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

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Wed, 10 Apr 2019 13:25:19 -0700

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)

---

From: Ahmed Bashandy <[email-masked]>
Date: Tue, 16 Apr 2019 08:13:48 -0700

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 17 Apr 2019 09:00:04 +0000

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:   [email-masked]

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Ahmed Bashandy
Sent: Tuesday, April 16, 2019 6:14 PM
To: Alvaro Retana <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Shraddha Hegde <[email-masked]>
Subject: Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT)

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:
> 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
> (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.
>
> (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."
>
> 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
> 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?
>
> [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
>
> 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.
>
>
> (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/per routing instance, topology, algorithm/per routing instance, 
> topology, or algorithm
>

_______________________________________________
spring mailing list
[email-masked]
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.
___________________________________________________________________________

---

From: Ahmed Bashandy <[email-masked]>
Date: Wed, 17 Apr 2019 10:44:16 -0700

Thanks a lot for the comments

See inline #Ahmed

Thanks

Ahmed

> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
#Ahmed
Martin (thanks a lot) replied to these points. I hope his reply is 
satisfactory
> "SHOULD check" be Normatively enforced?
#Ahmed: I removed the paragraph since I agree that RFC8402 is sufficient
> requirement for consistency, this "MUST" doesn't guarantee the same result.
#Ahmed:
I think there is a misunderstanding in this point. The objective of the 
tie breaking rules as mentioned in the 3rd paragraph in page 9 is 
determinism on any given router. I.e. on any router, if the same set of 
FECs are mapped to a label "L1", then that label L1 is assigned the same 
FEC irrespective of the order by which the FECs-to-label mappings are 
received. Hence even if different routers have different administrative 
distances (default or otherwise), if a router receives the mappings from 
the same set of FECs to the same label "L1", the router will always 
assign the same FEC to the label "L1" irrespective of the order by which 
these mappings are received
Hence the whether routers use the same or different administrative 
distances has no bearing on deterministically assigning the same label 
to the same FEC on each router.

The tie-breaking rules as they are written in the draft will result in 
determinism on any given router. If you think otherwise it would be 
great to point out the flaw(s) and we will be very happy to correct it 
(them)

> ability of multiple implementations to interoperate.
#Ahmed: Actually no. It is possible that an index could not be mapped 
into an SRGB on some routers, e.g. because the SRGB is too small or 
because of incoming label collision. But I agree with the first part of 
the sentence so I changed it to "is" in the latest version
> label collision...what are those cases?
#Ahmed: You're right. I'll replace"SHOULD" with "MUST"
I have not used the term "duplicate prefix-SID" anywhere.
> used...also not an ideal situation.
#Ahmed: I replaced "is" with "may be"
> inconsistency adds strength to my questions above.
#Ahmed: The sentence adds "based on the losing SID". This means for 
example it can be installed natively (e.g. pure IPv4/6 prefix) without 
any local or outgoing label or with a local and outgoing LDP label.
> (introduced later in this section)?  If so, please be explicit and consistent.
#Ahmed: I added the sentence "The numerical value of the FEC is 
determined according to the FEC encoding described later in this section"
> first part shows an incomplete case...or am I misinterpreting the rules?
#Ahmed: I modified the bullet after the "Else" statement in section 
2.5.2. I hope this modification is satisfactory
> is unnecessary as it doesn't seem to add anything from what rfc8402 already
#Ahmed: The section specifies more details that are requested by other 
members of the WG. For example it specifies the TTL and TC . It also 
refers to sections 2.10 and 2.11 and discusses mirror SID. But to ensure 
connectedness between this two document, I added the clause " As 
described in [RFC8402], " at the beginning of each subsection
> s/SR Algorithm,)/SR Algorithm)
#Ahmed: Fixed (thanks a lot)

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 18 Apr 2019 08:16:39 +0000

Ahmed, and all,
Two points:

1.       I have to admit that I did not interpret the requirement for deterministic behavior of the tie-breaking rules in the draft as limited to each specific router:

a.  If this is indeed the intention of the authors, I would suggest to state it explicitly in the text to avoid possible misinterpretations

b.  Personally I doubt the value of deterministic tie-breaking rules if they are limited to each individual router: from my POV having different deterministic rules in different routers does not guarantee any meaningful behavior across the SR domain.

2.       The updated text about node segment in Section 2 in the -21 revision of the draft  says that “In order to have a node segment reach the node, a network operator SHOULD configure at least one node segment per routing instance,  topology, or algorithm”. From my POV, this contradicts RFC 8402 that states in Section 3.1 that “The context for an IGP-Prefix segment includes the prefix, topology, and algorithm”.  The drafts that define SR extensions for IS-IS and OSPF are aligned with the definition in 8402; e.g., the IS-IS extensions for SR<https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-24> draft states in section 2.1 that the Prefix Segment Identifier Sub-TLV (that includes the Algorithm field) can appear in any of the following TLVs:

a.        TLV-135 (Extended IPv4 reachability) defined in [RFC5305].

b.        TLV-235 (Multitopology IPv4 Reachability) defined in [RFC5120].

c.        TLV-236 (IPv6 IP Reachability) defined in [RFC5308].

d.        TLV-237 (Multitopology IPv6 IP Reachability) defined in [RFC5120].
My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sent: Wednesday, April 17, 2019 8:44 PM

See inline #Ahmed

Thanks
Ahmed

DISCUSS:

both.

outgoing labels.

-- if that is out of scope of this document, then where is it specified?
#Ahmed
Martin (thanks a lot) replied to these points. I hope his reply is satisfactory

(1.5) From §2:

[2]

requirement for consistency, this "MUST" doesn't guarantee the same result.
#Ahmed:
I think there is a misunderstanding in this point. The objective of the tie breaking rules as mentioned in the 3rd paragraph in page 9 is determinism on any given router. I.e. on any router, if the same set of FECs are mapped to a label "L1", then that label L1 is assigned the same FEC irrespective of the order by which the FECs-to-label mappings are received. Hence even if different routers have different administrative distances (default or otherwise), if  a router receives the mappings from the same set of FECs to the same  label "L1", the router will always assign the same FEC to the label "L1" irrespective of the order by which these mappings are received
Hence the whether routers use the same or different administrative distances has no bearing on deterministically assigning the same label to the same FEC on each router.

The tie-breaking rules as they are written in the draft will result in determinism on any given router. If you think otherwise it would be great to point out the flaw(s) and we will be very happy to correct it (them)

IOW, why not use MUST?

COMMENT:

be mapped/A global segment is a label, or an index which MUST be mapped
#Ahmed: Actually no. It is possible that an index could not be mapped into an SRGB on some routers, e.g. because the SRGB is too small or because of incoming label collision. But I agree with the first part of the sentence so I changed it to "is" in the latest version

inconsistency adds strength to my questions above.
#Ahmed: The sentence adds "based on the losing SID". This means for example it can be installed natively (e.g. pure IPv4/6 prefix) without any local or outgoing label or with a local and outgoing LDP label.

(introduced later in this section)?  If so, please be explicit and consistent.
#Ahmed: I added the sentence "The numerical value of the FEC is determined according to the FEC encoding described later in this section"

first part shows an incomplete case...or am I misinterpreting the rules?
#Ahmed: I modified the bullet after the "Else" statement in section 2.5.2. I hope this modification is satisfactory

explains.
#Ahmed: The section specifies more details that are requested by other members of the WG. For example it specifies the TTL and TC . It also refers to sections 2.10 and 2.11 and discusses mirror SID. But to ensure connectedness between this two document, I added the clause " As described in [RFC8402], " at the beginning of each subsection

(7) Nits...

IGPs fit

algorithm

s/subTLVs/sub-TLVs