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

[Przemyslaw Krol <[e-mail]>]

Hi Shraddha

I think this would be very helpful.

pk

On Sun, Nov 18, 2018 at 8:39 PM Shraddha Hegde <[e-mail]> 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
>
> > 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 <[e-mail]>
> *Sent:* Sunday, November 4, 2018 9:37 PM
> *To:* Ahmed Bashandy <[e-mail]>
> *Cc:* [e-mail]; '[e-mail]' <[e-mail]>; '
> [e-mail]' <[e-mail]>; Jonathan Hardwick (
> [e-mail]) <[e-mail]>;
> [e-mail]; [e-mail];
> [e-mail]; Shraddha Hegde <
> [e-mail]>
> *Subject:* RE: RtgDir Early review:
> 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)”.
>
> 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: [phone]
>
> Cell:      [phone]
>
> Email:   [e-mail]
>
>
>
> *From:* Ahmed Bashandy [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Sunday, October 28, 2018 1:01 AM
> *To:* Shraddha Hegde <[e-mail]>; Alexander Vainshtein <
> [e-mail]>
> *Cc:* [e-mail]; '[e-mail]' <[e-mail]>; '
> [e-mail]' <[e-mail]>; Jonathan Hardwick (
> [e-mail]) <[e-mail]>;
> [e-mail]; [e-mail];
> [e-mail]
> *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 <[e-mail]>
> <[e-mail]>
> *Sent:* Thursday, July 19, 2018 10:05 PM
> *To:* Ahmed Bashandy <[e-mail]> <[e-mail]>
> *Cc:* [e-mail]; '[e-mail]' <[e-mail]> <[e-mail]>; '
> [e-mail]' <[e-mail]> <[e-mail]>;
> Jonathan Hardwick ([e-mail])
> <[e-mail]> <[e-mail]>;
> Shraddha Hegde <[e-mail]> <[e-mail]>;
> [e-mail]; [e-mail];
> [e-mail]
> *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: [phone]
>
> Cell:      [phone]
>
> Email:   [e-mail]
>
>
>
> *From:* Ahmed Bashandy [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Thursday, July 19, 2018 7:13 PM
> *To:* Alexander Vainshtein <[e-mail]>
> *Cc:* [e-mail]; '[e-mail]' <[e-mail]>; '
> [e-mail]' <[e-mail]>; Jonathan Hardwick (
> [e-mail]) <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *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: [phone]
>
> Cell:      [phone]
>
> Email:   [e-mail]
>
>
>
> *From:* Alexander Vainshtein
> *Sent:* Wednesday, July 11, 2018 12:02 PM
> *To:* Ahmed Bashandy <[e-mail]> <[e-mail]>
> *Cc:* [e-mail]; '[e-mail]' <[e-mail]> <[e-mail]>; '
> [e-mail]' <[e-mail]> <[e-mail]>;
> Jonathan Hardwick ([e-mail])
> <[e-mail]> <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *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: [phone]
>
> Cell:      [phone]
>
> Email:   [e-mail]
>
>
>
> *From:* Ahmed Bashandy [mailto:[e-mail]
> <[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];
> [e-mail]
> *Cc:* [e-mail]; [e-mail]; '[e-mail]'; '
> [e-mail]'; Jonathan Hardwick ([e-mail]);
> [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]
>
>
>
> *From:* Alexander Vainshtein
> *Sent:* Friday, June 8, 2018 5:43 PM
> *To:* '[e-mail]' <[e-mail]>
> <[e-mail]>; '
> [e-mail]'
> <[e-mail]>
> <[e-mail]>
> *Cc:* '[e-mail]' <[e-mail]> <[e-mail]>;
> [e-mail]; [e-mail]; '[e-mail]'
> <[e-mail]> <[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/
> <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 (
> [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://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: [phone]
>
> Cell:      [phone]
>
> Email:   [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.
> ___________________________________________________________________________
>
>
>
>
> ___________________________________________________________________________
>
> 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.
> ___________________________________________________________________________
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>


-- 
Przemyslaw "PK" Krol |  Strategic Network Engineer ing | [e-mail]