Subject: [spring] A question about Path Segment draft

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Jul 2018 09:59:44 +0000

Dear colleagues,
One of the issues I've raised during my Early RTG-DIR review<https://datatracker.ietf.org/doc/review-ietf-spring-segment-routing-mpls-13-rtgdir-early-vainshtein-2018-06-10/> of the SR-MPLS<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-14> draft dealt the way in which identity of the network protocol of the packet can be inferred when the label that represents some segment ID happens to be the bottom-of-stack label.

The Editors' response<https://www.ietf.org/mail-archive/web/spring/current/msg03877.html> was that for labels representing Prefix and Adjacency SIDs, the network protocol of such a packet is always either Ipv4 and IPv6. For Prefix SIDs this is obvious and for Adjacency SIDs IPv4 vs. IPv6 is indicated by the F-Flag in the corresponding IS-IS TLV (or its analogs for OSPF). This is also applicable for Binding SID because it refers to a specific prefix (or a range of prefixes from the same family).

>From my POV this response is sufficient in the context of the SR-MPLS. However, it does not help in the case of Path Segments introduced with your draft.

One use case for the label representing a Path Segment being BoS is LSP Ping (RFC 8029) for Segment Routing (RFC 8287) since both IPv4 and IPv6 packets can follow the BoS label in LSP Ping. It is not even clear whether packets immediately following the Path Segment label that is BoS can be neither IPv4 nor IPv6.

Your clarification of this point would be highly appreciated.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [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.
___________________________________________________________________________

---

From: Mach Chen <[email-masked]>
Date: Fri, 13 Jul 2018 02:04:22 +0000

Hi Sasha,

Thanks for your valuable question!

Since a Path Segment is just designed to identify an SR path,  if the Path Segment label is the BoS label, the network protocol of the packet should be the same as the one implied by the last label of the SR path. That means, no matter through signaling or configuration, when install a Path Segment label, the implicit network protocol can deduced from the last label of the SR path.

Hope this clarify the question, or maybe you have other suggestions.

Best regards,
Mach

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Thursday, July 12, 2018 6:00 PM
To: [email-masked]
Cc: [email-masked]
Subject: A question about Path Segment draft

Dear colleagues,

Regards,
Sasha

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 13 Jul 2018 07:35:48 +0000

Mach hi!
Lots of thanks for a prompt response.
Unfortunately your pdoposal zeems problematic to me because in many cases the last label above the Path Segment one will be popped by the penultimate node (e.g. if it identifes an Adj-SID or a Node SID for which PHP has been advertised).

>From my POV the preferred solution could be limiting payload of tbe problematic packets to just IPv4 and IPv6 and using the 1st nibble of the payload to differentiate between them. AFAIK this is commonly supported by many existing chipsets, si implementing this would be reasonably simple. But of course this is for you and your co-authors to decide.

On another issue:
The draft offers 2 solutions, with the 2-label solution effectivel using upstream-allocated labels.

I hhave raised the issue of upstream-allicated labels in my early RTG-DIR review of the SR-MOLS draft, anx the curre t position of the Editkr is that only downstream-allocated labels are used in SR-MPLS.
This looks to me as precluding the 2-label solution.

My 2c

Thumb typed by Sasha Vainshtein

________________________________
From: Mach Chen <[email-masked]>
Sent: Friday, July 13, 2018 5:04:22 AM
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]
Subject: RE: A question about Path Segment draft

Hi Sasha,

Best regards,
Mach

Dear colleagues,
One of the issues I’ve raised during my Early RTG-DIR review<https://datatracker.ietf.org/doc/review-ietf-spring-segment-routing-mpls-13-rtgdir-early-vainshtein-2018-06-10/> of the SR-MPLS<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-14> draft dealt the way in which identity of the network protocol of the packet can be inferred when the label that represents some segment ID happens to be the bottom-of-stack label.

The Editors’ response<https://www.ietf.org/mail-archive/web/spring/current/msg03877.html> was that for labels representing Prefix and Adjacency SIDs, the network protocol of such a packet is always either Ipv4 and IPv6. For Prefix SIDs this is obvious and for Adjacency SIDs IPv4 vs. IPv6 is indicated by the F-Flag in the corresponding IS-IS TLV (or its analogs for OSPF). This is also applicable for Binding SID because it refers to a specific prefix (or a range of prefixes from the same family).

Regards,
Sasha

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

---

From: Mach Chen <[email-masked]>
Date: Fri, 13 Jul 2018 08:45:12 +0000

Hi Sasha,

Thanks for your prompt response.

Maybe I am not clear in my last email, my thought was not to deduce the network protocol from the last label above the Path segment label when a packet is received.  Because the last label of the SR path and its implied network protocol is known, the correlation between the network protocol and the Path Segment label will be deduced when the Path Segment label is signaled or configured and be installed in a local table.  Given this, a node (e.g., the egress) can know the network protocol by looking up the local table and know how to process the packet (e.g., pop the Path Segment label and continue process the payload according to the deduced network protocol).

Of cause, I also think you suggested solution workable.

Regarding the two solutions introduced in the draft, as noted in the draft, it intends to trigger the WG to discuss and decide which one is more preferred.  I still remember that you thought 1-label solution is more preferred in a previous discussion. Regarding the 2-label solution, if the only downstream-allocated labels are allowed in SR-MPLS, indeed the 2-label solution is precluded.  I am open with it, but I will let others to express their points.

Best regards,
Mach

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Friday, July 13, 2018 3:36 PM
To: [email-masked]; Mach Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: A question about Path Segment draft

Mach hi!
On another issue:

________________________________
From: Mach Chen <[email-masked]<mailto:[email-masked]>>
Sent: Friday, July 13, 2018 5:04:22 AM
To: Alexander Vainshtein; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: A question about Path Segment draft

Hi Sasha,

Best regards,
Mach

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Thursday, July 12, 2018 6:00 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: A question about Path Segment draft

Dear colleagues,

Regards,
Sasha

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 15 Jul 2018 08:47:40 +0000

Mach,
Lots of thanks for a prompt response and my apologies for the delay.

I am not sure whether delegating responsibility for specifying the type of payload that immediately follows the Path Segment label is a robust enough solution.

In any case it would be good if you could include the answer in the next revision of the draft.

Regarding non-usage of upstream-allocated labels in SR - let's wait for the next revision of the MPLS-SR draft.

Regards,
Sasha

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

From: spring [mailto:[email-masked]] On Behalf Of Mach Chen
Sent: Friday, July 13, 2018 11:45 AM
To: Alexander Vainshtein <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [spring] A question about Path Segment draft

Hi Sasha,

Best regards,
Mach

To: [email-masked]<mailto:[email-masked]>; Mach Chen <[email-masked]<mailto:[email-masked]>>

Mach hi!
On another issue:
The draft offers 2 solutions, with the 2-label solution effectivel using upstream-allocated labels.
I hhave raised the issue of upstream-allicated labels in my early RTG-DIR review of the SR-MOLS draft, anx the curre t position of the Editkr is that only downstream-allocated labels are used in SR-MPLS..
This looks to me as precluding the 2-label solution.
My 2c

Hi Sasha,

Best regards,
Mach

Dear colleagues,

Your clarification of this point would be highly appreciated..

Regards,
Sasha

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