Re: [mpls] Resolution of issues raised in my early review of draft-ietf-spring-segment-routing-mpls-13

[<[e-mail]>]

Sasha,

Many thanks for your RTG directorate review and for following-up over the months.
Very useful.

--Bruno

From: mpls [mailto:[e-mail]] On Behalf Of Alexander Vainshtein
Sent: Sunday, November 25, 2018 3:42 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: [mpls] Resolution of issues raised in my early review of draft-ietf-spring-segment-routing-mpls-13

Dear all,
I did an early RtgDir review of draft-ietf-spring-segment-routing-mpls-13<https://www.ietf.org/mail-archive/web/spring/current/msg03762.html> in June, and since then has been discussing the draft with the authors.

Now that a -16 version of the draft<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-16> has been published, I think that all the issues I have raised then have been resolved - one way or another.

The table below summarizes the current status of these issues (including a nit that I have raised following publication of the -14 version of the draft):

Issue

Current status

Comments


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.

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

Fully resolved

The last para in Section 2.2 explicitly states that "Labels allocated in this document are considered per platform down-stream allocated labels" and explicitly references RFC 3031.


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

Fully resolved

See the previous comment.

In addition, Section 2.7.3.1 explicitly defines Mirror SIDs and their relationship with context labels and context label spaces defined in RFC 5331.

Note: I am not sure that the Mirror SID can be considered as a generalization of the context label (the last sentence in Section 2.7.3.1).

The relevant text in 8402 says:

In the event of a failure, a Point of Local Repair (PLR) diverting  traffic from A to B does a PUSH of the Mirror SID on the protected traffic..  When receiving the traffic with the Mirror SID as the active segment, B uses that segment and processes underlying segments in the context of A.

>From my POV, in SR-MPLS the "underlying segments" (in the highlighted text above) are labels following the Mirror SID label, i.e., per RFC 8402 a Mirror SID  cannot be the last label in the stack.

It would be nice to clarify this point.


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.

Fully resolved

The relevant text has been added to Section 2.7.1. It has been copied from RFC 8277.


4.      Inferring network protocol in SR-MPLS (the details are omitted)

Withdrawn

This has been discussed with the authors who have pointed out that prefix- and Adj-SIDs are always associated with a specific network protocol (IPv4 and IPv6).


5.      Resolution of Conflicts:

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?

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

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?

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

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


Fully resolved

Parallel adjacencies and Mirror SIDs have been added to the section describing conflict resolution.



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)

Fully resolved

The text discussing the need for Node-SIDs in SR-MPLS, potential conflicts that can be associated with these SIDs and their recommended resolution in the last para in Section 2.



7.      SRGB Size in SR-MPLS

Fully Resolved

The current revision of the draft explicitly marks this issue as left FFS in 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

b.      From my POV, the draft should explicitly state that the default Prefix-SID algorithm MUST be implemented in all SR-MPLS-compliant routers

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?

Withdrawn




9.      Routing instances and the context for Prefix-SIDs

Fully Resolved

The authors have clarified that routing instances are only mentioned in the context of incoming conflict resolution, and the draft explicitly states that.


10.  Example of PUSH operation in Section 2.10.1

Withdrawn

TI-LFA mentioned as an example of  PUSH operation


11.  Numerous nits reported by Adrian

Fully resolved




12.  NIT: TI-LFA spelled as Ti-LFA

Fully resolved




13.  NIT: Missing Informational reference to TI-LFA draft

Fully resolved

The reference  to the TI-LFA draft has been added


14.  NIT: Missing references to RFC 3443, 5332 and 5331

Fully resolved

References to RFC 3443  and RFC 5331 have been added. I agree that there is no need for a reference to RFC 5332.


15.  NIT: Missing reference to RFC 8287

Fully Resolved

 The reference has been added


16.  NIT: Problematic grammar in the first statement of the last para in Section 2.3:
Local segments MAY be allocated from the Segment Routing Local Block (SRLB) [RFC8402<https://tools.ietf.org/html/rfc8402>] or from any unused label as long as it does not use a special purpose label

Fully resolved

The grammar issue (introduced in the -14 version) has been fixed.


Hopefully this summary will be useful.

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.