[prev in list] [next in list] [prev in thread] [next in thread]
List: ms-ospf
Subject: Re: [Lsr] [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCU
From: Alexander Vainshtein <Alexander.Vainshtein () ecitele ! com>
Date: 2019-04-17 9:00:04
Message-ID: AM0PR03MB382811BAFC110137FB7A6BBC9D250 () AM0PR03MB3828 ! eurprd03 ! prod ! outlook ! com
[Download RAW message or body]
Alvaro, Ahmed and all,
As the twice RTG-DIR reviewer of this draft I should probably have noticed this \
earlier, but...
I fully agree with Alvaro that the drafts that define SR extensions to IS-IS and OSPF \
do not say anything about these protocols installing SR-related forwarding entries in \
the MPLS data plane. What's more, I do not think that such functionality should be \
specified in these drafts. From my POV, whether SR-related forwarding entries are \
installed in the MPLS DP by SR extension to the IGP, or by a different entity is a \
local implementation issue. I do not think there is any way for an external observer \
to decide whether these forwarding entries are installed by SR extension to IGP or by \
some other internal entity.
I am aware of some SR-MPLS implementations where SR-related forwarding entries are \
installed in the MPLS DP by dedicated internal entities and not by SR extension to \
IGP. So far this fact did not affect in any way successful participation of these \
implementations in public interoperability tests.
Regards, and apologies for missing this important point in my reviews,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: Alexander.Vainshtein@ecitele.com
-----Original Message-----
From: spring <spring-bounces@ietf.org> On Behalf Of Ahmed Bashandy
Sent: Tuesday, April 16, 2019 6:14 PM
To: Alvaro Retana <aretana.ietf@gmail.com>; The IESG <iesg@ietf.org>
Cc: draft-ietf-spring-segment-routing-mpls@ietf.org; spring@ietf.org; \
spring-chairs@ietf.org; Shraddha Hegde <shraddha@juniper.net>
Subject: Re: [spring] Alvaro Retana's Discuss on \
draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT)
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-mpl
> s/
>
>
>
> ----------------------------------------------------------------------
> 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-ext
> ensions [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)
>
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains information which \
is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received \
this transmission in error, please inform us by e-mail, phone or fax, and then \
delete the original and all copies thereof.
___________________________________________________________________________
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic