Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT)

[Ahmed Bashandy <[e-mail]>]

thanks a lot for the comments (very clear and to the point)

I am taking a look right now and will start discussion with authors of 
the IGP drafts.

Ahmed



On 4/10/19 1:25 PM, Alvaro Retana via Datatracker wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-spring-segment-routing-mpls-19: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> (1) This first point is a cross-document DISCUSS.  In short, the assumptions in
> this document about what an MCC is responsible for are not in line with the
> corresponding IGP drafts for OSPF [1][2] and IS-IS [3].  This misalignment must
> be resolved before any of these documents are published.
>
> [Note: I'll start a thread with the corresponding WGS, Authors, Shepherds,
> Chairs and ADs.  Let's please discuss this point there.]
>
> This document uses the following definition in §2: "We call "MPLS Control Plane
> Client (MCC)" any control plane entity installing forwarding entries in the
> MPLS data plane.  IGPs with SR extensions...are examples of MCCs."
>
> The focus of the IGP drafts is on the transport of the SR information, and not
> on other functions (see below).  Which component is responsible for what is the
> point that needs clarification -- either in this document, the IGP drafts, or
> both.
>
> These are some specific cases:
>
> (1.1) §2.4 (Mapping a SID Index to an MPLS label): "The following rules MUST be
> applied by the MCC when calculating the MPLS label value corresponding the SID
> index value "I"."  There's nothing in the IGP extension documents that point at
> this set of rules, and only a passing reference in the OSPF documents about
> outgoing labels.
>
> (1.2) §2.5 (Incoming Label Collision) also assumes more functions from an MCC
> than what the IGP documents do.  For example: "Within an MCC, apply
> tie-breaking rules to select one FEC only and assign the label to it."
>
> (1.3) §2.8 also expects work by the IGPs: "the MCC is responsible for
> downloading the correct label value to FIB"...in this case not just calculating
> the label, but installing it in the FIB.
>
> (1.4) §2.10.1: "The method by which the MCC on router "R0" determines that PUSH
> or CONTINUE operation must be applied using the SID "Si" is beyond the scope of
> this document. An example of a method to determine the SID "Si" for PUSH
> operation is the case where IS-IS
> [I-D.ietf-isis-segment-routing-extensions]..." Note that the IS-IS draft (or
> the OSPF ones, for that matter) don't talk about how to determine the operation
> -- if that is out of scope of this document, then where is it specified?
>
> (1.5) From §2:
>
>     An implementation SHOULD check that an IGP node-SID is not associated
>     with a prefix that is owned by more than one router within the same
>     routing domain. If so, it SHOULD NOT use this Node-SID, MAY use
>     another one if available, and SHOULD log an error.
>
> rfc8402 reads (§3.2): "An IGP Node-SID MUST NOT be associated with a prefix
> that is owned by more than one router within the same routing domain."  The
> text above is not in line with that (MUST NOT vs SHOULD).  Also, how can
> "SHOULD check" be Normatively enforced?
>
> Both sentences above seem to be trying to specify a behavior for the IGPs.
>
> [1] https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions
> [2]
> https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions
> [3] https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions
>
> (2) §2.5.1: According to §2.5, a "tie-breaking rule MUST be deterministic".
> However, the specification of the default rules are not: the first step uses
> the administrative distance, but the specification says that "the FEC types are
> ordered using the default administrative distance ordering defined by the
> implementation"...and later that the "user SHOULD ensure that the same
> administrative distance preference is used on all routers".  The combination of
> different implementations and the lack of an absolute requirement to ensure
> consistency can easily be non-deterministic.
>
> This point is related to the text in §2.6 which talks about how "the ingress
> node MUST resolve" collisions the same way.  Because of the lack of an absolute
> requirement for consistency, this "MUST" doesn't guarantee the same result.
>
> Also related is this text in §2.5.1: "All routers in a routing domain SHOULD
> use the same tie-breaking rules to maximize forwarding consistency."  When
> would all routers not use the same rules?  It seems to me that forwarding
> consistency is very important and would want to be maximized all the time.
> IOW, why not use MUST?
>
> I'm making this point a DISCUSS item because it is directly related to the
> ability of multiple implementations to interoperate.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> (1) §2.2: "A global segment MUST be a label, or an index which may be mapped to
> an MPLS label within the Segment Routing Global Block (SRGB)..."  I don't think
> this sentence fragment is clear: the intent is surely to say that the global
> segment MUST be mapped within the SRGB (and not that it "MUST be a label"),
> right?  Suggestion: s/A global segment MUST be a label, or an index which may
> be mapped/A global segment is a label, or an index which MUST be mapped
>
> (2) §2.5: "Suppose an anycast prefix...the advertisement of the prefix-SID by
> some, but not all, of advertising nodes SHOULD NOT be treated as a label
> collision."  I'm not sure how the receiver knows if the SID was advertised "by
> some, but not all"...or even if the prefix is being used as anycast.  Given the
> Normative language, please explain.  IOW, please clarify the difference between
> a duplicate prefix-SID and an anycast prefix.  The use of "SHOULD NOT" above
> seems to imply that there are cases when the situation should be treated as a
> label collision...what are those cases?
>
> (3) §2.5: "The remaining FECs with the default algorithm...are installed in the
> FIB...without any incoming labels..."  What will these entries be used for?
> Given that we're talking about an MPLS network, there may be no traffic that
> matches the FEC (the traffic should be labeled)...if that is the case, then why
> install in the FIB at all?  OTOH, if there is a possibility that unlabeled
> traffic is received, then this entry (meant for a different purpose) could be
> used...also not an ideal situation.
>
> §2.6 makes the case that in order "to minimize the chance of misforwarding, a
> FEC that loses its incoming label...MUST NOT be installed in FIB".  This
> inconsistency adds strength to my questions above.
>
> (4) §2.5.1: "if more than one competing FEC remains after step 1, select the
> smallest numerical FEC value"  What value?  Are you referring to the FEC type
> (introduced later in this section)?  If so, please be explicit and consistent.
>
> (5) §2.5.2.1: The illustration seems incomplete as the rules in §2.5.2 say that
> "the receiving instance MUST compute its local label", but in this case "B
> decides not to advertise any index".  The second part of the example (in
> §2.5.2.2) seems to complete the scenario.  It seems confusing to me that the
> first part shows an incomplete case...or am I misinterpreting the rules?
>
> (6) §2.7: "PUSH, NEXT, and CONTINUE...The specifications of these operations
> can be found in [RFC8402]. This sub-section specifies how to implement each of
> these operations in the MPLS forwarding plane."  It seems contradictory that
> the specification is in two places...  In any case, I think that this section
> is unnecessary as it doesn't seem to add anything from what rfc8402 already
> explains.
>
> (7) Nits...
>
> s/flooding mechanisms of link state IGPs fits/flooding mechanisms of link state
> IGPs fit
>
> s/to have a node segment to reach the node/to have a node segment reach the node
>
> s/per routing instance, topology, algorithm/per routing instance, topology, or
> algorithm
>
> s/except rule/except the rule
>
> s/local label serves/a local label serves
>
> s/subTLVs/sub-TLVs
>
> s/Remaining FECs/The remaining FECs
>
> s/installed in FIB/installed in the FIB
>
> s/lowest value SHOULD be/lowest value SHOULD be:
>
> s/SR Algorithm,)/SR Algorithm)
>
>