Subject: [spring] Questions re Section 3 of draft-filsfils-...-policy-00

From: Eric C Rosen <[email-masked]>
Date: Wed, 10 May 2017 13:34:01 -0400

I have a few questions/comments on Section 3 of 
draft-filsfils-spring-segment-routing-policy-00.  Mostly they are about 
text that is subject to different interpretatons, or about situations 
where the draft doesn't make it clear what to do. There are some 
substantive issues that really need clarification and/or further 
discussion.  For convenience, I've reproduced the Section 3 below, and 
have inserted my questions/comments in-line, beginning with "Eric> ".

----------------

3.  SR Policy

    An SR Policy is identified through the following tuple:

    o  The head-end where the policy is instantiated/implemented.
    o  The endpoint (i.e.: the destination of the policy).
    o  The color (an arbitrary numerical value).

    At a given head-end, an SR Policy is fully identified by the <color,
    endpoint> tuple.

    An endpoint can be specified as an IPv4 or IPv6 address.

    An SR Policy contain contains one or more candidate paths.

----------------

Eric> Perhaps: "An SR Policy is associated with one or more candidate paths"

----------------

    An SR Policy instantiates one single path in RIB/FIB: i.e. the
    selected path among the candidate paths.

----------------

Eric> I think it would be clearer to say "For each SR Policy, at most 
one candidate path is selected, and only the selected path is used for 
forwarding traffic that is being steered to that policy." (I'd avoid 
mentioning the FIB at all, since that will just raise questions about 
whether the FIB can have paths that aren't in the RIB.)

----------------

    A candidate path is either dynamic or explicit.

    A dynamic path expresses an optimization objective and a set of
    constraints.  The headend computes a solution to the optimization
    problem as a Segment Identifier (SID) list or a set of SID lists.
    When the headend does not have enough topological information (e.g.
    multi-domain problem), the headend may delegate the computation to a
    PCE.  Whenever the network situation changes, the path is recomputed.

----------------

Eric> Perhaps: "Whenever the solution to the optimization problem may 
have changed, the path is recomputed".

----------------

    An explicit path is a SID list or a set of SID lists.

    A candidate path has a preference.  If not specified, the default
    preference is 100.

    A candidate path is associated with a single Binding SID (BSID).

----------------

Eric> This seems to suggest that the mapping from a "candidate path" to 
a BSID is a one-one mapping.  However, I don't think that's correct.  
Two different SR policies might happen to be associated with identical 
candidate paths.  In that case, wouldn't one still want each policy to 
be associated with a distinct BSID?

Eric> Actually, I'd have thought that what is needed is that there be a 
one-one mapping in the control plane from BSID to SR Policy.  In the 
data plane, a BSID that maps to a given SR Policy maps to the selected 
path for that policy.

Eric> I think the draft needs to be modified to make it clear which 
interpretation (if either) is the correct one.

----------------

    A candidate path is valid if it is usable.  A common path validity
    criterion is the reachability of its constituent SIDs.  The
    validation rules are defined in a later section.

    A Path is selected (i.e. it is the best path of the policy) when it
    is valid and its preference is the best (highest value) among all the
    paths of the SR Policy.

----------------

Eric> Perhaps: "among all the candidate paths of the SR Policy".

----------------

    Whenever a new path is learned or the validity of an existing path
    changes or an existing path is changed, the selection process must be
    re-executed.

    A headend may be informed about a path for a policy <color, endpoint>

----------------

Eric> Perhaps: "about a path" --> "about a candidate path"

----------------

    by various means including: local configuration, NETCONF, PCEP or
    BGP.  The protocol source of the path does not matter to the path
    selection logic.

----------------

Eric> I find the last sentence to be very confusing, as the term "the 
path selection logic" is not clearly defined.

Eric> One can interpret the paragraph to mean the following: "For a 
given Policy, when comparing a candidate path learned via one means to a 
candidate path learned via another means, one path will be regarded as 
preferable to the other.  The determination of which path is the 
preferable one does not depend upon the means by which the path was 
learned."

Eric> That seems reasonable, though it might be good to add: "If two 
candidate paths are learned via different means, the choice between them 
is not to be based upon the 'administrative distance' or 'route 
preference' metrics that are typically used when comparing routes that 
are distributed by different routing protocols.  (If that's actually 
what is meant.)

Eric> But one could also interpret the paragraph to mean that when 
multiple candidate paths for a given Policy are distributed by BGP, that 
the BGP bestpath selection process is not applied. That interpretation 
would not be correct, and would in fact be in conflict with 
draft-previdi-idr-segment-routing-te-policy.  I'd like to see that 
clarified here.

Eric> (Draft-previdi also has some imprecise language about BGP being 
"just a conveyor".  That language should really be removed, as it is 
just a metaphor, and is subject to many different interpretations.)

Eric> When considering the BGP distribution of candidate paths for a 
Policy, there is a gray area that needs to be addressed.  In BGP, the 
policy <headend1, color1, endpoint1> would be represented as a route 
whose NLRI is <RD, color1, endpoint1> and that carries an RT that is an 
import RT of the headend.  It is possible that a given headend will 
import both <RD1, color1, endpoint1> and <RD2, color1, endpoint1>, where 
RD1 != RD2.  This is analogous to a familiar situation from L3VPN, where 
both <RD1, Prefix1> and <RD2, Prefix2> are imported into a given VRF.  
In this situation, L3VPN selects the bestpath by using the BGP Bestpath 
Selection procedure, but ignoring the fact that the RDs are different.

Eric> I have always assumed that the analogous procedure would be 
applied when comparing two BGP-distributed SR Policy "routes" wnose 
NLRIs differ only in their RDs. Some private conversations among vendors 
have indicated that this assumption is shared by others.  However, this 
is not stated clearly in either draft-previdi or draft-filsfils, and I 
have discovered recently that not everyone shares this assumption.  I've 
even heard people refer to the statement in draft-filsfils that "the 
protocol source of the path does not matter to the path selection logic" 
as "proof" that my assumption is incorrect.

Eric> So I'd like to see some text in one draft or the other that makes 
the intention very clear.  (Given such text, we might or might not want 
to argue about it further.)

----------------

    In the vast majority of use-cases known to date, a path is associated
    with a single SID list and each path of a policy has a different
    preference.

----------------

Eric> That's an interesting historical observation, but a protocol spec 
has to make it clear what needs to be done in the case where different 
candidate paths have the same preference.  Is the final selection left 
to the implementation, or is it desirable to have a tie breaking process 
that always makes it deterministic which of a set of candidate paths 
becomes the selected path for a given SR Policy?  The draft should 
specify one or the other of these options.

----------------

    The SID list of an SR Policy is the SID list of its selected path.

----------------

Eric> The above sentence is very confusing, as a path may consist of a 
set of SID lists, but the sentence presupposes that a path consists of a 
single SID list. Perhaps that sentence can just be removed?

----------------

    The BSID of an SR Policy refers to its selected path.

    In all the use-cases known to date, all the paths associated with a
    given policy have the same BSID.  One may thus assume that in
    practice a policy has a stable BSID that is independent of the
    selected path changes and this BSID is an identification of a policy.

----------------

Eric> Observations about the characteristics of "all the use-cases known 
to date" do not determine what one "may assume" about the future.  If 
the intention is that, at any given time, a given BSID maps directly to 
a single SR Policy and indirectly to its selected path, please state 
this explicitly, using normative terminology (e.g., RFC2119 "MUST").

----------------

    However, one should know that a BSID MAY change over the life of an

----------------

Eric> Perhaps "a BSID MAY change" --> "the mapping from a given BSID to 
an SR Policy may change".

----------------

    SR Policy and the true identification of a policy is the tuple
    <headend, endpoint, color>.

    An SR Policy <color, endpoint> is active at a headend as soon as this
    head-end knows about a valid path for this policy.

    An active SR Policy installs a BSID-keyed entry in the forwarding
    plane with the action of steering the packets matching this entry to
    the SID list of the SR Policy.

----------------

Eric> I think "the SID list of the SR Policy" should be replaced with 
"the selected path of the SR Policy".

----------------

    If a set of SID lists is associated with the selected path of the
    policy, then the steering is flow and W-ECMP based according to the
    relative weight of each SID list.

    In summary, the information model is the following:

             SR policy FOO
                 path 200 (selected)
                     BSID1
                     Weight W1, SID list1: SID11...SID1i
                     Weight W2, SID list2: SID21...SID2j
                 path 100 (selected)
                     BSID2
                     Weight W3, SID list3: SID31...SID3i
                     Weight W4, SID list4: SID41...SID4j

----------------

Eric> It is not clear what (if anything) the numbers "200" and "100" are 
meant to represent.

Eric> The above seems to suggest that Policy FOO has two selected 
paths.  That doesn't seem compatible with prior text that says only one 
path is selected from among the candidate paths.

----------------

    In general BSDIn = BSID1 = BSID2 ...

----------------

Eric> I don't see that this observation about what happens "in general" 
is really useful, except perhaps a recommendation to operators.  The 
draft needs to specify exactly what happens if two different BSIDs are 
assigned to the same Policy.

Eric> For concreteness, let's assume that Policy <headend1, color1, 
endpoint1> is distributed by BGP with BSID1, and that the same policy is 
distributed by PCEP with BSID2.  And let's assume that the selected path 
for that Policy is a path that is distributed by BGP.  Now what is 
headend1 supposed to do if it sees a packet whose top label is BSID2?  
Would BSID2 be considered to be an invalid incoming label, or would it 
be considered to denote the <color1, endpoint1> Policy?  If the latter, 
presumably it would denote the selected path for that Policy, even 
though the BSID was distributed by PCEP and the selected path was 
distributed by BGP.