Subject: Re: [mpls] RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 4 Nov 2018 16:06:54 +0000

Ahmed,
Apologies for a delayed response.
I fully agree that advertising the same prefix SID as the Node SID by two different nodes in the SR domain is “a clear violation of the SR architecture RFC (8402)”.
But I do not think that the SR-MPLS draft can silently ignore this violation just because it “is not an incoming label collision”.
The same applies to the controversy in advertising at the same prefix as Anycast by some nodes but not as Anycast (or even as a Node SID) by some other nodes.
Your reference to these being just control plane issues and therefore not related to SR-MPLS is not valid - because the drafts dealing with the SR control plane to which you refer in this draft are strictly MPLS-oriented: they define how to advertise SID labels or indices that are translated into SID labels, and neither of these mechanisms is relevant fore SRV6 IMHO. (I do not have to remind you that a draft that defines SRV6 extensions for ISIS<https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions/?include_text=1> exists, and deals with other issues).
My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: Ahmed Bashandy [mailto:[email-masked]]
Sent: Sunday, October 28, 2018 1:01 AM
To: Shraddha Hegde <[email-masked]>; Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; Jonathan Hardwick ([email-masked]) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

Thanks for the comments

While it is a clear violation of the SR architecture RFC (8402), more than one node advertising the same IPv4/6 PREFIX and both have the same prefix-SID value with "N" flag is not an incoming label collision because the label is associated with the same FEC, which is the prefix.

Hence handling such violation is not an SR-MPLS problem because there is no incoming label collision and hence it it is outside the scope of this draft

The second issue is which SID to choose for an SR-policy (be it a policy for TE, ti-lfa, uloop avoidance, security,..., etc). That is strictly a control layer functionality and is not specific to SR-MPLS. Hence it is outside the scope of this draft

The third issue is the case where an anycast prefix is advertised with a prefix-SID sub-TLV by some (but not all) of the nodes that advertise that prefix. Again this is not an incoming label collision because the label is associated with a single FEC, which is the anycast prefix.

On 7/19/18 8:30 PM, Shraddha Hegde wrote:
Hi Ahmed,

The Node-SIDs are expected to be unique to a node.

“
   An IGP Node-SID MUST NOT be associated with a prefix that is owned by
   more than one router within the same routing domain.”

If two different nodes advertise same Node-SID,
         For Example Node A and B both advertise prefix 1.1.1.1 and associate a  SID 1000 with N bit set.
There is an anomaly here and IMO, this draft should address how to handle this anomaly and whether TI-LFA and other
Applications can use this SID as a Node-SID.
Another slight variation of this case is a scenario where A and B both advertise a prefix 1.1.1.1 and A assigns a Node-Sid
Of 1000 and B does not assign any SID.

Rgds
Shraddha

From: Alexander Vainshtein <[email-masked]><mailto:[email-masked]>
Sent: Thursday, July 19, 2018 10:05 PM
To: Ahmed Bashandy <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>' <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>' <[email-masked]><mailto:[email-masked]>; Jonathan Hardwick ([email-masked]<mailto:[email-masked]>) <[email-masked]><mailto:[email-masked]>; Shraddha Hegde <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

Ahmed hi!
Lots of thanks for your response.
Of course Node SIDs are not different from any other Prefix SIDs when it comes to the MPLS forwarding plane.
But, IMHO, strictly speaking, this is correct for any other SID as well.
You seem to ignore the difference between SR-MPLS and SRv6 with regard to the life span of prefix SIDs in general and Node SIDs in particular. From my POV this difference should be discussed in the draft.
So it seems that we can only “agree to disagree” on the need to say something specific about Node SIDs in the draft, and let the WG to decide what to do about it.
Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

From: Ahmed Bashandy [mailto:[email-masked]]
Sent: Thursday, July 19, 2018 7:13 PM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; Jonathan Hardwick ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

Thanks for the reply

See inline

Ahmed

On 7/12/18 12:22 AM, Alexander Vainshtein wrote:
Ahmed and all,
I would like to expand on my comments (and your responses) about the role of Node SIDs in SR-MPLS.
I would like to bring your attention two points:

1.       Node SIDs (and, in general, Prefix SIDs) in MPLS-SR are different from the same in SRv6 because they require explicit configuration action by the operator of SR domain. I.e., it is not enough for a node to own some /32 or /128 prefix that is advertised by IGP. The operator must explicitly configure the node to use such a prefix as  Node SID and to assign to it a specific index that is unique in the SR domain. From my POV, this difference alone would qualify Node SIDs as a topic to be discussed in the MPLS-SR Architecture<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dmpls-2D14&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=q6djpRXlamUzKZlGIuXTtBcsnwevHwddqvStZrSFMnE&e=> draft.
#Ahmed: I disagree with your POV. From the forwarding plane perspective it does not make any difference whether a the label at the top of an MPLS packet (representing the prefix-SID) identifies a node or not. So from the SR-mpls forwarding point of view there is no difference between a prefix-SID and a node-SID. If there is any place in the SR-mpls draft where there is a need to handle a node-SID different from a prefix SID, it would be great to point it out

2.      In addition, quite a few constructs associated with SR-MPLS implicitly assume that each node in the SR-MPLS domain is assigned with at least one Node SID. One example can be found in the TI-LFA<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=jbH0DSYYo2UYymWZrlvAt7qUWVXsYKuCtMiEyoe-DWE&e=> draft. This draft says in Section 4.2:

4.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04-23section-2D4.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=sAi3KCWUwGS3D93t8ic64W_46xm9y8Oacs7ozcAweS8&e=>. The repair node is a PQ node

   When the repair node is in P(S,X), the repair list is made of a

   single node segment to the repair node.
In the scope of this section, the repair node is not adjacent to the PLR, and therefore, to the best of my understanding,  “a single node segment to the repair node” can be only the Node SID of the repair node. Since repair nodes are computed dynamically, this entire scheme depends on all nodes in the MPLS=SR domain  having at least one Node SID each
#Ahmed: The choice of the SID to identify an intermediate or exit node(s) in an SR-policy is a control plane behavior, irrespective of reason such policy is created (be it ti-lfa explicit path, uloop avoidance explicit path, or some SR-TE explicit path). SR-Policy as well as Ti-LFA and uloop avoidance are handled in separate drafts. So just like the response to your previous comment, from forwarding plane perspective it does not make any difference whether the label at the top of an MPLS packet identifies a single or multiple nodes.

.

Hopefully these notes clarify my position on the subject.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

From: Alexander Vainshtein
Sent: Wednesday, July 11, 2018 12:02 PM
To: Ahmed Bashandy <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>' <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>' <[email-masked]><mailto:[email-masked]>; Jonathan Hardwick ([email-masked]<mailto:[email-masked]>) <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

Ahmed, and all,
Lots of thanks for a detailed response to my comments.
Please see inline below my position on each of them.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

From: Ahmed Bashandy [mailto:[email-masked]]
Sent: Wednesday, July 11, 2018 4:42 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; Jonathan Hardwick ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

Thanks for thorough (and VERY clear) the review

See inline #Ahmed

Ahmed

On 6/15/18 11:08 PM, Alexander Vainshtein wrote:
Re-sending to  correct SPRING WG list.
Sincere apologies for the delay caused by a typo.
Thumb typed by Sasha Vainshtein

________________________________
From: Alexander Vainshtein
Sent: Sunday, June 10, 2018 10:43:52 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'; Jonathan Hardwick ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

Explicitly adding Shraddha  who is the shepherd of this draft.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

From: Alexander Vainshtein
Sent: Friday, June 8, 2018 5:43 PM
To: [email-masked]<mailto:[email-masked]>' <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>' <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>' <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>' <[email-masked]><mailto:[email-masked]>
Subject: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

Hello,
I have been selected to do a routing directorate “early” review of this draft: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dmpls_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=Cxbaaf9U0kj6_meVSobSkRLQW1SwI8MJvgHpuYp0QOM&e=>

The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. As this document is currently in the WG Last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments.

For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=6pnI7l82ewwzoxgOXqTKrbKuQidt6-KBsZdsXFnoQCg&e=>

Document: draft-ietf-spring-segment-routing-mpls-13
Reviewer: Alexander (“Sasha”) Vainshtein ([email-masked]<mailto:[email-masked]>)
Review Date: 08-Jun-18
Intended Status: Proposed Standard.

Summary:

I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.

Comments:

I consider this draft as an important  companion document to the Segment Routing Architecture<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D15&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=iJShh7e7yyVkt44v1O5pyCOMfHCpAvfBNGgFr5lk130&e=> draft that, ideally, should augment definitions of the Segment Routing (SR) notions and constructs given there with details specific for the SR instantiation that uses  the MPLS data plane (SR-MPLS).  Many issues raised in my review reflect either gaps that should be, but have not been, closed, or inconsistencies between the two drafts.

Since RFC 8287<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8287&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=y7jp3UYNTtcmm9HOulzqPTrMURTrsMiO26rWlNZN5Ws&e=> is already published as a Standards Track RFC, I expect such augmentation to be backward compatible with this document (or to provide clear indications of required updates to this document). And I include the MPLS WG into distribution list.

This draft was not easy reading for me. In particular, the style of Section 2.5 that discusses at length and in some detail multiple “corner cases” resulting, presumably, from misconfiguration, before it explains the basic (and relatively simple) “normal” behavior, looks problematic to me.

The WG Last Call has been extended by one week. Nevertheless, I am sending out my comments

Major Issues: None found
#Ahmed: thanks a lot

Minor Issues: Quite a few but, hopefully, easy to resolve.

1.    Encapsulation of SR-MPLS packets:

a.    RFC 3032 (referenced by the draft) and RFC 5332 (not mentioned in the draft) depend two encapsulations of labeled packets - one for Downstream-allocated labels and another for Upstream-allocated ones.
#Ahmed: RFC5332 is for multicast. As mentioned in Section 6 of draft-ietf-spring-segment-routing-15, multicast is outside the scope of SR. Hence the RFC was not referred to in the SR-MPLS draft
[[Sasha]] I would be satisfied with this response, would it not be for the following text I see in Section 2.2 of the SR Policy Architecture<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dpolicy-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=4f0H68LTvkp7N-bYTVLOhWqiEbHaCsOQR1z_Qzz3Wf4&e=> draft:
   A variation of SR Policy can be used for packet replication.  A
   candidate path could comprise multiple SID-Lists; one for each
   replication path.  In such a scenario, packets are actually
   replicated through each SID List of the SR Policy to realize a point-
   to-multipoint service delivery.

This looks to me as being very much multicast in SR, and, unless you want to say that it is limited to SRv6, makes my question relevant IMHO.

b.    From my POV the ST-MPLS only uses Downstream-allocated labels – but I expect the draft to state that explicitly, one way or another. (If Upstream-allocated labels are relevant for SR-MPLS, I would see it as a major gap, so I hope that this is not the case).
#Ahmed: I will add a statement in section 2.2 to mention that it is down-stream allocated as you mentioned
[[Sasha]] This is quite unambiguous and, once added, would resolve my comment in full – the previous comment notwithstanding. In particular, it would imply that even labels representing BSIDs of a SR Replication policies will be downstream-allocated.

2.    Label spaces in SR-MPLS:

a.    RFC 3031 (referenced by the draft) defines per-platform and per-interface label spaces, and RFC 5331 (not mentioned in the draft) adds context-specific label spaces and context labels.

b.    The draft does not say which of these are or are not relevant for SR-MPLS

c.    From my POV:

                                         i.    Labels representing all kinds of SIDs mentioned in the draft MUST be allocated from the per-platform label space only

                                        ii.    At the same time, instantiation of Mirror Segment IDs defined in Section 5.1 of the Segment Routing Architecture draft using MPLS data plane clearly calls for context labels and context-specific label spaces

d.    I expect the draft to provide a clear-cut position on these aspects of SR-MPLS.
#Ahmed: I will add a statement to section 2.2 to say that the it is per-platform. Regarding the function "mirroring", SR attaches a *function* to each SID. The "mirroring" function is already described in Section 5.1 of draft-ietf-spring-segment-routing and is not specific to the MPLS forwarding plane. Hence there is no need to re-mention it here because this document is trying to be as specific as possible to the MPLS forwarding plane. General functions attached to SID are described in the segment routing architecture document or future documents. Furture documents proposing new SR function must be as specific and clear as possible
[[Sasha]] Looks OK to me.

3.    SR-MPLS and hierarchical LSPs:

a.    SR LSPs that include more than one segment are hierarchical LSPs from the POV of the MPLS data plane. Therefore some (possibly, all) of the models for handling TTL and TC bits that have been defined in RFC 3443 (not mentioned in the draft) should apply to SR-MPLS

b.    RFC 8287 (not referenced in the draft) specifically discussed operation of the LSP Traceroute function for SR LSPs in the case when Pipe/Short Pipe model for TTL handling is used

c.    I expect the draft to provide at least some guidelines regarding applicability of each specific model defined in RFC 3443 (separately for TTL and TC bits) to SR-MPLS.
#Ahmed: BY design, the instantiation of SR over the MPLS forwarding plane (and hence this draft) does not modify the MPLS forwarding plan behavior as it is mentioned in the first sentence in Section 1. So the TTL behavior specified in rfc3443 is already implied and there is no need to re-mention it here just like all aspects of MPLS forwarding. RFC8287 is OAM-specific.  SR-OAM is handled in a separate document so is outside the scope of this draft
[[Sasha]] Unfortunately I do not think this is good enough. Let me ask a specific question reflecting my concerns:
The head-end node sends SR-MPLS packets across a path defined by an ordered set of SIDs with more than one SID in the list. Each SID is represented by a label stack entry (LSE) in the MPLS label stack, and the label field in each LSE is the label that matches the corresponding SID. However, each LSE also includes the TTL and TC fields. How does the head-end node set these fields in each of the LSEs following the top one? This clearly depends on the model (Uniform vs. Pipe/Short Pipe) implemented in each node that that performs Next operation on the packet along the path – but the head-end node usually is not aware of that.
RFC 8287 is relevant as an example here IMHO because it recommends the following setting of TTL in Traceroute packets:

-          Set the TTL of all the labels above one that represents the segment you are currently tracing to maximum

-          Set the TTL of the label one that represents the segment you are currently tracing to the desired value (to be incremented until end of segment is reached

-          Set the TTL of all the labels below one that represents the segment you are currently tracing to 0.
I expect the draft to provide some recommendations for traffic (non-OAM) packets as well.

4.    Inferring network layer protocol in SR-MPLS:

a.    I wonder if the draft could provide any details on the situation when a label that represents some kind of SID is the bottom-of-stack label to be popped by the egress LER
#ahmed: This is part of the "Next" function. It is described in detail in this document.
[[Sasha]] NEXT function is mentioned in several places in the document. Can you please point to the specific text that is relevant for my question?

b.    For the reference, RFC 3032 says that “the identity of the network layer protocol  must be inferable from the value of the label which is popped from  the bottom of the stack, possibly along with the contents  of the network layer header itself”

c.    From my POV the following scenario indicates relevance of this expectation for SR-MPLS:

                                         i.    IS-IS is used for distributing both IPv4 and IPv6 reachability in a given domain

                                        ii.    An IS-IS adjacency over some dual-stack link is established, and a single Adj-SID for this adjacency is advertised

                                       iii.    The node that has assigned and advertised this Adj-SID receives a labeled packet with the label representing this Adj-SID being both the top and bottom-of-stack label

                                       iv.    The implementers must be given unambiguous instructions for forwarding the unlabeled packet via the dual-stack link as an Ipv4 or an IPv6 packet.
#Ahmed: If you take a look at the SR-ISIS , SR-OSPFv2 and SR-OSFv3 drafts, you will see all 3 protocol advertise different adj-SIDS for IPv4 next-hop and IPv6 next-hop. For example, ISIS uses the "F-Flag" (section 2.2.1 in draft-ietf-isis-segment-routing-extensions-18) to specify whether the adj-SID is for IPv4 and IPv6. Similarly, the SR-ISIS draft attaches a prefix-SID to the prefix advertisement and hence implies the identity of the protocol underneath the bottom most label. For any other "function" attached to a SID, it is part of the specification of this function to describe what happens when the SID is represented by a label in the MPLS forwarding plane and this label is the bottom most label
[[Sasha]] OK, got it. This issue is resolved.

5.    Resolution of Conflicts: Are the

a.    Are the conflict resolution procedures listed in section 2.5 mandatory to implement?

b.    If they are mandatory to implement, are they also mandatory to deploy, or can the operators simply treat any detected conflict as requiring human intervention and preventing normal operation of SR-MPLS?
#Ahmed: They are recommended. I will modify the paragraph after the first 3 bullets in Section 2.5 to say that it is recommeded.
[[Sasha]] OK. However, it would be nice if you could refer separately for “RECOMMENDED to implement” and “RECOMMENDED to deploy”.  The latter probably requires a configuration knob for enabling conflict resolution rules (if they are implemented).

c.    For the reference, the IETF capitalized MUST appears just in a few places in Section 2.5, and each appearance has very narrow context:

                                         i.    For MCCs where the "Topology" and/or "Algorithm" fields are not defined, the numerical value of zero MUST be used for these two fields

                                        ii.    If the same set of FECs are attached to the same label "L1", then the tie-breaking rules MUST always select the same FEC irrespective of the order in which the FECs and the label "L1" are received. In other words, the tie-breaking rule MUST be deterministic.

                                       iii.    An implementation of explicit SID assignment MUST guarantee collision freeness on the same router
From my POV, it is not possible to infer the answer to my question from these statements. Some explicit statement is required.
#Ahmed: I agree with you POV and as mentioned in my reply to items (a) and (b), I will modify the paragraph to say that it is RECOMMENDED to answer you questions in items (a) and (b)

d.    The tie-breaking rules in section 2.5.1 include some specific values for encoding FEC types and address families – but these values are not supposed to appear in any IANA registries (because the draft does not request any IANA actions). Can you please clarify what is so special about these values?
#Ahmed: There is no significance to the values but there is a significance to the order among them. I will modify the text to clarify that
[[Sasha]] OK.

e.    I also doubt that comparison of FECs that represent IPv4 and IPv6 prefix SIDs makes much sense (for conflict resolution or else), because, among other things, there are valid scenarios when an IPv4 /32 prefix is embedded in an IPv6 /128 one.
#Ahmed: A prefix-SID is assigned to a prefix. An IPv6 prefix that embeds an IPv4 prefix is different from the IPv4 prefix. The specifications of SR extensions to ISIS, OSPFv2, OSPFv3, and BGP treat IPv4 and IPv6 prefixes separately, including the IPV6 prefixes with embedded IPv4 ones. Besides not all IPv6 prefixes embed IPv4 prefix in them. Hence the distinction between IPv4 and IPv6 prefixes is quite clear
[[Sasha]] My concern was mainly about IPv4-mapped IPv6 addresses. Quoting from RFC 4291:
2.5.5.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4291-23section-2D2.5.5.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=I14XA8I9Ruw5aBj5er_OVbvADz1sb9ZLFBGaZZlJJJ4&e=>.  IPv4-Mapped IPv6 Address

   A second type of IPv6 address that holds an embedded IPv4 address is
   defined.  This address type is used to represent the addresses of
   IPv4 nodes as IPv6 addresses.

From my POV this means that a /128 prefix associated with an IPv4-mapped IPv6 address and a /32 prefix associated with the IPv4 address that was mapped to this IPv6 address represent the same entity. This understanding fully matches usage of IPv4-mapped IPv6 addresses as BGP Next Hops of VPN-IPv6 addresses defined in RFC 4798. However, the comparison rules you have defined will treat them as two different prefixes.  I wonder if these rules, in the case of a conflict, could result in preferring the IPv6 prefix to an IPv4 one and therefore loosing MPLS connectivity for the ingress PE of a 6VPE service to its egress PE?

f.     Section 2.5.1 defines 3 types of SR-MPLS FECs, but I am not sure all SID types defined in the Segment Routing Architecture draft can be unambiguously mapped to one of these types. Problematic examples include at least the following:

                                         i.    Parallel Adjacency SID

                                        ii.    Mirror SID
Explicit mapping of SID types to SR-MPLS FEC types would be most useful IMO. If some SID types cannot be mapped to SR-MPLS FECs, this must be explicitly stated in the draft.
#Ahmed:
Parallel adjacency SID are handled in the type "(next-hop, outgoing interface)"
[[Sasha]] OK

Mirror SID is a type of binding-SID as mentioned in Section 5.1 in the SR architecture draft (draft-ietf-spring-segment-routing-15). Also as described in Section 2.4 draft-ietf-isis-segment-routing-extensions-18 (also see the equivalent in the OSPFv2 and OSPFv3 draft), a binding SID is identified by a prefix. Hence it is covered by the type "(Prefix, Routing Instance, Topology, Algorithm)"
[[Sasha]] I respectfully disagree. There is definitely no mention of Algorithm in the definition of the Mirror SID.

6.    Node SIDs in SR-MPLS:

a.    Node SIDs are explicitly defined and discussed in the Segment Routing Architecture draft but are not mentioned even once in this draft

b.    AFAIK, the common implementation practice today includes assignment of at least one Node SID to every node in the SR-MPLS domain

c.    Is there a requirement to assign at least one Node SID per {routing instance, topology, algorithm} in SR-MPLS? If not, can the authors explain expected behavior of such a node? (See also my comment about routing instances below).
#Ahmed: A Node-SID is a special case of prefix-SID. So there nothing specific about it from the MPLS forwarding plane point of view. Similarly from a standard tracks draft point of view, there is no requirement to assign a SID to every prefix just like there is no requirement to bind every prefix to an LDP label. Common and/or recommended practices or description of deployment scenarios are more befitting to BCP or informational drafts. This draft is a standards track draft
[[Sasha]] Well, you’ve just said that conflict resolution rules are RECOMMENDED, and this is quite common in the Standards Track RFCs.

If a {routing instance, topology, algorithm} is not assigned a SID, then this FEC is totally irrelavant to this draft and hence describing how a node treats it is totally outside the scope of this draft
[[Sasha]] AFAIK, neither of the SR extension drafts for IGPs mention routing instances that can be associated with the prefix, so I think that your reference to it is incorrect.
What’s more I suspect that Node SIDs represent the most used special case of Prefix SIDs with Anycast SIDs being quite behind.  Therefore some recommendation pertaining to the usage of Node SIDs would be very much in place IMHO.

7.    SRGB Size in SR-MPLS:

a.    The draft correctly treats the situation when an index assigned to some global SID cannot be mapped to a label using the procedure in Section 2.4 as a conflict.

b.    At the same time the draft does not define any minimum size of SRGB (be it defined as a single contiguous block or as a sequence of such blocks) that MUST be implemented by all SR-capable nodes

c.    I suspect that lack of such a definition could be detrimental to interoperability of SR-MPLS solutions. AFAIK, the IETF has been following, for quite some time, a policy that some reasonable MUST-to-implement defaults should be assigned for all configurable parameters exactly in order to prevent this.
#Ahmed: This document specifies how the SRGB is used and the behavior of routers when a prefix-SID index maps to a label inside and/or outside the SRGB. The actual size of the SRGB is a task in partitioning the label space, which is very specific to a particular deployment scenario. So IMO it is outside the scope of a standards track document. Now that SR-MPLS is deployed in many places, I expect the community to gain sufficient experience to recommend (or not recommend) a particular minimum/maximum size for the SRGB is some future informational or BCP draft/RFC
[[Sasha]] My reading of your response is that minimum size of SRGB is an issue for future study. Can you please just add this to the draft?

8.    Algorithms and Prefix SIDs:

a.    The draft mentions Algorithms (as part of SR-MPLS Prefix FEC) in, but it does not explicitly link them with the Prefix-SID algorithms defined in section 3.1.1 of the Segment Routing Architecture draft
#Ahmed: I will just add the reference [I-D.ietf-spring-segment-routing] right beside the first time "Algorithm" is mentioned
[[Sasha]] OK

b.    From my POV, the draft should explicitly state that the default Prefix-SID algorithm MUST be implemented in all SR-MPLS-compliant routers.
#Ahmed: The specification of what path calculation method should or must be supported is a routing protocol property not a forwarding plane property. In fact, the choice of a path calculation method or algorithm is completely orthogonal to the routed protocol. Hence mandating the support of a particular routing algorithm is beyond the scope of this document.
[[Sasha]] OK

c.    The Segment Routing Architecture draft states (in section 3.1.3) that “Support of multiple algorithms applies to SRv6”. But neither draft states whether multiple algorithms apply to SR-MPLS. Can you please clarify this point?
#Ahmed: The last paragraph of Section 3.1.2 titled SR-MPLS in draft-ietf-spring-segment-routing-15 discusses the support of multiple algorithms. So it is implied that the concept of algorithm applies to SR-MPLS. Hence there is no need to re-mention it here
[[Sasha]] The paragraph to which you refer only says that if a packet with the active Prefix-SID that is associated with a specific algorithm is received by a node that does not support this algorithm, this packet will be discarded. If this is the only type of support for multiple algorithms SR provides, it is not very useful IMHO.

9.    Routing instances and the context for Prefix-SIDs:

a.    The Segment Routing Architecture draft states in Section 3.1 that the “context for an IGP-Prefix segment includes the prefix, topology, and algorithm”

b.    This draft seems to define (in section 2.5) the context for the Prefix SID as “Prefix, Routing Instance, Topology, Algorithm” where ”a routing instance is identified by a single incoming label downloader to FIB” (but the notion of the label downloader to FIB is not defined).

c.    These two definitions look different to me.

d.    At the very least I would expect alignment between the definitions of context for the Prefix-SID between the two drafts. Preferably, the definition given in the Segment Routing Architecture draft should be used in both drafts.
#Ahmed: The context of the section 2.5 is limited to the resolution of local label collision. The use of "routing instance" in section 2.5 is just there for tie-breaking if there is local label collision.
[[Sasha]] I have already mentioned that “routing instances” are not defined in any the drafts dealing with SR Extensions for IGPs. So I do not understand how the conflict resolution procedure is supposed to use this. And in any case the difference between two definitions of the context of Prefix-SID requires some explanation.

10. Example of PUSH operation in Section 2.10.1:

a.    The first para of this section begins with the sentence “Suppose an MCC on a router "R0" determines that PUSH or CONTINUE   operation is to be applied to an incoming packet whose active SID is the global SID "Si"”. In the context of SR-MPLS this means (to me) that the incoming packet is a labeled packet and its top label matches the global SID “Si”.

b.    However, the example for PUSH operation in the next para of this section is the case of an (unlabeled) IP packet with the destination address covered by the IP prefix for which “Si” has been assigned.

c.    From my POV:

                                         i.    Mapping unlabeled packets to SIDs is indeed out of scope of the draft. Therefore an example of a PUSH operation that is applied to a labeled packet (with the active SID inferred from the top label in the stack) is preferable.

                                        ii.    Valid examples of  PUSH operation applied to a labeled incoming packet can be found in Sections 4.2 or 4.3 of the TI-LFA<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=jbH0DSYYo2UYymWZrlvAt7qUWVXsYKuCtMiEyoe-DWE&e=> draft

#Ahmed: I do not understand your concern here:)
[[Sasha]] I think it is pretty clear: can you provide an example of a PUSH operation applied to a labeled packet instead of your current example?

Nits:

1.    I concur with Adrian regarding numerous nits he has reported in his WG LC Comment<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_spring_FRhO2lgR8r4VlKP2ZN2dZwHU5BY&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=I_4gDFhcjR_1npqKUQDHThsejUMgJy3WlLzC90poR1w&e=>. I would like to thank Adrian for an excellent review that have saved me lots of hard work.
#Ahmed: I also agree that Adrian's review is exceptional. I believe I addressed all his comments in the latest version.

2.    In addition, I’d like to report the following nits:

a.    Ti-LFA in Section 2.11.1 should be TI-LFA (as in the TI-LFA<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=jbH0DSYYo2UYymWZrlvAt7qUWVXsYKuCtMiEyoe-DWE&e=> draft)
#Ahmed: Already done in the latest version[[Sasha]] OK

b.    TI-LFA draft is referenced in the text of Section 2.11.1, but there is no matching reference in the “References” section (probably, Informational)
#Ahmed: Already done in the latest version[[Sasha]] OK

c.    “zero Algorithm” in Section 2.5 (immediately above Section 2.5.1) must be replaced with “default algorithm”. Similarly, “non-zero Algorithm” should be replaced with “non-default algorithm”
#Ahmed: Will be done in the next version[[Sasha]]  OK

3.    I think that RFC 3443 and RFC 5332 should be listed as Normative references in this draft while RFC 5331 and RFC 8277 should be listed as Informative references. This would improve the readability of the draft without any impact on its advancement.

#Ahmed RFC5331 describes upstream label assignment. As you mentioned above (and I will modify the draft to indicate that) SR-MPLS behavior is similar to downstream label assignment. RFC 3443 describes TTL behavior. This is an MPLS forwarding behavior. As mentioned in the draft, SR-MPLS does not modify at the MPLS forwarding behavior
[[Sasha]] Regarding RFC 5331 – you may skip this reference if you state (as discussed below) that SR-MPLS only allocates labels from the per-platform label space. Regarding RFC 3443 – I do not think that you can fully avoid discussion of Uniform and Pipe/Short Pipe models, and therefore you will need this reference.

Hopefully, these comments will be useful.
#Ahmed: They are certainly quite useful. Thanks a lot

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

___________________________________________________________________________

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.
___________________________________________________________________________

___________________________________________________________________________

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.
___________________________________________________________________________

___________________________________________________________________________

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.
___________________________________________________________________________

___________________________________________________________________________

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: Shraddha Hegde <[email-masked]>
Date: Mon, 19 Nov 2018 04:37:24 +0000

Hi all,

I am preparing the shepherd write-up and noticed that the topic in below e-mail thread is an
Open item. My personal opinion is to add a new section to this draft to address below cases
> more than one node advertising the same IPv4/6 PREFIX and both have the same prefix-SID value with "N" flag
> where an anycast prefix is advertised with a prefix-SID sub-TLV by some (but not all) of the nodes that advertise that prefix.

This draft is addressing incoming label collision and resulting behavior and also describes other aspects like different SIDs for same prefix so it seems reasonable to add above two cases to this draft.
WG members, if you have an opinion, pls respond on the list.

Rgds
Shraddha
From: Alexander Vainshtein <[email-masked]>
Sent: Sunday, November 4, 2018 9:37 PM
To: Ahmed Bashandy <[email-masked]>
Cc: [email-masked]; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; Jonathan Hardwick ([email-masked]) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Shraddha Hegde <[email-masked]>
Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

Ahmed,
Your reference to these being just control plane issues and therefore not related to SR-MPLS is not valid - because the drafts dealing with the SR control plane to which you refer in this draft are strictly MPLS-oriented: they define how to advertise SID labels or indices that are translated into SID labels, and neither of these mechanisms is relevant fore SRV6 IMHO. (I do not have to remind you that a draft that defines SRV6 extensions for ISIS<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbashandy-2Disis-2Dsrv6-2Dextensions_-3Finclude-5Ftext-3D1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=ko-3eF8yySF1exH64SoeyEP0ett4gjsHmmOCvj9zCvQ&s=_AZSiqmTUTMKFS9DAqboueo_GnvvAcFxARWF820HnTA&e=> exists, and deals with other issues).
My 2c,
Sasha

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

From: Ahmed Bashandy [mailto:[email-masked]]
Sent: Sunday, October 28, 2018 1:01 AM
To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]' <[email-masked]<mailto:[email-masked]>>; [email-masked]' <[email-masked]<mailto:[email-masked]>>; Jonathan Hardwick ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

Thanks for the comments

“

Rgds
Shraddha

Ahmed hi!

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

Thanks for the reply

See inline

Ahmed

.

Regards,
Sasha

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

Ahmed, and all,

Regards,
Sasha

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

See inline #Ahmed

Ahmed

Regards,
Sasha

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

Hello,

Summary:

Comments:

Major Issues: None found
#Ahmed: thanks a lot

c.    From my POV:

                                        ii.    Mirror SID

6.    Node SIDs in SR-MPLS:

7.    SRGB Size in SR-MPLS:

c.    From my POV:

Nits:

Regards,
Sasha

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

---

From: Przemyslaw Krol <[email-masked]>
Date: Mon, 19 Nov 2018 08:01:26 -0800

Hi Shraddha

I think this would be very helpful.

pk

On Sun, Nov 18, 2018 at 8:39 PM Shraddha Hegde <[email-masked]> wrote:

> > where an anycast prefix is advertised with a prefix-SID sub-TLV by some
> (but not all) of the nodes that advertise that prefix.
>
>
>
> This draft is addressing incoming label collision and resulting behavior
> and also describes other aspects like different SIDs for same prefix so it
> seems reasonable to add above two cases to this draft.
>
> *From:* Alexander Vainshtein <[email-masked]>
> *Sent:* Sunday, November 4, 2018 9:37 PM
> *To:* Ahmed Bashandy <[email-masked]>
> *Cc:* [email-masked]; [email-masked]' <[email-masked]>; '
> [email-masked]' <[email-masked]>; Jonathan Hardwick (
> [email-masked]) <[email-masked]>;
> [email-masked]; [email-masked];
> [email-masked]; Shraddha Hegde <
> [email-masked]>
> *Subject:* RE: RtgDir Early review:
> draft-ietf-spring-segment-routing-mpls-13
>
>
>
> Ahmed,
>
> I fully agree that advertising the same prefix SID as the Node SID by two
> different nodes in the SR domain is “a clear violation of the SR
> architecture RFC (8402)”.
>
> But I do not think that the SR-MPLS draft can silently ignore this
> violation just because it “is not an incoming label collision”.
>
> The same applies to the controversy in advertising at the same prefix as
> Anycast by some nodes but not as Anycast (or even as a Node SID) by some
> other nodes.
>
> Your reference to these being just control plane issues and therefore not
> related to SR-MPLS is not valid - because the drafts dealing with the SR
> control plane to which you refer in this draft are strictly MPLS-oriented:
> they define how to advertise *SID labels* or *indices* that are
> translated into *SID labels*, and neither of these mechanisms is relevant
> fore SRV6 IMHO. (I do not have to remind you that a draft that defines SRV6
> extensions for ISIS
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbashandy-2Disis-2Dsrv6-2Dextensions_-3Finclude-5Ftext-3D1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=ko-3eF8yySF1exH64SoeyEP0ett4gjsHmmOCvj9zCvQ&s=_AZSiqmTUTMKFS9DAqboueo_GnvvAcFxARWF820HnTA&e=>
> exists, and deals with other issues).
>
> My 2c,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> *From:* Ahmed Bashandy [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Sunday, October 28, 2018 1:01 AM
> *To:* Shraddha Hegde <[email-masked]>; Alexander Vainshtein <
> [email-masked]>
> *Cc:* [email-masked]; [email-masked]' <[email-masked]>; '
> [email-masked]' <[email-masked]>; Jonathan Hardwick (
> [email-masked]) <[email-masked]>;
> [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: RtgDir Early review:
> draft-ietf-spring-segment-routing-mpls-13
>
>
>
> Thanks for the comments
>
> While it is a clear violation of the SR architecture RFC (8402), more than
> one node advertising the same IPv4/6 PREFIX and both have the same
> prefix-SID value with "N" flag is not an incoming label collision because
> the label is associated with the same FEC, which is the prefix.
>
> Hence handling such violation is not an SR-MPLS problem because there is
> no incoming label collision and hence it it is outside the scope of this
> draft
>
>
>
> The second issue is which SID to choose for an SR-policy (be it a policy
> for TE, ti-lfa, uloop avoidance, security,..., etc). That is strictly a
> control layer functionality and is not specific to SR-MPLS. Hence it is
> outside the scope of this draft
>
>
>
> The third issue is the case where an anycast prefix is advertised with a
> prefix-SID sub-TLV by some (but not all) of the nodes that advertise that
> prefix. Again this is not an incoming label collision because the label is
> associated with a single FEC, which is the anycast prefix.
>
>
>
> There is an anomaly here and IMO, this draft should address how to handle
> this anomaly and whether TI-LFA and other
>
> Another slight variation of this case is a scenario where A and B both
> advertise a prefix 1.1.1.1 and A assigns a Node-Sid
>
> *From:* Alexander Vainshtein <[email-masked]>
> <[email-masked]>
> *Sent:* Thursday, July 19, 2018 10:05 PM
> *To:* Ahmed Bashandy <[email-masked]> <[email-masked]>
> *Cc:* [email-masked]; [email-masked]' <[email-masked]> <[email-masked]>; '
> [email-masked]' <[email-masked]> <[email-masked]>;
> Jonathan Hardwick ([email-masked])
> <[email-masked]> <[email-masked]>;
> Shraddha Hegde <[email-masked]> <[email-masked]>;
> [email-masked]; [email-masked];
> [email-masked]
> *Subject:* RE: RtgDir Early review:
> draft-ietf-spring-segment-routing-mpls-13
>
>
>
> Ahmed hi!
>
> You seem to ignore the difference between SR-MPLS and SRv6 with regard to
> the life span of prefix SIDs in general and Node SIDs in particular. From
> my POV this difference should be discussed in the draft.
>
> So it seems that we can only “agree to disagree” on the need to say
> something specific about Node SIDs in the draft, and let the WG to decide
> what to do about it.
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> *From:* Ahmed Bashandy [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Thursday, July 19, 2018 7:13 PM
> *To:* Alexander Vainshtein <[email-masked]>
> *Cc:* [email-masked]; [email-masked]' <[email-masked]>; '
> [email-masked]' <[email-masked]>; Jonathan Hardwick (
> [email-masked]) <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: RtgDir Early review:
> draft-ietf-spring-segment-routing-mpls-13
>
>
>
> Thanks for the reply
>
> See inline
>
> Ahmed
>
>
>
> 1.       Node SIDs (and, in general, Prefix SIDs) in MPLS-SR are
> different from the same in SRv6 because they require explicit configuration
> action by the operator of SR domain. I.e., it is not enough for a node to
> own some /32 or /128 prefix that is advertised by IGP. The operator must
> explicitly configure the node to use such a prefix as  Node SID and to
> assign to it a specific index that is unique in the SR domain. From my POV,
> this difference alone would qualify Node SIDs as a topic to be discussed in
> the MPLS-SR Architecture
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dmpls-2D14&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=q6djpRXlamUzKZlGIuXTtBcsnwevHwddqvStZrSFMnE&e=>
> draft.
>
> #Ahmed: I disagree with your POV. From the forwarding plane perspective it
> does not make any difference whether a the label at the top of an MPLS
> packet (representing the prefix-SID) identifies a node or not. So from the
> SR-mpls forwarding point of view there is no difference between a
> prefix-SID and a node-SID. If there is any place in the SR-mpls draft where
> there is a need to handle a node-SID different from a prefix SID, it would
> be great to point it out
>
> 2.      In addition, quite a few constructs associated with SR-MPLS
> implicitly assume that each node in the SR-MPLS domain is assigned with at
> least one Node SID. One example can be found in the TI-LFA
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=jbH0DSYYo2UYymWZrlvAt7qUWVXsYKuCtMiEyoe-DWE&e=>
> draft. This draft says in Section 4.2:
>
>
> 4.2
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04-23section-2D4.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=sAi3KCWUwGS3D93t8ic64W_46xm9y8Oacs7ozcAweS8&e=>.
> The repair node is a PQ node
>
>
>
>
>
> In the scope of this section, the repair node is not adjacent to the PLR,
> and therefore, to the best of my understanding,  “a single node segment
> to the repair node” can be only the Node SID of the repair node. Since
> repair nodes are computed dynamically, this entire scheme depends on all
> nodes in the MPLS=SR domain  having at least one Node SID each
>
> #Ahmed: The choice of the SID to identify an intermediate or exit node(s)
> in an SR-policy is a control plane behavior, irrespective of reason such
> policy is created (be it ti-lfa explicit path, uloop avoidance explicit
> path, or some SR-TE explicit path). SR-Policy as well as Ti-LFA and uloop
> avoidance are handled in separate drafts. So just like the response to your
> previous comment, from forwarding plane perspective it does not make any
> difference whether the label at the top of an MPLS packet identifies a
> single or multiple nodes.
>
> .
>
>
>
> *From:* Alexander Vainshtein
> *Sent:* Wednesday, July 11, 2018 12:02 PM
> *To:* Ahmed Bashandy <[email-masked]> <[email-masked]>
> *Cc:* [email-masked]; [email-masked]' <[email-masked]> <[email-masked]>; '
> [email-masked]' <[email-masked]> <[email-masked]>;
> Jonathan Hardwick ([email-masked])
> <[email-masked]> <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* RE: RtgDir Early review:
> draft-ietf-spring-segment-routing-mpls-13
>
>
>
> Ahmed, and all,
>
> Please see *inline below* my position on each of them.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> *From:* Ahmed Bashandy [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Wednesday, July 11, 2018 4:42 AM
> *To:* Alexander Vainshtein <[email-masked]>;
> [email-masked];
> [email-masked]
> *Cc:* [email-masked]; [email-masked]' <[email-masked]>; '
> [email-masked]' <[email-masked]>; Jonathan Hardwick (
> [email-masked]) <[email-masked]>;
> [email-masked]; [email-masked]
> *Subject:* Re: RtgDir Early review:
> draft-ietf-spring-segment-routing-mpls-13
>
>
>
> ------------------------------
>
> *From:* Alexander Vainshtein
> *Sent:* Sunday, June 10, 2018 10:43:52 AM
> *To:* [email-masked];
> [email-masked]
> *Cc:* [email-masked]; [email-masked]; [email-masked]'; '
> [email-masked]'; Jonathan Hardwick ([email-masked]);
> [email-masked]
> *Subject:* RE: RtgDir Early review:
> draft-ietf-spring-segment-routing-mpls-13
>
>
>
> *From:* Alexander Vainshtein
> *Sent:* Friday, June 8, 2018 5:43 PM
> *To:* [email-masked]' <[email-masked]>
> <[email-masked]>; '
> [email-masked]'
> <[email-masked]>
> <[email-masked]>
> *Cc:* [email-masked]' <[email-masked]> <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]'
> <[email-masked]> <[email-masked]>
> *Subject:* RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13
>
>
>
>
>
> Hello,
>
> I have been selected to do a routing directorate “early” review of this
> draft:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dmpls_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=Cxbaaf9U0kj6_meVSobSkRLQW1SwI8MJvgHpuYp0QOM&e=>
>
>
>
> The routing directorate will, on request from the working group chair,
> perform an “early” review of a draft before it is submitted for publication
> to the IESG. The early review can be performed at any time during the
> draft’s lifetime as a working group document. The purpose of the early
> review depends on the stage that the document has reached. As this document
> is currently in the WG Last call, my focus for the review was to determine
> whether the document is ready to be published. Please consider my comments
> along with the other working group last call comments.
>
>
>
> For more information about the Routing Directorate, please see ​
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=6pnI7l82ewwzoxgOXqTKrbKuQidt6-KBsZdsXFnoQCg&e=>
>
>
>
> *Document*: draft-ietf-spring-segment-routing-mpls-13
>
> *Reviewer*: Alexander (“Sasha”) Vainshtein (
> [email-masked])
>
> *Review Date*: 08-Jun-18
>
> *Intended Status*: Proposed Standard.
>
>
>
> *Summary*:
>
>
>
> I have some minor concerns about this document that I think should be
> resolved before it is submitted to the IESG.
>
>
>
> *Comments*:
>
>
>
> I consider this draft as an important  companion document to the Segment
> Routing Architecture
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D15&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=iJShh7e7yyVkt44v1O5pyCOMfHCpAvfBNGgFr5lk130&e=>
> draft that, ideally, should augment definitions of the Segment Routing (SR)
> notions and constructs given there with details specific for the SR
> instantiation that uses  the MPLS data plane (SR-MPLS).  Many issues raised
> in my review reflect either gaps that should be, but have not been, closed,
> or inconsistencies between the two drafts.
>
>
>
>
>
> Since RFC 8287
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8287&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=y7jp3UYNTtcmm9HOulzqPTrMURTrsMiO26rWlNZN5Ws&e=>
> is already published as a Standards Track RFC, I expect such augmentation
> to be backward compatible with this document (or to provide clear
> indications of required updates to this document). And I include the MPLS
> WG into distribution list.
>
>
>
> This draft was not easy reading for me. In particular, the style of
> Section 2.5 that discusses at length and in some detail multiple “corner
> cases” resulting, presumably, from misconfiguration, before it explains the
> basic (and relatively simple) “normal” behavior, looks problematic to me.
>
>
>
> *Major Issues*: None found
>
> #Ahmed: thanks a lot
>
>
>
> *Minor Issues*: Quite a few but, hopefully, easy to resolve.
>
>
>
> 1.    *Encapsulation of SR-MPLS packets*:
>
> a.    RFC 3032 (referenced by the draft) and RFC 5332 (*not mentioned in
> the draft*) depend two encapsulations of labeled packets - one for
> Downstream-allocated labels and another for Upstream-allocated ones.
>
> #Ahmed: RFC5332 is for multicast. As mentioned in Section 6 of
> draft-ietf-spring-segment-routing-15, multicast is outside the scope of SR.
> Hence the RFC was not referred to in the SR-MPLS draft
>
> *[[Sasha]] I would be satisfied with this response, would it not be for
> the following text I see in Section 2.2 of the* *SR Policy Architecture*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dpolicy-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=4f0H68LTvkp7N-bYTVLOhWqiEbHaCsOQR1z_Qzz3Wf4&e=>
> *draft:*
>
> *This looks to me as being very much multicast in SR, and, unless you want
> to say that it is limited to SRv6, makes my question relevant IMHO.*
>
> b.    From my POV the ST-MPLS only uses Downstream-allocated labels – but
> I expect the draft to state that explicitly, one way or another. (If
> Upstream-allocated labels are relevant for SR-MPLS, I would see it as a
> major gap, so I hope that this is not the case).
>
> *[[Sasha]] This is quite unambiguous and, once added, would resolve my
> comment in full – the previous comment notwithstanding. In particular, it
> would imply that even labels representing BSIDs of a SR Replication
> policies will be downstream-allocated. *
>
>
>
> 2.    *Label spaces in SR-MPLS*:
>
> a.    RFC 3031 (referenced by the draft) defines per-platform and
> per-interface label spaces, and RFC 5331 (*not mentioned in the draft*)
> adds context-specific label spaces and context labels.
>
>                                          i.    Labels representing all
> kinds of SIDs mentioned in the draft MUST be allocated from the
> per-platform label space only
>
>                                         ii.    At the same time,
> instantiation of Mirror Segment IDs defined in Section 5.1 of the Segment
> Routing Architecture draft using MPLS data plane clearly calls for context
> labels and context-specific label spaces
>
> #Ahmed: I will add a statement to section 2.2 to say that the it is
> per-platform. Regarding the function "mirroring", SR attaches a *function*
> to each SID. The "mirroring" function is already described in Section 5.1
> of draft-ietf-spring-segment-routing and is not specific to the MPLS
> forwarding plane. Hence there is no need to re-mention it here because this
> document is trying to be as specific as possible to the MPLS forwarding
> plane. General functions attached to SID are described in the segment
> routing architecture document or future documents. Furture documents
> proposing new SR function must be as specific and clear as possible
>
> *[[Sasha]] Looks OK to me.*
>
>
>
> 3.    *SR-MPLS and hierarchical LSPs*:
>
> a.    SR LSPs that include more than one segment are hierarchical LSPs
> from the POV of the MPLS data plane. Therefore some (possibly, all) of the
> models for handling TTL and TC bits that have been defined in RFC 3443 (*not
> mentioned in the draft*) should apply to SR-MPLS
>
> b.    RFC 8287 (*not referenced in the draft*) specifically discussed
> operation of the LSP Traceroute function for SR LSPs in the case when
> Pipe/Short Pipe model for TTL handling is used
>
> c.    I expect the draft to provide at least some guidelines regarding
> applicability of each specific model defined in RFC 3443 (separately for
> TTL and TC bits) to SR-MPLS.
>
> #Ahmed: BY design, the instantiation of SR over the MPLS forwarding plane
> (and hence this draft) does not modify the MPLS forwarding plan behavior as
> it is mentioned in the first sentence in Section 1. So the TTL behavior
> specified in rfc3443 is already implied and there is no need to re-mention
> it here just like all aspects of MPLS forwarding. RFC8287 is OAM-specific.
> SR-OAM is handled in a separate document so is outside the scope of this
> draft
>
> *[[Sasha]] Unfortunately I do not think this is good enough. Let me ask a
> specific question reflecting my concerns:*
>
> *The head-end node sends SR-MPLS packets across a path defined by an
> ordered set of SIDs with more than one SID in the list. Each SID is
> represented by a label stack entry (LSE) in the MPLS label stack, and the
> label field in each LSE is the label that matches the corresponding SID.
> However, each LSE also includes the TTL and TC fields. How does the
> head-end node set these fields in each of the LSEs following the top one?
> This clearly depends on the model (Uniform vs. Pipe/Short Pipe) implemented
> in each node that that performs Next operation on the packet along the path
> – but the head-end node usually is not aware of that. *
>
> *RFC 8287 is relevant as an example here IMHO because it recommends the
> following setting of TTL in Traceroute packets:*
>
> -          *Set the TTL of all the labels above one that represents the
> segment you are currently tracing to maximum*
>
> -          *Set the TTL of the label one that represents the segment you
> are currently tracing to the desired value (to be incremented until end of
> segment is reached*
>
> -          *Set the TTL of all the labels below one that represents the
> segment you are currently tracing to 0.*
>
> *I expect the draft to provide some recommendations for traffic (non-OAM)
> packets as well.*
>
>
>
> 4.    *Inferring network layer protocol in SR-MPLS*:
>
> a.    I wonder if the draft could provide any details on the situation
> when a label that represents some kind of SID is the bottom-of-stack label
> to be popped by the egress LER
>
> *[[Sasha]] NEXT function is mentioned in several places in the document.
> Can you please point to the specific text that is relevant for my question?*
>
>
>
> b.    For the reference, RFC 3032 says that “the identity of the network
> layer protocol  must be inferable from the value of the label which is
> popped from  the bottom of the stack, possibly along with the contents  of
> the network layer header itself”
>
>                                          i.    IS-IS is used for
> distributing both IPv4 and IPv6 reachability in a given domain
>
>                                         ii.    An IS-IS adjacency over
> some dual-stack link is established, and a single Adj-SID for this
> adjacency is advertised
>
>                                        iii.    The node that has assigned
> and advertised this Adj-SID receives a labeled packet with the label
> representing this Adj-SID being both the top and bottom-of-stack label
>
>                                        iv.    The implementers must be
> given unambiguous instructions for forwarding the unlabeled packet via the
> dual-stack link as an Ipv4 or an IPv6 packet.
>
> #Ahmed: If you take a look at the SR-ISIS , SR-OSPFv2 and SR-OSFv3 drafts,
> you will see all 3 protocol advertise different adj-SIDS for IPv4 next-hop
> and IPv6 next-hop. For example, ISIS uses the "F-Flag" (section 2.2.1 in
> draft-ietf-isis-segment-routing-extensions-18) to specify whether the
> adj-SID is for IPv4 and IPv6. Similarly, the SR-ISIS draft attaches a
> prefix-SID to the prefix advertisement and hence implies the identity of
> the protocol underneath the bottom most label. For any other "function"
> attached to a SID, it is part of the specification of this function to
> describe what happens when the SID is represented by a label in the MPLS
> forwarding plane and this label is the bottom most label
>
> *[[Sasha]] OK, got it. This issue is resolved.*
>
>
>
> 5.    *Resolution* *of Conflicts*: Are the
>
> b.    If they are mandatory to implement, are they also mandatory to
> deploy, or can the operators simply treat any detected conflict as
> requiring human intervention and preventing normal operation of SR-MPLS?
>
> #Ahmed: They are recommended. I will modify the paragraph after the first
> 3 bullets in Section 2.5 to say that it is recommeded.
>
> *[[Sasha]] OK. However, it would be nice if you could refer separately for
> “RECOMMENDED to implement” and “RECOMMENDED to deploy”.  The latter
> probably requires a configuration knob for enabling conflict resolution
> rules (if they are implemented). *
>
> c.    For the reference, the IETF capitalized MUST appears just in a few
> places in Section 2.5, and each appearance has very narrow context:
>
>                                          i.    For MCCs where the
> "Topology" and/or "Algorithm" fields are not defined, the numerical value
> of zero MUST be used for these two fields
>
>                                         ii.    If the same set of FECs
> are attached to the same label "L1", then the tie-breaking rules MUST
> always select the same FEC irrespective of the order in which the FECs and
> the label "L1" are received. In other words, the tie-breaking rule MUST be
> deterministic.
>
>                                        iii.    An implementation of
> explicit SID assignment MUST guarantee collision freeness on the same router
>
> From my POV, it is not possible to infer the answer to my question from
> these statements. Some explicit statement is required.
>
> #Ahmed: I agree with you POV and as mentioned in my reply to items (a) and
> (b), I will modify the paragraph to say that it is RECOMMENDED to answer
> you questions in items (a) and (b)
>
> d.    The tie-breaking rules in section 2.5.1 include some specific
> values for encoding FEC types and address families – but these values are
> not supposed to appear in any IANA registries (because the draft does not
> request any IANA actions). Can you please clarify what is so special about
> these values?
>
> #Ahmed: There is no significance to the values but there is a significance
> to the order among them. I will modify the text to clarify that
>
> *[[Sasha]] OK. *
>
>
>
> e.    I also doubt that comparison of FECs that represent IPv4 and IPv6
> prefix SIDs makes much sense (for conflict resolution or else), because,
> among other things, there are valid scenarios when an IPv4 /32 prefix is
> embedded in an IPv6 /128 one.
>
> #Ahmed: A prefix-SID is assigned to a prefix. An IPv6 prefix that embeds
> an IPv4 prefix is different from the IPv4 prefix. The specifications of SR
> extensions to ISIS, OSPFv2, OSPFv3, and BGP treat IPv4 and IPv6 prefixes
> separately, including the IPV6 prefixes with embedded IPv4 ones. Besides
> not all IPv6 prefixes embed IPv4 prefix in them. Hence the distinction
> between IPv4 and IPv6 prefixes is quite clear
>
> *[[Sasha]] My concern was mainly about IPv4-mapped IPv6 addresses. Quoting
> from RFC 4291:*
> *2.5.5.2*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4291-23section-2D2.5.5.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=I14XA8I9Ruw5aBj5er_OVbvADz1sb9ZLFBGaZZlJJJ4&e=>*.
> IPv4-Mapped IPv6 Address*
>
>
>
>
>
> *From my POV this means that a /128 prefix associated with an IPv4-mapped
> IPv6 address and a /32 prefix associated with the IPv4 address that was
> mapped to this IPv6 address represent the same entity. This understanding
> fully matches usage of IPv4-mapped IPv6 addresses as BGP Next Hops of
> VPN-IPv6 addresses defined in RFC 4798. However, the comparison rules you
> have defined will treat them as two different prefixes.  I wonder if these
> rules, in the case of a conflict, could result in preferring the IPv6
> prefix to an IPv4 one and therefore loosing MPLS connectivity for the
> ingress PE of a 6VPE service to its egress PE?*
>
>
>
> f.     Section 2.5.1 defines 3 types of SR-MPLS FECs, but I am not sure
> all SID types defined in the Segment Routing Architecture draft can be
> unambiguously mapped to one of these types. Problematic examples include at
> least the following:
>
> Explicit mapping of SID types to SR-MPLS FEC types would be most useful
> IMO. If some SID types cannot be mapped to SR-MPLS FECs, this must be
> explicitly stated in the draft.
>
> #Ahmed:
> *[[Sasha]] OK*
> Mirror SID is a type of binding-SID as mentioned in Section 5.1 in the SR
> architecture draft (draft-ietf-spring-segment-routing-15). Also as
> described in Section 2.4 draft-ietf-isis-segment-routing-extensions-18
> (also see the equivalent in the OSPFv2 and OSPFv3 draft), a binding SID is
> identified by a prefix. Hence it is covered by the type "(Prefix, Routing
> Instance, Topology, Algorithm)"
>
> *[[Sasha]] I respectfully disagree. There is definitely no mention of
> Algorithm in the definition of the Mirror SID. *
>
>
>
> 6.    *Node SIDs in SR-MPLS*:
>
> a.    Node SIDs are explicitly defined and discussed in the Segment
> Routing Architecture draft but are not mentioned even once in this draft
>
> b.    AFAIK, the common implementation practice today includes assignment
> of at least one Node SID to every node in the SR-MPLS domain
>
> c.    Is there a requirement to assign at least one Node SID per {routing
> instance, topology, algorithm} in SR-MPLS? If not, can the authors explain
> expected behavior of such a node? (See also my comment about routing
> instances below).
>
> #Ahmed: A Node-SID is a special case of prefix-SID. So there nothing
> specific about it from the MPLS forwarding plane point of view. Similarly
> from a standard tracks draft point of view, there is no requirement to
> assign a SID to every prefix just like there is no requirement to bind
> every prefix to an LDP label. Common and/or recommended practices or
> description of deployment scenarios are more befitting to BCP or
> informational drafts. This draft is a standards track draft
>
> *[[Sasha]] Well, you’ve just said that conflict resolution rules are
> RECOMMENDED, and this is quite common in the Standards Track RFCs. *
>
>
> If a {routing instance, topology, algorithm} is not assigned a SID, then
> this FEC is totally irrelavant to this draft and hence describing how a
> node treats it is totally outside the scope of this draft
>
> *[[Sasha]] AFAIK, neither of the SR extension drafts for IGPs mention
> routing instances that can be associated with the prefix, so I think that
> your reference to it is incorrect.*
>
> *What’s more I suspect that Node SIDs represent the most used special case
> of Prefix SIDs with Anycast SIDs being quite behind.  Therefore some
> recommendation pertaining to the usage of Node SIDs would be very much in
> place IMHO. *
>
>
>
> 7.    *SRGB Size in SR-MPLS*:
>
> a.    The draft correctly treats the situation when an index assigned to
> some global SID cannot be mapped to a label using the procedure in Section
> 2.4 as a conflict.
>
> b.    At the same time the draft does not define any minimum size of SRGB
> (be it defined as a single contiguous block or as a sequence of such
> blocks) that MUST be implemented by all SR-capable nodes
>
> c.    I suspect that lack of such a definition could be detrimental to
> interoperability of SR-MPLS solutions. AFAIK, the IETF has been following,
> for quite some time, a policy that some reasonable MUST-to-implement
> defaults should be assigned for all configurable parameters exactly in
> order to prevent this.
>
> #Ahmed: This document specifies how the SRGB is used and the behavior of
> routers when a prefix-SID index maps to a label inside and/or outside the
> SRGB. The actual size of the SRGB is a task in partitioning the label
> space, which is very specific to a particular deployment scenario. So IMO
> it is outside the scope of a standards track document. Now that SR-MPLS is
> deployed in many places, I expect the community to gain sufficient
> experience to recommend (or not recommend) a particular minimum/maximum
> size for the SRGB is some future informational or BCP draft/RFC
>
> *[[Sasha]] My reading of your response is that minimum size of SRGB is an
> issue for future study. Can you please just add this to the draft?*
>
>
>
> 8.    *Algorithms and Prefix SIDs*:
>
> a.    The draft mentions Algorithms (as part of SR-MPLS Prefix FEC) in,
> but it does not explicitly link them with the Prefix-SID algorithms defined
> in section 3.1.1 of the Segment Routing Architecture draft
>
> #Ahmed: I will just add the reference [I-D.ietf-spring-segment-routing]
> right beside the first time "Algorithm" is mentioned
>
> *[[Sasha]] OK*
>
>
>
> b.    From my POV, the draft should explicitly state that the default
> Prefix-SID algorithm MUST be implemented in all SR-MPLS-compliant routers.
>
> #Ahmed: The specification of what path calculation method should or must
> be supported is a routing protocol property not a forwarding plane
> property. In fact, the choice of a path calculation method or algorithm is
> completely orthogonal to the routed protocol. Hence mandating the support
> of a particular routing algorithm is beyond the scope of this document.
>
> *[[Sasha]] OK*
>
>
>
> c.    The Segment Routing Architecture draft states (in section 3.1.3)
> that “Support of multiple algorithms applies to SRv6”. But neither draft
> states whether multiple algorithms apply to SR-MPLS. Can you please clarify
> this point?
>
> #Ahmed: The last paragraph of Section 3.1.2 titled SR-MPLS in
> draft-ietf-spring-segment-routing-15 discusses the support of multiple
> algorithms. So it is implied that the concept of algorithm applies to
> SR-MPLS. Hence there is no need to re-mention it here
>
> *[[Sasha]] The paragraph to which you refer only says that if a packet
> with the active Prefix-SID that is associated with a specific algorithm is
> received by a node that does not support this algorithm, this packet will
> be discarded. If this is the only type of support for multiple algorithms
> SR provides, it is not very useful IMHO**. *
>
>
>
> 9.    *Routing instances and the context for Prefix-SIDs*:
>
> a.    The Segment Routing Architecture draft states in Section 3.1 that
> the “context for an IGP-Prefix segment includes the prefix, topology, and
> algorithm”
>
> b.    This draft seems to define (in section 2.5) the context for the
> Prefix SID as “Prefix, Routing Instance, Topology, Algorithm” where ”a
> routing instance is identified by a single incoming label downloader to
> FIB” (but the notion of the label downloader to FIB is not defined).
>
> d.    At the very least I would expect alignment between the definitions
> of context for the Prefix-SID between the two drafts. Preferably, the
> definition given in the Segment Routing Architecture draft should be used
> in both drafts.
>
> #Ahmed: The context of the section 2.5 is limited to the resolution of
> local label collision. The use of "routing instance" in section 2.5 is just
> there for tie-breaking if there is local label collision.
>
> *[[Sasha]] I have already mentioned that “routing instances” are not
> defined in any the drafts dealing with SR Extensions for IGPs. So I do not
> understand how the conflict resolution procedure is supposed to use this.
> And in any case the difference between two definitions of the context of
> Prefix-SID requires some explanation.*
>
>
>
> 10. *Example of PUSH operation in Section 2.10.1*:
>
> a.    The first para of this section begins with the sentence “Suppose an
> MCC on a router "R0" determines that PUSH or CONTINUE   operation is to be
> applied to an incoming packet whose active SID is the global SID "Si"”. In
> the context of SR-MPLS this means (to me) that the incoming packet is a
> labeled packet and its top label matches the global SID “Si”.
>
> b.    However, the example for PUSH operation in the next para of this
> section is the case of an (unlabeled) IP packet with the destination
> address covered by the IP prefix for which “Si” has been assigned.
>
> c.    From my POV:
>
>                                          i.    Mapping unlabeled packets
> to SIDs is indeed out of scope of the draft. Therefore an example of a PUSH
> operation that is applied to a labeled packet (with the active SID inferred
> from the top label in the stack) is preferable.
>
>                                         ii.    Valid examples of  PUSH
> operation applied to a labeled incoming packet can be found in Sections 4.2
> or 4.3 of the TI-LFA
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=jbH0DSYYo2UYymWZrlvAt7qUWVXsYKuCtMiEyoe-DWE&e=>
> draft
>
>
>
> *[[Sasha]] I think it is pretty clear: can you provide an example of a
> PUSH operation applied to a labeled packet instead of your current example?*
>
>
>
> *Nits*:
>
> 1.    I concur with Adrian regarding numerous nits he has reported in his WG
> LC Comment
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_spring_FRhO2lgR8r4VlKP2ZN2dZwHU5BY&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=I_4gDFhcjR_1npqKUQDHThsejUMgJy3WlLzC90poR1w&e=>.
> I would like to thank Adrian for an excellent review that have saved me
> lots of hard work.
>
> #Ahmed: I also agree that Adrian's review is exceptional. I believe I
> addressed all his comments in the latest version.
>
> a.    Ti-LFA in Section 2.11.1 should be TI-LFA (as in the TI-LFA
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=jbH0DSYYo2UYymWZrlvAt7qUWVXsYKuCtMiEyoe-DWE&e=>
> draft)
>
> #Ahmed: Already done in the latest version*[[Sasha]] OK*
>
> b.    TI-LFA draft is referenced in the text of Section 2.11.1, but there
> is no matching reference in the “References” section (probably,
> Informational)
>
> #Ahmed: Already done in the latest version*[[Sasha]] OK*
>
> c.    “zero Algorithm” in Section 2.5 (immediately above Section 2.5.1)
> must be replaced with “default algorithm”. Similarly, “non-zero Algorithm”
> should be replaced with “non-default algorithm”
>
> #Ahmed: Will be done in the next version*[[Sasha]] * OK
>
> 3.    I think that RFC 3443 and RFC 5332 should be listed as Normative
> references in this draft while RFC 5331 and RFC 8277 should be listed as
> Informative references. This would improve the readability of the draft
> without any impact on its advancement.
>
>
>
> #Ahmed RFC5331 describes upstream label assignment. As you mentioned above
> (and I will modify the draft to indicate that) SR-MPLS behavior is similar
> to downstream label assignment. RFC 3443 describes TTL behavior. This is an
> MPLS forwarding behavior. As mentioned in the draft, SR-MPLS does not
> modify at the MPLS forwarding behavior
>
> *[[Sasha]] Regarding RFC 5331 – you may skip this reference if you state
> (as discussed below) that SR-MPLS only allocates labels from the
> per-platform label space. Regarding RFC 3443 – I do not think that you can
> fully avoid discussion of Uniform and Pipe/Short Pipe models, and therefore
> you will need this reference.*
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

-- 
Przemyslaw "PK" Krol |  Strategic Network Engineer ing | [email-masked]

---

From: Alex Bogdanov <[email-masked]>
Date: Mon, 19 Nov 2018 10:47:09 -0800

Hello Shraddha, I think it's an important recommendation to include.

In the absence of another obvious draft/RFC, I would lean towards my
original proposal of including it as a section in
draft-ietf-spring-segment-routing-mpls.

Cheers,

Alex

On Mon, Nov 19, 2018 at 8:02 AM Przemyslaw Krol <pkrol=
[email-masked]> wrote:

>> > where an anycast prefix is advertised with a prefix-SID sub-TLV by
>> some (but not all) of the nodes that advertise that prefix.
>>
>>
>>
>> draft-ietf-spring-segment-routing-mpls.authors@ietf..org; Shraddha Hegde
>> <[email-masked]>
>>
>
>> translated into *SID labels*, and neither of these mechanisms is
>> relevant fore SRV6 IMHO. (I do not have to remind you that a draft that
>> defines SRV6 extensions for ISIS
>> Office: +972-39266302 <+972%203-926-6302>
>>
>> Cell:      +972-549266302 <+972%2054-926-6302>
>>
>> While it is a clear violation of the SR architecture RFC (8402), more
>> than one node advertising the same IPv4/6 PREFIX and both have the same
>> <[email-masked]>
>> *Cc:* [email-masked]; [email-masked]' <[email-masked]> <[email-masked]>;
>> [email-masked]' <[email-masked]> <[email-masked]>;
>> Office: +972-39266302 <+972%203-926-6302>
>>
>> Cell:      +972-549266302 <+972%2054-926-6302>
>>
>> #Ahmed: I disagree with your POV. From the forwarding plane perspective
>> it does not make any difference whether a the label at the top of an MPLS
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04-23section-2D4.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=sAi3KCWUwGS3D93t8ic64W_46xm9y8Oacs7ozcAweS8&e=>..
>> Office: +972-39266302 <+972%203-926-6302>
>>
>> Cell:      +972-549266302 <+972%2054-926-6302>
>>
>> <[email-masked]>
>> *Cc:* [email-masked]; [email-masked]' <[email-masked]> <[email-masked]>;
>> [email-masked]' <[email-masked]> <[email-masked]>;
>> Office: +972-39266302 <+972%203-926-6302>
>>
>> Cell:      +972-549266302 <+972%2054-926-6302>
>>
>> *Cc:* spring@ietf..com <[email-masked]>; [email-masked]; '
>> [email-masked]'; [email-masked]'; Jonathan Hardwick (
>> [email-masked]); [email-masked]
>>
>>
>> Office: +972-39266302 <+972%203-926-6302>
>>
>> Cell:      +972-549266302 <+972%2054-926-6302>
>>
>> *This looks to me as being very much multicast in SR, and, unless you
>> want to say that it is limited to SRv6, makes my question relevant IMHO.*
>>
>> b.    From my POV the ST-MPLS only uses Downstream-allocated labels –
>> but I expect the draft to state that explicitly, one way or another. (If
>>                                        iii.    The node that has
>> assigned and advertised this Adj-SID receives a labeled packet with the
>> label representing this Adj-SID being both the top and bottom-of-stack label
>>
>> #Ahmed: If you take a look at the SR-ISIS , SR-OSPFv2 and SR-OSFv3
>> drafts, you will see all 3 protocol advertise different adj-SIDS for IPv4
>> next-hop and IPv6 next-hop. For example, ISIS uses the "F-Flag" (section
>> 2.2.1 in draft-ietf-isis-segment-routing-extensions-18) to specify whether
>> the adj-SID is for IPv4 and IPv6. Similarly, the SR-ISIS draft attaches a
>> *[[Sasha]] OK. However, it would be nice if you could refer separately
>> for “RECOMMENDED to implement” and “RECOMMENDED to deploy”.  The latter
>> #Ahmed: I agree with you POV and as mentioned in my reply to items (a)
>> and (b), I will modify the paragraph to say that it is RECOMMENDED to
>> answer you questions in items (a) and (b)
>>
>> #Ahmed: There is no significance to the values but there is a
>> significance to the order among them. I will modify the text to clarify that
>>
>> *[[Sasha]] OK. *
>>
>>
>>
>> *[[Sasha]] My concern was mainly about IPv4-mapped IPv6 addresses.
>> Quoting from RFC 4291:*
>> *2.5.5.2*
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools..ietf.org_html_rfc4291-23section-2D2.5.5.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=I14XA8I9Ruw5aBj5er_OVbvADz1sb9ZLFBGaZZlJJJ4&e=>*.
>> <p class="MsoNormal" style="margin:0in;margin-bottom:.0001pt;line-heigh
>>
>> --

-- Alex

Alex Bogdanov | Strategic NetEng | bogdanov@ <[email-masked]> | Cell:
650-314-8196

---

From: Rob Shakir <[email-masked]>
Date: Mon, 19 Nov 2018 20:17:09 -0800

Folks,

Thanks for the feedback here -- given that there were relatively late
changes to this draft in its lifecycle to absorb some of the material on
conflicts, if the consensus is that we need to make additions (it seems to
be pointing that way from this small sample), then I (personally, no chair
hat) think we should not worry too much about needing another (short) WGLC.

The alternatives of having undefined cases, or worse, needing an addendum
document very soon after this is published -- seem much worse than a short
delay.

Cheers,
r.

On Mon, Nov 19, 2018 at 10:47 AM Alex Bogdanov <[email-masked]> wrote:

>>> draft-ietf-spring-segment-routing-mpls.authors@ietf..org; Shraddha
>>> Hegde <[email-masked]>
>>>
>>
>>> I fully agree that advertising the same prefix SID as the Node SID by
>>> two different nodes in the SR domain is “a clear violation of the SR
>>> Your reference to these being just control plane issues and therefore
>>> not related to SR-MPLS is not valid - because the drafts dealing with the
>>> SR control plane to which you refer in this draft are strictly
>>> MPLS-oriented: they define how to advertise *SID labels* or *indices*
>>> that are translated into *SID labels*, and neither of these mechanisms
>>> is relevant fore SRV6 IMHO. (I do not have to remind you that a draft that
>>> There is an anomaly here and IMO, this draft should address how to
>>> handle this anomaly and whether TI-LFA and other
>>>
>>> You seem to ignore the difference between SR-MPLS and SRv6 with regard
>>> to the life span of prefix SIDs in general and Node SIDs in particular.
>>> From my POV this difference should be discussed in the draft.
>>>
>>> In the scope of this section, the repair node is not adjacent to the
>>> PLR, and therefore, to the best of my understanding,  “a single node
>>> segment to the repair node” can be only the Node SID of the repair
>>> node. Since repair nodes are computed dynamically, this entire scheme
>>> depends on all nodes in the MPLS=SR domain  having at least one Node SID
>>> each
>>>
>>> #Ahmed: The choice of the SID to identify an intermediate or exit
>>> node(s) in an SR-policy is a control plane behavior, irrespective of reason
>>> such policy is created (be it ti-lfa explicit path, uloop avoidance
>>> explicit path, or some SR-TE explicit path). SR-Policy as well as Ti-LFA
>>> and uloop avoidance are handled in separate drafts. So just like the
>>> response to your previous comment, from forwarding plane perspective it
>>> does not make any difference whether the label at the top of an MPLS packet
>>> identifies a single or multiple nodes.
>>>
>>> .
>>>
>>>
>>>
>>> *Subject:* RtgDir Early review:
>>> a.    RFC 3032 (referenced by the draft) and RFC 5332 (*not mentioned
>>> in the draft*) depend two encapsulations of labeled packets - one for
>>> #Ahmed: BY design, the instantiation of SR over the MPLS forwarding
>>> plane (and hence this draft) does not modify the MPLS forwarding plan
>>> behavior as it is mentioned in the first sentence in Section 1. So the TTL
>>> behavior specified in rfc3443 is already implied and there is no need to
>>> re-mention it here just like all aspects of MPLS forwarding. RFC8287 is
>>> OAM-specific.  SR-OAM is handled in a separate document so is outside the
>>> scope of this draft
>>>
>>> *[[Sasha]] Unfortunately I do not think this is good enough. Let me ask
>>> a specific question reflecting my concerns:*
>>>
>>> -          *Set the TTL of the label one that represents the segment
>>> you are currently tracing to the desired value (to be incremented until end
>>> of segment is reached*
>>>
>>> *I expect the draft to provide some recommendations for traffic
>>> (non-OAM) packets as well.*
>>>
>>>
>>>
>>> b.    For the reference, RFC 3032 says that “the identity of the
>>> network layer protocol  must be inferable from the value of the label which
>>> is popped from  the bottom of the stack, possibly along with the contents
>>> of the network layer header itself”
>>>
>>> #Ahmed: They are recommended. I will modify the paragraph after the
>>> first 3 bullets in Section 2.5 to say that it is recommeded.
>>>
>>> c.    For the reference, the IETF capitalized MUST appears just in a
>>> few places in Section 2.5, and each appearance has very narrow context:
>>>
>>>                                          i.    For MCCs where the

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 19 Nov 2018 21:19:02 -0800

Sraddha,

Please do so.
Thanks 

Regards,
Jeff

> On Nov 18, 2018, at 20:37, Shraddha Hegde <[email-masked]> wrote:
> 
> Hi all,
> 
>  
> 
> Your reference to these being just control plane issues and therefore not related to SR-MPLS is not valid - because the drafts dealing with the SR control plane to which you refer in this draft are strictly MPLS-oriented: they define how to advertise SID labels or indices that are translated into SID labels, and neither of these mechanisms is relevant fore SRV6 IMHO. (I do not have to remind you that a draft that defines SRV6 extensions for ISIS exists, and deals with other issues).
> 
> My 2c,
> Sasha
>  
> Office: +972-39266302
> Cell:      +972-549266302
> Cc: [email-masked]; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; Jonathan Hardwick ([email-masked]) <[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
> To: Alexander Vainshtein <[email-masked]>
> Cc: [email-masked]; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; Jonathan Hardwick ([email-masked]) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> 1.       Node SIDs (and, in general, Prefix SIDs) in MPLS-SR are different from the same in SRv6 because they require explicit configuration action by the operator of SR domain. I.e., it is not enough for a node to  own some /32 or /128 prefix that is advertised by IGP. The operator must explicitly configure the node to use such a prefix as  Node SID and to assign to it a specific index that is unique in the SR domain. From my POV, this difference alone would qualify Node SIDs as a topic to be discussed in the MPLS-SR Architecture draft.
> 2.      In addition, quite a few constructs associated with SR-MPLS implicitly assume that each node in the SR-MPLS domain is assigned with at least one Node SID. One example can be found in the TI-LFA draft. This draft says in Section 4.2:
>  
> 
> 4.2. The repair node is a PQ node
>  
>  
> Cc: [email-masked]; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; Jonathan Hardwick ([email-masked]) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> To: Alexander Vainshtein <[email-masked]>; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; Jonathan Hardwick ([email-masked]) <[email-masked]>; [email-masked]; [email-masked]
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]'; [email-masked]'; Jonathan Hardwick ([email-masked]); [email-masked]
> To: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
> Cc: [email-masked]' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]' <[email-masked]>
> I have been selected to do a routing directorate “early” review of this draft: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
> 
>  
> 
> For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
>  
> 
> Reviewer: Alexander (“Sasha”) Vainshtein ([email-masked])
> 
> Review Date: 08-Jun-18
> 
> I consider this draft as an important  companion document to the Segment Routing Architecture draft that, ideally, should augment definitions of the Segment Routing (SR) notions and constructs given there with details specific for the SR instantiation that uses  the MPLS data plane (SR-MPLS).  Many issues raised in my review reflect either gaps that should be, but have not been, closed, or inconsistencies between the two drafts.
> 
>  
> 
>  
> 
> Since RFC 8287 is already published as a Standards Track RFC, I expect such augmentation to be backward compatible with this document (or to provide clear indications of required updates to this document). And I include the MPLS WG into distribution list.
> 
>  
> 
> [[Sasha]] I would be satisfied with this response, would it not be for the following text I see in Section 2.2 of the SR Policy Architecture draft:
> 
> 2.5.5.2.  IPv4-Mapped IPv6 Address
>  
>  
>                                         ii.    Valid examples of  PUSH operation applied to a labeled incoming packet can be found in Sections 4.2 or 4.3 of the TI-LFA draft
>  
> 
> 1.    I concur with Adrian regarding numerous nits he has reported in his WG LC Comment. I would like to thank Adrian for an excellent review that have saved me lots of hard work.
> a.    Ti-LFA in Section 2.11.1 should be TI-LFA (as in the TI-LFA draft)
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Loa Andersson <[email-masked]>
Date: Tue, 20 Nov 2018 14:45:11 +0800

Shaddra,

Yes I agree.

/Loa

On 2018-11-20 00:01, Przemyslaw Krol wrote:
> On Sun, Nov 18, 2018 at 8:39 PM Shraddha Hegde <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi all,____
> 
>     __ __
> 
>     I am preparing the shepherd write-up and noticed that the topic in
>     below e-mail thread is an____
> 
>     Open item. My personal opinion is to add a new section to this draft
>     to address below cases____
> 
>     >  more than one node advertising the same IPv4/6 PREFIX and both
>     have the same prefix-SID value with "N" flag____
> 
>     some (but not all) of the nodes that advertise that prefix.____
> 
>     __ __
> 
>     This draft is addressing incoming label collision and resulting
>     behavior and also describes other aspects like different SIDs for
>     same prefix so it seems reasonable to add above two cases to this
>     draft.____
> 
>     WG members, if you have an opinion, pls respond on the list.____
> 
>     __ __
> 
>     Rgds____
> 
>     Shraddha____
> 
>     *From:*Alexander Vainshtein <[email-masked]
>     <mailto:[email-masked]>>
>     *To:* Ahmed Bashandy <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>' <[email-masked] <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>'
>     <[email-masked] <mailto:[email-masked]>>; Jonathan
>     Hardwick ([email-masked]
>     <mailto:[email-masked]>)
>     <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>;
>     draft-ietf-spring-segment-routing-mpls.authors@ietf..org
>     <mailto:draft-ietf-spring-segment-routing-mpls.authors@ietf..org>;
>     Shraddha Hegde <[email-masked] <mailto:[email-masked]>>
>     draft-ietf-spring-segment-routing-mpls-13____
> 
>     __ __
> 
>     Ahmed,____
> 
>     Apologies for a delayed response.____
> 
>     I fully agree that advertising the same prefix SID as the Node SID
>     by two different nodes in the SR domain is “a clear violation of the
>     SR architecture RFC (8402)”.____
> 
>     violation just because it “is not an incoming label collision”. ____
> 
>     The same applies to the controversy in advertising at the same
>     prefix as Anycast by some nodes but not as Anycast (or even as a
>     Node SID) by some other nodes. ____
> 
>     Your reference to these being just control plane issues and
>     therefore not related to SR-MPLS is not valid - because the drafts
>     dealing with the SR control plane to which you refer in this draft
>     are strictly MPLS-oriented: they define how to advertise */SID
>     labels/* or */indices/* that are translated into */SID labels/*, and
>     neither of these mechanisms is relevant fore SRV6 IMHO. (I do not
>     have to remind you that a draft that defines SRV6 extensions for
>     ISIS
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbashandy-2Disis-2Dsrv6-2Dextensions_-3Finclude-5Ftext-3D1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=ko-3eF8yySF1exH64SoeyEP0ett4gjsHmmOCvj9zCvQ&s=_AZSiqmTUTMKFS9DAqboueo_GnvvAcFxARWF820HnTA&e=>exists,
>     and deals with other issues).____
> 
>     My 2c,____
> 
>     Sasha____
> 
>     __ __
> 
>     Office: +972-39266302____
> 
>     Cell:      +972-549266302____
> 
>     <mailto:[email-masked]>____
> 
>     __ __
> 
>     *From:*Ahmed Bashandy [mailto:[email-masked]]
>     *To:* Shraddha Hegde <[email-masked]
>     <mailto:[email-masked]>>; Alexander Vainshtein
>     <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>' <[email-masked] <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>'
>     <[email-masked] <mailto:[email-masked]>>; Jonathan
>     Hardwick ([email-masked]
>     <mailto:[email-masked]>)
>     <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>;
>     <mailto:[email-masked]>
>     draft-ietf-spring-segment-routing-mpls-13____
> 
>     __ __
> 
>     Thanks for the comments____
> 
>     While it is a clear violation of the SR architecture RFC (8402),
>     more than one node advertising the same IPv4/6 PREFIX and both have
>     the same prefix-SID value with "N" flag is not an incoming label
>     collision because the label is associated with the same FEC, which
>     is the prefix. ____
> 
>     Hence handling such violation is not an SR-MPLS problem because
>     there is no incoming label collision and hence it it is outside the
>     scope of this draft____
> 
>     __ __
> 
>     The second issue is which SID to choose for an SR-policy (be it a
>     policy for TE, ti-lfa, uloop avoidance, security,..., etc). That is
>     strictly a control layer functionality and is not specific to
>     SR-MPLS. Hence it is outside the scope of this draft____
> 
>     __ __
> 
>     The third issue is the case where an anycast prefix is advertised
>     with a prefix-SID sub-TLV by some (but not all) of the nodes that
>     advertise that prefix. Again this is not an incoming label collision
>     because the label is associated with a single FEC, which is the
>     anycast prefix.____
> 
>     __ __
> 
>     On 7/19/18 8:30 PM, Shraddha Hegde wrote:____
> 
>         Hi Ahmed,____
> 
>         ____
> 
>         The Node-SIDs are expected to be unique to a node. ____
> 
>         “____
> 
>             An IGP Node-SID MUST NOT be associated with a prefix that is
>         owned by____
> 
>             more than one router within the same routing domain.”____
> 
>         ____
> 
>         If two different nodes advertise same Node-SID,____
> 
>                   For Example Node A and B both advertise prefix 1.1.1.1
>         and associate a  SID 1000 with N bit set.____
> 
>         There is an anomaly here and IMO, this draft should address how
>         to handle this anomaly and whether TI-LFA and other____
> 
>         Applications can use this SID as a Node-SID.____
> 
>         Another slight variation of this case is a scenario where A and
>         B both advertise a prefix 1.1.1.1 and A assigns a Node-Sid____
> 
>         Of 1000 and B does not assign any SID.____
> 
>         ____
> 
>         Rgds____
> 
>         Shraddha____
> 
>         ____
> 
>         *From:*Alexander Vainshtein <[email-masked]>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]>
>         *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>' <[email-masked]> <mailto:[email-masked]>;
>         [email-masked] <mailto:[email-masked]>'
>         <[email-masked]> <mailto:[email-masked]>; Jonathan
>         Hardwick ([email-masked]
>         <mailto:[email-masked]>)
>         <[email-masked]>
>         <mailto:[email-masked]>; Shraddha Hegde
>         <[email-masked]> <mailto:[email-masked]>;
>         [email-masked] <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>;
>         <mailto:[email-masked]>
>         draft-ietf-spring-segment-routing-mpls-13____
> 
>         ____
> 
>         Ahmed hi!____
> 
>         Lots of thanks for your response.____
> 
>         Of course Node SIDs are not different from any other Prefix SIDs
>         when it comes to the MPLS forwarding plane.____
> 
>         But, IMHO, strictly speaking, this is correct for any other SID
>         as well. ____
> 
>         You seem to ignore the difference between SR-MPLS and SRv6 with
>         regard to the life span of prefix SIDs in general and Node SIDs
>         in particular. From my POV this difference should be discussed
>         in the draft. ____
> 
>         So it seems that we can only “agree to disagree” on the need to
>         say something specific about Node SIDs in the draft, and let the
>         WG to decide what to do about it. ____
> 
>         Regards,____
> 
>         Sasha____
> 
>         ____
> 
>         Office: +972-39266302____
> 
>         Cell:      +972-549266302____
> 
>         <mailto:[email-masked]>____
> 
>         ____
> 
>         *From:*Ahmed Bashandy [mailto:[email-masked]]
>         *To:* Alexander Vainshtein <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>' <[email-masked] <mailto:[email-masked]>>;
>         [email-masked] <mailto:[email-masked]>'
>         <[email-masked] <mailto:[email-masked]>>; Jonathan
>         Hardwick ([email-masked]
>         <mailto:[email-masked]>)
>         <[email-masked]
>         <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>;
>         <mailto:[email-masked]>
>         draft-ietf-spring-segment-routing-mpls-13____
> 
>         ____
> 
>         Thanks for the reply____
> 
>         See inline____
> 
>         Ahmed____
> 
>         ____
> 
>         On 7/12/18 12:22 AM, Alexander Vainshtein wrote:____
> 
>             Ahmed and all,____
> 
>             I would like to expand on my comments (and your responses)
>             about the role of Node SIDs in SR-MPLS.____
> 
>             I would like to bring your attention two points:____
> 
>             __1.__Node SIDs (and, in general, Prefix SIDs) in MPLS-SR
>             are different from the same in SRv6 because they require
>             explicit configuration action by the operator of SR domain.
>             I.e., it is not enough for a node to own some /32 or /128
>             prefix that is advertised by IGP. The operator must
>             explicitly configure the node to use such a prefix as  Node
>             SID and to assign to it a specific index that is unique in
>             the SR domain. From my POV, this difference alone would
>             qualify Node SIDs as a topic to be discussed in the MPLS-SR
>             Architecture
>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dmpls-2D14&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=q6djpRXlamUzKZlGIuXTtBcsnwevHwddqvStZrSFMnE&e=>draft.____
> 
>         #Ahmed: I disagree with your POV. From the forwarding plane
>         perspective it does not make any difference whether a the label
>         at the top of an MPLS packet (representing the prefix-SID)
>         identifies a node or not. So from the SR-mpls forwarding point
>         of view there is no difference between a prefix-SID and a
>         node-SID. If there is any place in the SR-mpls draft where there
>         is a need to handle a node-SID different from a prefix SID, it
>         would be great to point it out
> 
>         ____
> 
> 
>                   __2.__In addition, quite a few constructs associated
>                   with SR-MPLS implicitly assume that each node in the
>                   SR-MPLS domain is assigned with at least one Node SID.
>                   One example can be found in the TI-LFA
>                   draft. This draft says in Section 4.2:____
> 
>             ____
> 
> 
>                   4.2
>                   The repair node is a PQ node____
> 
>             ____
> 
>             ____
> 
>                 When the repair node is in P(S,X), the repair list is
>             made of a____
> 
>                 single node segment to the repair node.____
> 
>             In the scope of this section, the repair node is not
>             adjacent to the PLR, and therefore, to the best of my
>             understanding,  “a single node segment to the repair node”
>             can be only the Node SID of the repair node. Since repair
>             nodes are computed dynamically, this entire scheme depends
>             on all nodes in the MPLS=SR domain  having at least one Node
>             SID each____
> 
>         #Ahmed: The choice of the SID to identify an intermediate or
>         exit node(s) in an SR-policy is a control plane behavior,
>         irrespective of reason such policy is created (be it ti-lfa
>         explicit path, uloop avoidance explicit path, or some SR-TE
>         explicit path). SR-Policy as well as Ti-LFA and uloop avoidance
>         are handled in separate drafts. So just like the response to
>         your previous comment, from forwarding plane perspective it does
>         not make any difference whether the label at the top of an MPLS
>         packet identifies a single or multiple nodes.
> 
>         ____
> 
>             .____
> 
>             ____
> 
>             Hopefully these notes clarify my position on the subject.____
> 
>             ____
> 
>             Regards,____
> 
>             Sasha____
> 
>             ____
> 
>             Office: +972-39266302____
> 
>             Cell:      +972-549266302____
> 
>             <mailto:[email-masked]>____
> 
>             ____
> 
>             *From:*Alexander Vainshtein
>             <mailto:[email-masked]>
>             *Cc:* [email-masked] <mailto:[email-masked]>;
>             [email-masked] <mailto:[email-masked]>' <[email-masked]>
>             <mailto:[email-masked]>; [email-masked]
>             <mailto:[email-masked]>' <[email-masked]>
>             <mailto:[email-masked]>; Jonathan Hardwick
>             ([email-masked]
>             <mailto:[email-masked]>)
>             <[email-masked]>
>             <mailto:[email-masked]>;
>             [email-masked] <mailto:[email-masked]>;
>             [email-masked] <mailto:[email-masked]>;
>             [email-masked] <mailto:[email-masked]>;
>             <mailto:[email-masked]>
>             draft-ietf-spring-segment-routing-mpls-13____
> 
>             ____
> 
>             Ahmed, and all,____
> 
>             Lots of thanks for a detailed response to my comments. ____
> 
>             Please see */inline below/*my position on each of them.____
> 
>             ____
> 
>             Regards,____
> 
>             Sasha____
> 
>             ____
> 
>             Office: +972-39266302____
> 
>             Cell:      +972-549266302____
> 
>             <mailto:[email-masked]>____
> 
>             ____
> 
>             *From:*Ahmed Bashandy [mailto:[email-masked]]
>             *To:* Alexander Vainshtein <[email-masked]
>             <mailto:[email-masked]>>;
>             [email-masked] <mailto:[email-masked]>;
>             <mailto:[email-masked]>
>             *Cc:* [email-masked] <mailto:[email-masked]>;
>             [email-masked] <mailto:[email-masked]>' <[email-masked]
>             <mailto:[email-masked]>>; [email-masked]
>             <mailto:[email-masked]>' <[email-masked]
>             <mailto:[email-masked]>>; Jonathan Hardwick
>             ([email-masked]
>             <mailto:[email-masked]>)
>             <[email-masked]
>             <mailto:[email-masked]>>;
>             [email-masked] <mailto:[email-masked]>;
>             [email-masked] <mailto:[email-masked]>
>             draft-ietf-spring-segment-routing-mpls-13____
> 
>             ____
> 
>             Thanks for thorough (and VERY clear) the review____
> 
>             See inline #Ahmed____
> 
>             ____
> 
>             Ahmed____
> 
>             ____
> 
>             ____
> 
>             On 6/15/18 11:08 PM, Alexander Vainshtein wrote:____
> 
>                 Re-sending to  correct SPRING WG list.____
> 
>                 Sincere apologies for the delay caused by a typo.____
> 
>                 Thumb typed by Sasha Vainshtein____
> 
>                 ____
> 
>                 ------------------------------------------------------------------------
> 
>                 *To:* [email-masked]
>                 <mailto:[email-masked]>;
>                 <mailto:[email-masked]>
>                 *Cc:* spring@ietf..com <mailto:[email-masked]>;
>                 [email-masked] <mailto:[email-masked]>;
>                 [email-masked] <mailto:[email-masked]>';
>                 [email-masked] <mailto:[email-masked]>';
>                 Jonathan Hardwick ([email-masked]
>                 <mailto:[email-masked]>);
>                 [email-masked] <mailto:[email-masked]>
>                 draft-ietf-spring-segment-routing-mpls-13____
> 
>                 ____
> 
>                 Explicitly adding Shraddha  who is the shepherd of this
>                 draft. ____
> 
>                 ____
> 
>                 Regards,____
> 
>                 Sasha____
> 
>                 ____
> 
>                 Office: +972-39266302____
> 
>                 Cell:      +972-549266302____
> 
>                 <mailto:[email-masked]>____
> 
>                 ____
> 
>                 *To:* [email-masked]
>                 <mailto:[email-masked]>'
>                 <[email-masked]>
>                 <mailto:[email-masked]>;
>                 [email-masked]
>                 <mailto:[email-masked]>'
>                 <[email-masked]> <mailto:[email-masked]>
>                 *Cc:* [email-masked] <mailto:[email-masked]>'
>                 <[email-masked]> <mailto:[email-masked]>;
>                 [email-masked] <mailto:[email-masked]>;
>                 [email-masked] <mailto:[email-masked]>;
>                 [email-masked] <mailto:[email-masked]>'
>                 <[email-masked]> <mailto:[email-masked]>
>                 draft-ietf-spring-segment-routing-mpls-13____
> 
>                 ____
> 
>                 ____
> 
>                 Hello,____
> 
>                 I have been selected to do a routing directorate “early”
>                 review of this draft:
>                 <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dmpls_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=Cxbaaf9U0kj6_meVSobSkRLQW1SwI8MJvgHpuYp0QOM&e=>____
> 
>                 ____
> 
>                 The routing directorate will, on request from the
>                 working group chair, perform an “early” review of a
>                 draft before it is submitted for publication to the
>                 IESG. The early review can be performed at any time
>                 during the draft’s lifetime as a working group document.
>                 The purpose of the early review depends on the stage
>                 that the document has reached. As this document is
>                 currently in the WG Last call, my focus for the review
>                 was to determine whether the document is ready to be
>                 published. Please consider my comments along with the
>                 other working group last call comments.____
> 
>                 ____
> 
>                 <https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=6pnI7l82ewwzoxgOXqTKrbKuQidt6-KBsZdsXFnoQCg&e=>____
> 
>                 ____
> 
>                 *Document*: draft-ietf-spring-segment-routing-mpls-13____
> 
>                 *Reviewer*: Alexander (“Sasha”) Vainshtein
>                 ([email-masked]
>                 <mailto:[email-masked]>)____
> 
>                 *Review Date*: 08-Jun-18____
> 
>                 *Intended Status*: Proposed Standard.____
> 
>                 ____
> 
>                 *Summary*:____
> 
>                 ____
> 
>                 I have some minor concerns about this document that I
>                 think should be resolved before it is submitted to the
>                 IESG.____
> 
>                 ____
> 
>                 *Comments*:____
> 
>                 ____
> 
>                 I consider this draft as an important  companion
>                 document to the Segment Routing Architecture
>                 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D15&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=iJShh7e7yyVkt44v1O5pyCOMfHCpAvfBNGgFr5lk130&e=>draft
>                 that, ideally, should augment definitions of the Segment
>                 Routing (SR) notions and constructs given there with
>                 details specific for the SR instantiation that uses  the
>                 MPLS data plane (SR-MPLS).  Many issues raised in my
>                 review reflect either gaps that should be, but have not
>                 been, closed, or inconsistencies between the two drafts.
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 Since RFC 8287
>                 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8287&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=y7jp3UYNTtcmm9HOulzqPTrMURTrsMiO26rWlNZN5Ws&e=>is
>                 already published as a Standards Track RFC, I expect
>                 such augmentation to be backward compatible with this
>                 document (or to provide clear indications of required
>                 updates to this document). And I include the MPLS WG
>                 into distribution list. ____
> 
>                 ____
> 
>                 This draft was not easy reading for me. In particular,
>                 the style of Section 2.5 that discusses at length and in
>                 some detail multiple “corner cases” resulting,
>                 presumably, from misconfiguration, before it explains
>                 the basic (and relatively simple) “normal” behavior,
>                 looks problematic to me.____
> 
>                 ____
> 
>                 The WG Last Call has been extended by one week.
>                 Nevertheless, I am sending out my comments ____
> 
>                 ____
> 
>                 *Major Issues*: None found____
> 
>             #Ahmed: thanks a lot____
> 
>                 ____
> 
>                 *Minor Issues*: Quite a few but, hopefully, easy to
>                 resolve.____
> 
>                 ____
> 
>                 1.*Encapsulation of SR-MPLS packets*: ____
> 
>                 a.RFC 3032 (referenced by the draft) and RFC 5332 (*/not
>                 mentioned in the draft/*) depend two encapsulations of
>                 labeled packets - one for Downstream-allocated labels
>                 and another for Upstream-allocated ones.____
> 
>             #Ahmed: RFC5332 is for multicast. As mentioned in Section 6
>             of draft-ietf-spring-segment-routing-15, multicast is
>             outside the scope of SR. Hence the RFC was not referred to
>             in the SR-MPLS draft____
> 
>             */[[Sasha]] I would be satisfied with this response, would
>             it not be for the following text I see in Section 2.2 of
>             the/**//**/SR Policy Architecture/*
>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dpolicy-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=4f0H68LTvkp7N-bYTVLOhWqiEbHaCsOQR1z_Qzz3Wf4&e=>*//**/draft:/*____
> 
>                 A variation of SR Policy can be used for packet
>             replication.  A____
> 
>                 candidate path could comprise multiple SID-Lists; one
>             for each____
> 
>                 replication path.  In such a scenario, packets are
>             actually____
> 
>                 replicated through each SID List of the SR Policy to
>             realize a point-____
> 
>                 to-multipoint service delivery. ____
> 
>             ____
> 
>             */This looks to me as being very much multicast in SR, and,
>             unless you want to say that it is limited to SRv6, makes my
>             question relevant IMHO./*____
> 
>                 b.From my POV the ST-MPLS only uses Downstream-allocated
>                 labels – but I expect the draft to state that
>                 explicitly, one way or another. (If Upstream-allocated
>                 labels are relevant for SR-MPLS, I would see it as a
>                 major gap, so I hope that this is not the case).____
> 
>             #Ahmed: I will add a statement in section 2.2 to mention
>             that it is down-stream allocated as you mentioned____
> 
>             */[[Sasha]] This is quite unambiguous and, once added, would
>             resolve my comment in full – the previous comment
>             notwithstanding. In particular, it would imply that even
>             labels representing BSIDs of a SR Replication policies will
>             be downstream-allocated. /*____
> 
>             ____
> 
>                 2.*Label spaces in SR-MPLS*:____
> 
>                 a.RFC 3031 (referenced by the draft) defines
>                 per-platform and per-interface label spaces, and RFC
>                 5331 (*/not mentioned in the draft/*) adds
>                 context-specific label spaces and context labels. ____
> 
>                 b.The draft does not say which of these are or are not
>                 relevant for SR-MPLS____
> 
>                 c.From my POV:____
> 
>                 i.Labels representing all kinds of SIDs mentioned in the
>                 draft MUST be allocated from the per-platform label
>                 space only ____
> 
>                 ii.At the same time, instantiation of Mirror Segment IDs
>                 defined in Section 5.1 of the Segment Routing
>                 Architecture draft using MPLS data plane clearly calls
>                 for context labels and context-specific label spaces____
> 
>                 d.I expect the draft to provide a clear-cut position on
>                 these aspects of SR-MPLS.____
> 
>             #Ahmed: I will add a statement to section 2.2 to say that
>             the it is per-platform. Regarding the function "mirroring",
>             SR attaches a *function* to each SID. The "mirroring"
>             function is already described in Section 5.1 of
>             draft-ietf-spring-segment-routing and is not specific to the
>             MPLS forwarding plane. Hence there is no need to re-mention
>             it here because this document is trying to be as specific as
>             possible to the MPLS forwarding plane. General functions
>             attached to SID are described in the segment routing
>             architecture document or future documents. Furture documents
>             proposing new SR function must be as specific and clear as
>             possible____
> 
>             */[[Sasha]] Looks OK to me./*____
> 
>             ____
> 
>                 3.*SR-MPLS and hierarchical LSPs*:____
> 
>                 a.SR LSPs that include more than one segment are
>                 hierarchical LSPs from the POV of the MPLS data plane.
>                 Therefore some (possibly, all) of the models for
>                 handling TTL and TC bits that have been defined in RFC
>                 3443 (*/not mentioned in the draft/*) should apply to
>                 SR-MPLS____
> 
>                 b.RFC 8287 (*/not referenced in the draft/*)
>                 specifically discussed operation of the LSP Traceroute
>                 function for SR LSPs in the case when Pipe/Short Pipe
>                 model for TTL handling is used____
> 
>                 c.I expect the draft to provide at least some guidelines
>                 regarding applicability of each specific model defined
>                 in RFC 3443 (separately for TTL and TC bits) to SR-MPLS.____
> 
>             #Ahmed: BY design, the instantiation of SR over the MPLS
>             forwarding plane (and hence this draft) does not modify the
>             MPLS forwarding plan behavior as it is mentioned in the
>             first sentence in Section 1. So the TTL behavior specified
>             in rfc3443 is already implied and there is no need to
>             re-mention it here just like all aspects of MPLS forwarding.
>             RFC8287 is OAM-specific.  SR-OAM is handled in a separate
>             document so is outside the scope of this draft____
> 
>             */[[Sasha]] Unfortunately I do not think this is good
>             enough. Let me ask a specific question reflecting my
>             concerns:/*____
> 
>             */The head-end node sends SR-MPLS packets across a path
>             defined by an ordered set of SIDs with more than one SID in
>             the list. Each SID is represented by a label stack entry
>             (LSE) in the MPLS label stack, and the label field in each
>             LSE is the label that matches the corresponding SID.
>             However, each LSE also includes the TTL and TC fields. How
>             does the head-end node set these fields in each of the LSEs
>             following the top one? This clearly depends on the model
>             (Uniform vs. Pipe/Short Pipe) implemented in each node that
>             that performs Next operation on the packet along the path –
>             but the head-end node usually is not aware of that. /*____
> 
>             */RFC 8287 is relevant as an example here IMHO because it
>             recommends the following setting of TTL in Traceroute
>             packets:/*____
> 
>             __-__*/Set the TTL of all the labels above one that
>             represents the segment you are currently tracing to
>             maximum/*____
> 
>             __-__*/Set the TTL of the label one that represents the
>             segment you are currently tracing to the desired value (to
>             be incremented until end of segment is reached/*____
> 
>             __-__*/Set the TTL of all the labels below one that
>             represents the segment you are currently tracing to 0./*____
> 
>             */I expect the draft to provide some recommendations for
>             traffic (non-OAM) packets as well./*____
> 
>             ____
> 
>                 4.*Inferring network layer protocol in SR-MPLS*:____
> 
>                 a.I wonder if the draft could provide any details on the
>                 situation when a label that represents some kind of SID
>                 is the bottom-of-stack label to be popped by the egress
>                 LER____
> 
>             #ahmed: This is part of the "Next" function. It is described
>             in detail in this document. ____
> 
>             */[[Sasha]] NEXT function is mentioned in several places in
>             the document. Can you please point to the specific text that
>             is relevant for my question?/*____
> 
>             ____
> 
>                 b.For the reference, RFC 3032 says that “the identity of
>                 the network layer protocol  must be inferable from the
>                 value of the label which is popped from  the bottom of
>                 the stack, possibly along with the contents  of the
>                 network layer header itself”____
> 
>                 c.From my POV the following scenario indicates relevance
>                 of this expectation for SR-MPLS:____
> 
>                 i.IS-IS is used for distributing both IPv4 and IPv6
>                 reachability in a given domain____
> 
>                 ii.An IS-IS adjacency over some dual-stack link is
>                 established, and a single Adj-SID for this adjacency is
>                 advertised____
> 
>                 iii.The node that has assigned and advertised this
>                 Adj-SID receives a labeled packet with the label
>                 representing this Adj-SID being both the top and
>                 bottom-of-stack label____
> 
>                 iv.The implementers must be given unambiguous
>                 instructions for forwarding the unlabeled packet via the
>                 dual-stack link as an Ipv4 or an IPv6 packet.____
> 
>             #Ahmed: If you take a look at the SR-ISIS , SR-OSPFv2 and
>             SR-OSFv3 drafts, you will see all 3 protocol advertise
>             different adj-SIDS for IPv4 next-hop and IPv6 next-hop. For
>             example, ISIS uses the "F-Flag" (section 2.2.1 in
>             draft-ietf-isis-segment-routing-extensions-18) to specify
>             whether the adj-SID is for IPv4 and IPv6. Similarly, the
>             SR-ISIS draft attaches a prefix-SID to the prefix
>             advertisement and hence implies the identity of the protocol
>             underneath the bottom most label. For any other "function"
>             attached to a SID, it is part of the specification of this
>             function to describe what happens when the SID is
>             represented by a label in the MPLS forwarding plane and this
>             label is the bottom most label ____
> 
>             */[[Sasha]] OK, got it. This issue is resolved./*____
> 
>             ____
> 
>                 5.*Resolution**of Conflicts*: Are the____
> 
>                 a.Are the conflict resolution procedures listed in
>                 section 2.5 mandatory to implement? ____
> 
>                 b.If they are mandatory to implement, are they also
>                 mandatory to deploy, or can the operators simply treat
>                 any detected conflict as requiring human intervention
>                 and preventing normal operation of SR-MPLS?____
> 
>             #Ahmed: They are recommended. I will modify the paragraph
>             after the first 3 bullets in Section 2.5 to say that it is
>             recommeded. ____
> 
>             */[[Sasha]] OK. However, it would be nice if you could refer
>             separately for “RECOMMENDED to implement” and “RECOMMENDED
>             to deploy”.  The latter probably requires a configuration
>             knob for enabling conflict resolution rules (if they are
>             implemented). /*____
> 
>                 c.For the reference, the IETF capitalized MUST appears
>                 just in a few places in Section 2.5, and each appearance
>                 has very narrow context:____
> 
>                 i.For MCCs where the "Topology" and/or "Algorithm"
>                 fields are not defined, the numerical value of zero MUST
>                 be used for these two fields____
> 
>                 ii.If the same set of FECs are attached to the same
>                 label "L1", then the tie-breaking rules MUST always
>                 select the same FEC irrespective of the order in which
>                 the FECs and the label "L1" are received. In other
>                 words, the tie-breaking rule MUST be deterministic. ____
> 
>                 iii.An implementation of explicit SID assignment MUST
>                 guarantee collision freeness on the same router____
> 
>                  From my POV, it is not possible to infer the answer to
>                 my question from these statements. Some explicit
>                 statement is required.____
> 
>             #Ahmed: I agree with you POV and as mentioned in my reply to
>             items (a) and (b), I will modify the paragraph to say that
>             it is RECOMMENDED to answer you questions in items (a) and
>             (b)____
> 
>                 d.The tie-breaking rules in section 2.5.1 include some
>                 specific values for encoding FEC types and address
>                 families – but these values are not supposed to appear
>                 in any IANA registries (because the draft does not
>                 request any IANA actions). Can you please clarify what
>                 is so special about these values? ____
> 
>             #Ahmed: There is no significance to the values but there is
>             a significance to the order among them. I will modify the
>             text to clarify that____
> 
>             */[[Sasha]] OK. /*____
> 
>             ____
> 
>                 e.I also doubt that comparison of FECs that represent
>                 IPv4 and IPv6 prefix SIDs makes much sense (for conflict
>                 resolution or else), because, among other things, there
>                 are valid scenarios when an IPv4 /32 prefix is embedded
>                 in an IPv6 /128 one.____
> 
>             #Ahmed: A prefix-SID is assigned to a prefix. An IPv6 prefix
>             that embeds an IPv4 prefix is different from the IPv4
>             prefix. The specifications of SR extensions to ISIS, OSPFv2,
>             OSPFv3, and BGP treat IPv4 and IPv6 prefixes separately,
>             including the IPV6 prefixes with embedded IPv4 ones. Besides
>             not all IPv6 prefixes embed IPv4 prefix in them. Hence the
>             distinction between IPv4 and IPv6 prefixes is quite clear ____
> 
>             */[[Sasha]] My concern was mainly about IPv4-mapped IPv6
>             addresses. Quoting from RFC 4291:/*____
> 
> 
>                       *2.5.5.2*
>                       IPv4-Mapped IPv6 Address*____
> 
>             ____
> 
>             ____
> 
>                 A second type of IPv6 address that holds an embedded
>             IPv4 address is____
> 
>                 defined. This address type is used to represent the
>             addresses of____
> 
>                 IPv4 nodes as IPv6 addresses.____
> 
>             *//*____
> 
>             */From my POV this means that a /128 prefix associated with
>             an IPv4-mapped IPv6 address and a /32 prefix associated with
>             the IPv4 address that was mapped to this IPv6 address
>             represent the same entity. This understanding fully matches
>             usage of IPv4-mapped IPv6 addresses as BGP Next Hops of
>             VPN-IPv6 addresses defined in RFC 4798. However, the
>             comparison rules you have defined will treat them as two
>             different prefixes.  I wonder if these rules, in the case of
>             a conflict, could result in preferring the IPv6 prefix to an
>             IPv4 one and therefore loosing MPLS connectivity for the
>             ingress PE of a 6VPE service to its egress PE?/*____
> 
>             ____
> 
>                 f.Section 2.5.1 defines 3 types of SR-MPLS FECs, but I
>                 am not sure all SID types defined in the Segment Routing
>                 Architecture draft can be unambiguously mapped to one of
>                 these types. Problematic examples include at least the
>                 following:____
> 
>                 i.Parallel Adjacency SID____
> 
>                 ii.Mirror SID____
> 
>                 Explicit mapping of SID types to SR-MPLS FEC types would
>                 be most useful IMO. If some SID types cannot be mapped
>                 to SR-MPLS FECs, this must be explicitly stated in the
>                 draft.____
> 
>             #Ahmed:
>             Parallel adjacency SID are handled in the type "(next-hop,
>             outgoing interface)" ____
> 
>             */[[Sasha]] OK/*____
> 
> 
>             Mirror SID is a type of binding-SID as mentioned in Section
>             5.1 in the SR architecture draft
>             (draft-ietf-spring-segment-routing-15). Also as described in
>             Section 2.4 draft-ietf-isis-segment-routing-extensions-18
>             (also see the equivalent in the OSPFv2 and OSPFv3 draft), a
>             binding SID is identified by a prefix. Hence it is covered
>             by the type "(Prefix, Routing Instance, Topology,
>             Algorithm)"____
> 
>             */[[Sasha]] I respectfully disagree. There is definitely no
>             mention of Algorithm in the definition of the Mirror SID. /*____
> 
>             ____
> 
>                 6.*Node SIDs in SR-MPLS*:____
> 
>                 a.Node SIDs are explicitly defined and discussed in the
>                 Segment Routing Architecture draft but are not mentioned
>                 even once in this draft____
> 
>                 b.AFAIK, the common implementation practice today
>                 includes assignment of at least one Node SID to every
>                 node in the SR-MPLS domain____
> 
>                 c.Is there a requirement to assign at least one Node SID
>                 per {routing instance, topology, algorithm} in SR-MPLS?
>                 If not, can the authors explain expected behavior of
>                 such a node? (See also my comment about routing
>                 instances below).____
> 
>             #Ahmed: A Node-SID is a special case of prefix-SID. So there
>             nothing specific about it from the MPLS forwarding plane
>             point of view. Similarly from a standard tracks draft point
>             of view, there is no requirement to assign a SID to every
>             prefix just like there is no requirement to bind every
>             prefix to an LDP label. Common and/or recommended practices
>             or description of deployment scenarios are more befitting to
>             BCP or informational drafts. This draft is a standards track
>             draft____
> 
>             */[[Sasha]] Well, you’ve just said that conflict resolution
>             rules are RECOMMENDED, and this is quite common in the
>             Standards Track RFCs. /*____
> 
> 
>             If a {routing instance, topology, algorithm} is not assigned
>             a SID, then this FEC is totally irrelavant to this draft and
>             hence describing how a node treats it is totally outside the
>             scope of this draft____
> 
>             */[[Sasha]] AFAIK, neither of the SR extension drafts for
>             IGPs mention routing instances that can be associated with
>             the prefix, so I think that your reference to it is
>             incorrect./*____
> 
>             */What’s more I suspect that Node SIDs represent the most
>             used special case of Prefix SIDs with Anycast SIDs being
>             quite behind.  Therefore some recommendation pertaining to
>             the usage of Node SIDs would be very much in place IMHO. /*____
> 
>             ____
> 
>                 7.*SRGB Size in SR-MPLS*: ____
> 
>                 a.The draft correctly treats the situation when an index
>                 assigned to some global SID cannot be mapped to a label
>                 using the procedure in Section 2.4 as a conflict.____
> 
>                 b.At the same time the draft does not define any minimum
>                 size of SRGB (be it defined as a single contiguous block
>                 or as a sequence of such blocks) that MUST be
>                 implemented by all SR-capable nodes____
> 
>                 c.I suspect that lack of such a definition could be
>                 detrimental to interoperability of SR-MPLS solutions.
>                 AFAIK, the IETF has been following, for quite some time,
>                 a policy that some reasonable MUST-to-implement defaults
>                 should be assigned for all configurable parameters
>                 exactly in order to prevent this.____
> 
>             #Ahmed: This document specifies how the SRGB is used and the
>             behavior of routers when a prefix-SID index maps to a label
>             inside and/or outside the SRGB. The actual size of the SRGB
>             is a task in partitioning the label space, which is very
>             specific to a particular deployment scenario. So IMO it is
>             outside the scope of a standards track document. Now that
>             SR-MPLS is deployed in many places, I expect the community
>             to gain sufficient experience to recommend (or not
>             recommend) a particular minimum/maximum size for the SRGB is
>             some future informational or BCP draft/RFC____
> 
>             */[[Sasha]] My reading of your response is that minimum size
>             of SRGB is an issue for future study. Can you please just
>             add this to the draft?/*____
> 
>             ____
> 
>                 8.*Algorithms and Prefix SIDs*:____
> 
>                 a.The draft mentions Algorithms (as part of SR-MPLS
>                 Prefix FEC) in, but it does not explicitly link them
>                 with the Prefix-SID algorithms defined in section 3.1.1
>                 of the Segment Routing Architecture draft____
> 
>             #Ahmed: I will just add the reference
>             [I-D.ietf-spring-segment-routing] right beside the first
>             time "Algorithm" is mentioned____
> 
>             */[[Sasha]] OK/*____
> 
>             ____
> 
>                 b.From my POV, the draft should explicitly state that
>                 the default Prefix-SID algorithm MUST be implemented in
>                 all SR-MPLS-compliant routers.____
> 
>             #Ahmed: The specification of what path calculation method
>             should or must be supported is a routing protocol property
>             not a forwarding plane property. In fact, the choice of a
>             path calculation method or algorithm is completely
>             orthogonal to the routed protocol. Hence mandating the
>             support of a particular routing algorithm is beyond the
>             scope of this document.____
> 
>             */[[Sasha]] OK/*____
> 
>             ____
> 
>                 c.The Segment Routing Architecture draft states (in
>                 section 3.1.3) that “Support of multiple algorithms
>                 applies to SRv6”. But neither draft states whether
>                 multiple algorithms apply to SR-MPLS. Can you please
>                 clarify this point?____
> 
>             #Ahmed: The last paragraph of Section 3.1.2 titled SR-MPLS
>             in draft-ietf-spring-segment-routing-15 discusses the
>             support of multiple algorithms. So it is implied that the
>             concept of algorithm applies to SR-MPLS. Hence there is no
>             need to re-mention it here____
> 
>             */[[Sasha]] The paragraph to which you refer only says that
>             if a packet with the active Prefix-SID that is associated
>             with a specific algorithm is received by a node that does
>             not support this algorithm, this packet will be discarded.
>             If this is the only type of support for multiple algorithms
>             SR provides, it is not very useful IMHO/**/. /*____
> 
>             ____
> 
>                 9.*Routing instances and the context for Prefix-SIDs*:____
> 
>                 a.The Segment Routing Architecture draft states in
>                 Section 3.1 that the “context for an IGP-Prefix segment
>                 includes the prefix, topology, and algorithm”____
> 
>                 b.This draft seems to define (in section 2.5) the
>                 context for the Prefix SID as “Prefix, Routing Instance,
>                 Topology, Algorithm” where ”a routing instance is
>                 identified by a single incoming label downloader to FIB”
>                 (but the notion of the label downloader to FIB is not
>                 defined).____
> 
>                 c.These two definitions look different to me. ____
> 
>                 d.At the very least I would expect alignment between the
>                 definitions of context for the Prefix-SID between the
>                 two drafts. Preferably, the definition given in the
>                 Segment Routing Architecture draft should be used in
>                 both drafts.____
> 
>             #Ahmed: The context of the section 2.5 is limited to the
>             resolution of local label collision. The use of "routing
>             instance" in section 2.5 is just there for tie-breaking if
>             there is local label collision.____
> 
>             */[[Sasha]] I have already mentioned that “routing
>             instances” are not defined in any the drafts dealing with SR
>             Extensions for IGPs. So I do not understand how the conflict
>             resolution procedure is supposed to use this. And in any
>             case the difference between two definitions of the context
>             of Prefix-SID requires some explanation./*____
> 
> 
> 
>             ____
> 
>                 10.*Example of PUSH operation in Section 2.10.1*:____
> 
>                 a.The first para of this section begins with the
>                 sentence “Suppose an MCC on a router "R0" determines
>                 that PUSH or CONTINUE   operation is to be applied to an
>                 incoming packet whose active SID is the global SID
>                 "Si"”. In the context of SR-MPLS this means (to me) that
>                 the incoming packet is a labeled packet and its top
>                 label matches the global SID “Si”. ____
> 
>                 b.However, the example for PUSH operation in the next
>                 para of this section is the case of an (unlabeled) IP
>                 packet with the destination address covered by the IP
>                 prefix for which “Si” has been assigned. ____
> 
>                 c.From my POV:____
> 
>                 i.Mapping unlabeled packets to SIDs is indeed out of
>                 scope of the draft. Therefore an example of a PUSH
>                 operation that is applied to a labeled packet (with the
>                 active SID inferred from the top label in the stack) is
>                 preferable.____
> 
>                 ii.Valid examples of  PUSH operation applied to a
>                 labeled incoming packet can be found in Sections 4.2 or
>                 4.3 of the TI-LFA
>                 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=jbH0DSYYo2UYymWZrlvAt7qUWVXsYKuCtMiEyoe-DWE&e=>draft____
> 
>                 ____
> 
>             #Ahmed: I do not understand your concern here:)____
> 
>             */[[Sasha]] I think it is pretty clear: can you provide an
>             example of a PUSH operation applied to a labeled packet
>             instead of your current example?/*____
> 
>             ____
> 
>                 *Nits*: ____
> 
>                 1.I concur with Adrian regarding numerous nits he has
>                 reported in his WG LC Comment
>                 I would like to thank Adrian for an excellent review
>                 that have saved me lots of hard work.____
> 
>             #Ahmed: I also agree that Adrian's review is exceptional. I
>             believe I addressed all his comments in the latest version.____
> 
>                 2.In addition, I’d like to report the following nits:____
> 
>                 a.Ti-LFA in Section 2.11.1 should be TI-LFA (as in the
>                 TI-LFA
>                 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=jbH0DSYYo2UYymWZrlvAt7qUWVXsYKuCtMiEyoe-DWE&e=>draft)____
> 
>             #Ahmed: Already done in the latest version*/[[Sasha]] OK/* ____
> 
>                 b.TI-LFA draft is referenced in the text of Section
>                 2.11.1, but there is no matching reference in the
>                 “References” section (probably, Informational)____
> 
>             #Ahmed: Already done in the latest version*/[[Sasha]] OK/* ____
> 
>                 c.“zero Algorithm” in Section 2.5 (immediately above
>                 Section 2.5.1) must be replaced with “default
>                 algorithm”. Similarly, “non-zero Algorithm” should be
>                 replaced with “non-default algorithm”____
> 
>             #Ahmed: Will be done in the next version*/[[Sasha]] /* OK____
> 
>                 3.I think that RFC 3443 and RFC 5332 should be listed as
>                 Normative references in this draft while RFC 5331 and
>                 RFC 8277 should be listed as Informative references.
>                 This would improve the readability of the draft without
>                 any impact on its advancement. ____
> 
>                 ____
> 
>             #Ahmed RFC5331 describes upstream label assignment. As you
>             mentioned above (and I will modify the draft to indicate
>             that) SR-MPLS behavior is similar to downstream label
>             assignment. RFC 3443 describes TTL behavior. This is an MPLS
>             forwarding behavior. As mentioned in the draft, SR-MPLS does
>             not modify at the MPLS forwarding behavior____
> 
>             */[[Sasha]] Regarding RFC 5331 – you may skip this reference
>             if you state (as discussed below) that SR-MPLS only
>             allocates labels from the per-platform label space.
>             Regarding RFC 3443 – I do not think that you can fully avoid
>             discussion of Uniform and Pipe/Short Pipe models, and
>             therefore you will need this reference./*____
> 
> 
> 
>             ____
> 
>                 Hopefully, these comments will be useful.____
> 
>             #Ahmed: They are certainly quite useful. Thanks a lot____
> 
>                 ____
> 
>                 Regards,____
> 
>                 Sasha____
> 
>                 ____
> 
>                 Office: +972-39266302____
> 
>                 Cell:      +972-549266302____
> 
>                 <mailto:[email-masked]>____
> 
>                 ____
> 
> 
>                 _______________________________________________________________________________
> 
>             ____
> 
> 
>             _______________________________________________________________________________
> 
>         ____
> 
> 
>         _______________________________________________________________________________
> 
>     __ __
> 
> 
>     _______________________________________________________________________________
> 
>     [email-masked] <mailto:[email-masked]>
> Przemyslaw "PK" Krol |	 Strategic Network Engineer	ing [email-masked] 
> <mailto:[email-masked]> 	
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64