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.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
