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
Email: [email protected]
From: spring [mailto:[email protected]] On Behalf Of Mach Chen
Sent: Friday, July 13, 2018 11:45 AM
To: Alexander Vainshtein <[email protected]>;
[email protected]
Cc: [email protected]
Subject: Re: [spring] A question about Path Segment draft
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 protected]]
Sent: Friday, July 13, 2018 3:36 PM
To:
[email protected]<mailto:[email protected]>;
Mach Chen <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: Re: A question about Path Segment draft
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 protected]<mailto:[email protected]>>
Sent: Friday, July 13, 2018 5:04:22 AM
To: Alexander Vainshtein;
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
Subject: RE: A question about Path Segment draft
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 protected]]
Sent: Thursday, July 12, 2018 6:00 PM
To:
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
Subject: A question about Path Segment draft
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 protected]<mailto:[email protected]>
___________________________________________________________________________
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
[email protected]
https://www.ietf.org/mailman/listinfo/spring
