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

[Ahmed Bashandy <[e-mail]>]

Thanks a lot for the reply

See inline "##Ahmed"


On 7/11/18 2:02 AM, Alexander Vainshtein wrote:
>
> 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: [phone]
>
> Cell: [phone]
>
> Email: [e-mail]
>
> *From:*Ahmed Bashandy [mailto:[e-mail]]
> *Sent:* Wednesday, July 11, 2018 4:42 AM
> *To:* Alexander Vainshtein <[e-mail]>; 
> [e-mail]; 
> [e-mail]
> *Cc:* [e-mail]; '[e-mail]' <[e-mail]>; 
> '[e-mail]' <[e-mail]>; Jonathan Hardwick 
> ([e-mail]) <[e-mail]>; 
> [e-mail]; [e-mail]
> *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:* [e-mail] <mailto:[e-mail]>;
>     [e-mail]
>     <mailto:[e-mail]>
>     *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; '[e-mail] <mailto:[e-mail]>';
>     '[e-mail] <mailto:[e-mail]>'; Jonathan
>     Hardwick ([e-mail]
>     <mailto:[e-mail]>); [e-mail]
>     <mailto:[e-mail]>
>     *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: [phone]
>
>     Cell: [phone]
>
>     Email: [e-mail]
>     <mailto:[e-mail]>
>
>     *From:* Alexander Vainshtein
>     *Sent:* Friday, June 8, 2018 5:43 PM
>     *To:* '[e-mail] <mailto:[e-mail]>'
>     <[e-mail]> <mailto:[e-mail]>;
>     '[e-mail]
>     <mailto:[e-mail]>'
>     <[e-mail]>
>     <mailto:[e-mail]>
>     *Cc:* '[e-mail] <mailto:[e-mail]>' <[e-mail]>
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>;
>     '[e-mail] <mailto:[e-mail]>'
>     <[e-mail]> <mailto:[e-mail]>
>     *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/
>
>     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
>
>     *Document*: draft-ietf-spring-segment-routing-mpls-13
>
>     *Reviewer*: Alexander (“Sasha”) Vainshtein
>     ([e-mail]
>     <mailto:[e-mail]>)
>
>     *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://tools.ietf.org/html/draft-ietf-spring-segment-routing-15>
>     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://tools.ietf.org/html/rfc8287> 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://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-01> 
> /**/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./*
>
##Ahmed: The main reference for this draft is the sr-architecture, which 
clearly states that multicast is out of SR scope. SR-MPLS, being an MPLS 
instantiation of the SR-architecture, follows the SR-architecture as 
close as possible. If another draft proposes something related to SR, 
then it is the responsibility of the other draft to mention any 
extensions/restrictions in relation to the basic 
draft-ietf-spring-segment-routing and/or SR-MPLS, or to specifically say 
that it does not apply to SR-MPLS.
>
>     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. /*
>
/*#Ahmed: Binding SID is just a special case of a SID. So what applies 
to a SID applies to a binding SID*/
>
> *//*
>
>     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./*
>
/*##Ahmed: The setting of the TTL for non-OAM packets are subject to the 
policy that constructed the label stack. SR-policy is handled in a 
separate draft */
>
> *//*
>
>
>
>     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?/*
>
/*##Ahmed: Part (a) here is a statement not a question. What is the 
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://tools.ietf.org/html/rfc4291#section-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?/*
>
/*##Ahmed: The basic MPLS architecture does not forbid assigning 
different labels to the same prefix, nonetheless to different prefixes 
belonging to the same node or the same interface on the same node. One 
of the fundamental concepts of SR-MPLS is that the same prefix-SID must 
not be assigned to two different prefixes. So for the particular 
scenario of embedding IPv4 in IPv6, the operator must assign different 
SIDs to the IPv4 address and the IPv4-mapped IPv6 address that embeds 
it, otherwise the label will be subject to the incoming label collision 
resolution

*/
>
> *//*
>
>
>
>     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. /*
>
/*##Ahmed: *//*
*//*The last paragraph in Section 2 of 
*//*draft-ietf-spring-segment-routing-14*//*says*/

    We call "MPLS Control Plane Client (MCC)" any control plane entity
    installing forwarding entries in the MPLS data plane.

/*The sentence starting at the 5th line of the first bullet of Section 
2.5 of *//*draft-ietf-spring-segment-routing-14 *//*says*/

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

/*If a binding-SID is downloaded to the forwarding plane, then it must 
be associated with an MCC and hence it either has an "algorithm" or the 
value zero is assumed for the "algorithm" field. If the binding-SID is 
not downloaded to the forwarding plane, then it is irrelevant to the 
entire draft not only to incoming label collision*/
>
>
>     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. /*
>
/*##Ahmed: OK., I think we are in agreement here:)*/
>
> *//*
>
>
> 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. /*
>
/*##Ahmed: The  term "routing instance" within the context of incoming 
label collision is defined in the first bullet in Section 2.5.
As for any recommendation for useage of node-SID, anycast-SID,...,etc , 
it is out of the scope of this draft because it is a matter of of 
deployment/informational/BCP draft
*/
>
> *//*
>
>
>
>     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?/*
>
/*##Ahmed: OK. Added a sentence to the last paragraph of section 2.3*/
>
> *//*
>
>
>
>     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/**/. /*
>
/*##Ahmed: The SR-MPLS draft that we are discussing here does not 
attempt to modify the SR-architecture draft. *//*Any concerns related to 
the SR-architecture should be addressed to the SR-architecture draft not 
to this draft. */
>
> *//*
>
>
>
>     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./*
>
/*##Ahmed: incoming label collision defines what is a routing instance 
within its context. I do not understand what explanation you are looking 
for*/
>
> *//*
>
>
>
>
>     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://tools.ietf.org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-04>
>     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?/*
>
/*##Ahmed: The example in the draft is included to clarify the concept 
of a prefix SID attached to a prefix. As mentioned more than once, 
SR-MPLS does not modify MPLS forwarding including *//*/*pushing a label 
on a labeled packet. It is something that has been done by routers and 
switches for 20+ years. */So including it here is redundant*/
>
> *//*
>
>     *Nits*:
>
>     1.I concur with Adrian regarding numerous nits he has reported in
>     his WG LC Comment
>     <https://mailarchive.ietf.org/arch/msg/spring/FRhO2lgR8r4VlKP2ZN2dZwHU5BY>.
>     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://tools.ietf.org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-04>
>     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./*
>
/*##Ahmed: I did not add rfc5331 as a reference . Again pushing multiple 
labels on top of a packet is a matter of SR-policy, which is handled in 
a separate draft. */
>
> *//*
>
>
>
>
>     Hopefully, these comments will be useful.
>
> #Ahmed: They are certainly quite useful. Thanks a lot
>
>     Regards,
>
>     Sasha
>
>     Office: [phone]
>
>     Cell:      [phone]
>
>     Email: [e-mail]
>     <mailto:[e-mail]>
>
>
>     ___________________________________________________________________________
>
>     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.
> ___________________________________________________________________________