Yimin,
Again, lots of thanks for a prompt response.
I am adding the SPRING WG list to the distribution of this message, because,
from my POV, it raises an issue that should be answered – one way or another –
by the SPRING experts.
I do not think that agree that End.DT6 requires augmentation for correct
processing of the Mirror SID. All that is required is to set the Next Header
value (in the outer IPv6 header or in the outer SRH if it is used) to 41 (IPv6).
I also have to admit that, in spite of your reference to RFC 86667, I do not
understand why Mirror SID must be represented by an index in SRGB in SRv6. From
my POV:
1. RFC 8402 says that:
a. Mirror SID is a special case of a Binding SID
b. A Binding SID may be local or global, and, if it is local, SHOULD be
allocated from the SRLB (and not from the SRGB)
2. RFC 8667 says that:
a. Mirror SID is advertised using the SID/Label Binding TLV with M-flag
set
b. SID/Label Sub-TLV MUST be present in the SID/Label Binding TLV if
M-flag is set
3. SID/Label Sub-TLV can be used to carry both labels and indices, but
it cannot advertise anything else (e.g., a SRv6 SID)
a. It seems that this is why you think that it MUST be associated with an
index in SRGB, Is this correct?
b. Another interpretation, of course, is that SRv6 has not really defined how
Mirror SIDs are advertised:
i. SRGB for SRv6 is simply defined in RFC 8402 as “the
set of global SRv6 SIDs in the SR domain”
ii. This RFC
does not ever mention usage of indices in connection with SRv6 SIDs. Instead,
it always says that SIDs can be advertised as indices, labels or addresses, and
from my POV the latter refers to all forms of SRv6 SIDs.
My questions to the SPRING WG are:
1. Is Binding SID and, as its special case, Mirror SID) always global in
SRv6? (In SR-MPLS both can be local of course)
2. Are global SIDs in SRv6 associated with any indices and, if yes, how
are these indices converted to routable IPv6 addresses?
3. Are local SIDs possible in SRv6, and, if yes, how can they be
advertised? One use case could be an IGP adjacency across an interface that is
not configured with any routable IPv6 addresses.
Hopefully these notes will be of some interest.
Regards, and lots of thanks in advance,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: alexander.vainsht...@ecitele.com
From: Yimin Shen <ys...@juniper.net>
Sent: Tuesday, February 25, 2020 4:26 PM
To: Alexander Vainshtein <alexander.vainsht...@ecitele.com>
Cc: rt...@ietf.org; Huaimo Chen <huaimo.c...@futurewei.com>
Subject: Re: Mail regarding draft-hu-rtgwg-srv6-egress-protection
Hi Sasha,
Just to correct one thing in my previous email -- In SRv6, a mirror SID
(containing an IPv6 context ID) is routable via the shortest path to protector
P. This is because in the SID/Label Binding TLV (RFC 8667), the SID/Label
sub-TLV must contain an index (to the SRGB), which will automatically make the
mirror SID routable on all SR routers.
Given that, an PLR may use a mirror SID as a bypass path, if and only if the
shortest path from the PLR to P does not traverse the router E. But this must
be verified by bypass path computation.
Therefore, items [5] and [6] should be updated as below:
[5] PLR should set up a backup forwarding state as below:
[5.1] Keep packet’s original IPv6 header and SRH header unchanged.
[5.2] Push a new IPv6 header to the packet. There are two cases:
[5.2.1] If the path of the mirror SID (i.e. the shortest path from PLR to P)
doesn’t traverse E, Set DA = context ID, no SRH is needed. This is H.Encap.
[5.2.2] Otherwise, an explicit path must be used. Assuming the SID list is <S1,
S2,…, Sn>, set DA = S1, and SRH = <S1, S2, …, Sn, mirror SID>, SL = n. A new
“H.Encap.Mirror” would need to be defined.
[6] When P receives a re-routed packet, it should get the mirror SID (i.e.
context ID) from the outer IPv6 header, remove this outer IPv6 header, and
continue to process the inner IPv6 header. When processing the inner IPv6
header, P should process E’s VPN SID by using the mapping indicated by the
mirror SID (i.e. context ID).
There are two steps of SID processing above – (a) Use the mirror SID to set up
the context, and (b) look up the VPN SID in that context. I agree (b) is
End.DT6, but there would need a new End behavior for (a). Alternatively, a new
End behavior may be defined for (a) and (b) together.
Thanks,
-- Yimin
From: Alexander Vainshtein
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>
Date: Tuesday, February 25, 2020 at 8:37 AM
To: Yimin Shen <ys...@juniper.net<mailto:ys...@juniper.net>>
Cc: "rt...@ietf.org<mailto:rt...@ietf.org>"
<rt...@ietf.org<mailto:rt...@ietf.org>>, Huaimo Chen
<huaimo.c...@futurewei.com<mailto:huaimo.c...@futurewei.com>>
Subject: RE: Mail regarding draft-hu-rtgwg-srv6-egress-protection
Ymin,
Lots of thanks for a prompt and very detailed response to my comments.
I think that the scheme you have shared in your mail provides a very reasonable
description of the PLR behavior. I fully agree that the definitions you’ve
provided extend and clarify the definitions of the Headend behavior in the SRv6
Network Programming
draft<https://clicktime.symantec.com/a/1/aJUs9Gofce8YTesUKXcSaQlwlRI4RaL8Jde0t7Fgj6s=?d=frO-agcgs9Ob-OF68ucVFSzoRkjlWJ0MWrchPwKexaxXfzxSurCkZGTMTtKKczPn9GUN6sKjHig8wqujEH6DfW02-NKIZWnKkGctLmBjrQDBQ0xxe2X5CxS0qR5ThQa9soNeK7mTpiTNTIP6rHC1LNzkDxEuFEKNB0D6ORB7VIoh6ESynjf-Qo2DF35pu1ozeL61u0kVV5aOzKWWbXm6XOEsYffSVygZ7v_h85ESRrAyZhJL48mzKZz9qJK1heESPWtsXW4Cop4Z6LZvSPY18omjlaLJyZzdJ3BapdCjNBvEyZ_NwEwbEiRGwJEsJT7bDj0NXZx_E8U8AzPcky2j55rD_c3XLsGIDzq6JRVgYQssDt-a0mclmA7M9Tfu-o_uItU5MLPp3ZrNNU1DyTn3879gnlZQ6SxJ2oMwPfMG_KqT_FiIE-5rGOEY2uVNDyZiYHdxtun43A%3D%3D&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-srv6-network-programming-10__%3B%21%21NEt6yMaO-gk%21UjGh8V5stOa02aYOK3_XrRYuSqfuTowH4KJ__K2zMvGSAFukGS5Esaj4XGADVFI%24>.
I also think that your our description of the Protector behavior (“When P
receives a re-routed packet, it should get the mirror SID (i.e. context ID)
from the outer IPv6 header, remove this outer IPv6 header, and continue to
process the inner IPv6. When processing the inner IPv6 header, P should process
E’s VPN SID by using the mapping indicated by the mirror SID (i.e. context ID)”
) should be explicitly mapped to one of the SRv6 Endpoint behaviors described
in the SRv6 Network Programming
draft<https://clicktime.symantec.com/a/1/aJUs9Gofce8YTesUKXcSaQlwlRI4RaL8Jde0t7Fgj6s=?d=frO-agcgs9Ob-OF68ucVFSzoRkjlWJ0MWrchPwKexaxXfzxSurCkZGTMTtKKczPn9GUN6sKjHig8wqujEH6DfW02-NKIZWnKkGctLmBjrQDBQ0xxe2X5CxS0qR5ThQa9soNeK7mTpiTNTIP6rHC1LNzkDxEuFEKNB0D6ORB7VIoh6ESynjf-Qo2DF35pu1ozeL61u0kVV5aOzKWWbXm6XOEsYffSVygZ7v_h85ESRrAyZhJL48mzKZz9qJK1heESPWtsXW4Cop4Z6LZvSPY18omjlaLJyZzdJ3BapdCjNBvEyZ_NwEwbEiRGwJEsJT7bDj0NXZx_E8U8AzPcky2j55rD_c3XLsGIDzq6JRVgYQssDt-a0mclmA7M9Tfu-o_uItU5MLPp3ZrNNU1DyTn3879gnlZQ6SxJ2oMwPfMG_KqT_FiIE-5rGOEY2uVNDyZiYHdxtun43A%3D%3D&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-srv6-network-programming-10__%3B%21%21NEt6yMaO-gk%21UjGh8V5stOa02aYOK3_XrRYuSqfuTowH4KJ__K2zMvGSAFukGS5Esaj4XGADVFI%24>
with clarifications and extensions if necessary (End.DT6 looks like a
reasonable candidate to me).
Without these clarifications it is difficult for me to say whether the draft is
a good start – one of the two basic requirements for adopting the draft as a WG
document.
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email:
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>
From: Yimin Shen <ys...@juniper.net<mailto:ys...@juniper.net>>
Sent: Monday, February 24, 2020 6:10 PM
To: Alexander Vainshtein
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>;
Huaimo Chen <huaimo.c...@futurewei.com<mailto:huaimo.c...@futurewei.com>>
Cc: rt...@ietf.org<mailto:rt...@ietf.org>; Yimin Shen
<ys...@juniper.net<mailto:ys...@juniper.net>>
Subject: Re: Mail regarding draft-hu-rtgwg-srv6-egress-protection
I believe Sasha has raised a good point regarding the usage of mirror SIDs in
this document.
According RFC 8402 section 5.1, a mirror SID
---
“is to provide support for an IGP node to advertise its ability to process
traffic originally destined to another IGP node, called the "mirrored node" and
identified by an IP address or a Node-SID, provided that a Mirroring Context
segment is inserted in the segment list prior to any service segment local to
the mirrored node.
When a given node B wants to provide egress node A protection, it advertises a
segment identifying node's A context. Such a segment is called "Mirroring
Context segment" and is identified by the Mirror SID.”
---
RFC 8667 specifies the advertisement of a mirror SID (for ISIS) via the
SID/Label Binding TLV. The TLV contains a prefix, M-flag =1, and a SID/Label
sub-TLV. So, there are two cases. If the SID/Label sub-TLV contains an index
(to the SRGB), the mirror SID is routable. If it contains a label, the mirror
SID is not routable. The draft assumes the mirror SID to be routable, but both
cases should be considered.
If we put RFC 8402, 8667 and 8679 together, we can basically get a high level
solution for SRv6 egress protection, shared below:
[1] A protector (P) advertises a mirror SID for each egress node (E) which P
protects. It identifies the primary-and-protector relationship between E and P.
It indicates P's capability of processing E's SID (or E's SID list) contained
in re-routed packets which are originally destined for E. The granularity of
mirror SIDs is per ordered pair of <E, P>, not per VPN locator.
[2] The prefix contained in this mirror SID is the IPv6 context ID of <E, P>.
[3] When E advertises each VPN SID, E should attach the mirror SID (i.e.
context ID) to the VPN SID, to indicate P’s identity to PLR(s). This is needed
regardless of whether the locator in the VPN SID is routable or non-routable.
[4] Each PLR performs bypass path computation for the context ID. (Per previous
comments, the draft needs to provide the details of this calculation.)
[5] PLR should set up a backup forwarding state as below (some is similar to
what Sasha suggested):
[5.1] Keep packet’s original IPv6 header and SRH header unchanged.
[5.2] Push a new IPv6 header to the packet. This new IPv6 header may be
constructed in two ways, depending on whether the mirror SID (i.e. the context
ID) is routable or non-routable.
[5.2.1] If the mirror SID (i.e. context ID) is routable, Set DA = context ID,
no SRH is needed.
[5.2.2] If the mirror SID (i.e. context ID) is non-routable, there are two
sub-cases:
[a] If the bypass path coincides with the shortest path from the PLR to P, set
DA = P's node SID, SRH = <P’s node SID, mirror SID>, SL = 1.
[b] If the bypass path is an explicit path corresponding to a SID list <S1,
S2,…, Sn>, set DA = S1, and SRH = <S1, S2, …, Sn, mirror SID>, SL = n.
Note that only [4.2.1] is similar to H.Encap defined in
draft-ietf-spring-srv6-network-programming. The other behaviors need be defined.
[5] When P receives a re-routed packet, it should get the mirror SID (i.e.
context ID) from the outer IPv6 header, remove this outer IPv6 header, and
continue to process the inner IPv6. When processing the inner IPv6 header, P
should process E’s VPN SID by using the mapping indicated by the mirror SID
(i.e. context ID).
Finally, a few general comments on this draft:
- The draft currently uses an example (IMO, simplistic) to describe
the mechanism. Please consider having a section of generic theory of operation,
and then use an example to illustrate.
- Do not put the above comments directly in the draft. By no means I’m
writing the text for this draft.
Thanks,
-- Yimin
From: Alexander Vainshtein
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>
Date: Sunday, February 23, 2020 at 7:01 AM
To: Yimin Shen <ys...@juniper.net<mailto:ys...@juniper.net>>, Huaimo Chen
<huaimo.c...@futurewei.com<mailto:huaimo.c...@futurewei.com>>
Cc: "rt...@ietf.org<mailto:rt...@ietf.org>"
<rt...@ietf.org<mailto:rt...@ietf.org>>
Subject: RE: Mail regarding draft-hu-rtgwg-srv6-egress-protection
Dear all,
I concur with Yimin's comments in his last email.
I have also an additional concern regarding support of a Mirror SID in SRv6.
This concern is based on the following observations:
1. As per RFC 8402, a Mirror SID is a special case of the Binding SID
2. In SR-MPLS, a Mirror SID is defined as a generalization of the Context
label as defined RFC 5331. If it is not the last label in the label stack,
then, to the best of my understanding, it is just the Context label identifying
the context label space in which the next label (representing the next SID in
the list) is looked up. in other words, ability of SR-MPLS to support Mirror
SID is based on support of context labels and context label spaces in the MPLS
DP. IMHO and FWIW it would not work with the MPLS DP as defined in RFC 3031 and
3032.
3. As mentioned in the email by Zhibo
Hu<https://clicktime.symantec.com/a/1/9_O3SINBr8OxkRrLyJNEgOqApyP0UIgTyA6GEuIGlZQ=?d=frO-agcgs9Ob-OF68ucVFSzoRkjlWJ0MWrchPwKexaxXfzxSurCkZGTMTtKKczPn9GUN6sKjHig8wqujEH6DfW02-NKIZWnKkGctLmBjrQDBQ0xxe2X5CxS0qR5ThQa9soNeK7mTpiTNTIP6rHC1LNzkDxEuFEKNB0D6ORB7VIoh6ESynjf-Qo2DF35pu1ozeL61u0kVV5aOzKWWbXm6XOEsYffSVygZ7v_h85ESRrAyZhJL48mzKZz9qJK1heESPWtsXW4Cop4Z6LZvSPY18omjlaLJyZzdJ3BapdCjNBvEyZ_NwEwbEiRGwJEsJT7bDj0NXZx_E8U8AzPcky2j55rD_c3XLsGIDzq6JRVgYQssDt-a0mclmA7M9Tfu-o_uItU5MLPp3ZrNNU1DyTn3879gnlZQ6SxJ2oMwPfMG_KqT_FiIE-5rGOEY2uVNDyZiYHdxtun43A%3D%3D&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F397J25GUxhisvSuUz3BV2M46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fmailarchive.ietf.org%2A2Farch%2A2Fmsg%2A2Frtgwg%2A2FJ2fJ3PF-bIYIeRzeWG83QpqpAR4%2A2F__%2A3B%2A21%2A21NEt6yMaO-gk%2A21V-obNn_H2GxE-5f1nt8OkBTJoJf0qTAdCWwntY6AQ4cWAHhLMUjV4C237QgDmVE%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSU%21%21NEt6yMaO-gk%21UjGh8V5stOa02aYOK3_XrRYuSqfuTowH4KJ__K2zMvGSAFukGS5Esaj49wxx3KE%24>,
“The behavior of PLR encapsulating Mirror Sid is the same as that of SRv6
Ti-LFA。draft-ietf-spring-srv6-network-programming section 5.1 has been
mentioned that H.Encap is used to encapsulate the TiLFA Repair List”. I assume
that this what the draft in question intends to do, i.e.,:
* Push a new IPv6 header and a new SRH on the original packet.
i. The new
SRH would include the Node SID of the Protector node and the Mirror SID
ii. The
destination IPv6 address would be the address of the Protector node
iii. The Next
Header value in the SRH would be IPv6
* Decrement the TTL in the inner IPv6 header
* Forward the packet towards the Protector node.
1. This technique would work just fine in the case when the inserted SID
refers to a topological instruction (as in the case of Ti-LFA or in the case
when a binding SID represented an SR policy. But I do not understand how it
could be used with SIDs that are not topological instructions without any
updates to IPv6 data plane.
My 2c,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email:
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>
-----Original Message-----
From: rtgwg <rtgwg-boun...@ietf.org<mailto:rtgwg-boun...@ietf.org>> On Behalf
Of Yimin Shen
Sent: Sunday, February 23, 2020 4:10 AM
To: Huaimo Chen <huaimo.c...@futurewei.com<mailto:huaimo.c...@futurewei.com>>;
rt...@ietf.org<mailto:rt...@ietf.org>
Subject: Re: Mail regarding draft-hu-rtgwg-srv6-egress-protection
Hi Huaimo, Authors,
>> Step 1: Find the P-Space P(Z, X) and the Q-Space Q(Y, X), which are similar
>> to those in [RFC7490];
Unfortunately this is not a right solution. As I mentioned before, in egress
protection, bypass path computation should not rely on LFA, because it is not
finding a path to merge back to the protected/primary router. I have already
suggested in a previous email to remove the link between PE3 and PE4, to make
your discussion more generic. Similarly, the draft should not assume there is a
multi-hop path from PE4 to PE3 which does not traverse P1. Your mechanism must
be able to return a bypass path in these cases. My suggestion is to take the
guidelines in RFC 8679, and use context-IDs as locators.
>> Step 5: Try to find a shortest path from Z to Y without going through X;
As a transit router, Z is supposed to perform generic bypass calculation for X
(like other IPv6 addresses), based on a general FRR logic. So, how would Z even
know to "Try" in this step ? What is it trying ? Isn't this "shortest path from
Z to Y without going through X" the bypass path you are looking for in Step 1 -
3 ?
>> For a (primary) locator associated with the (primary) egress node of a SR
>> path/tunnel, most often the locator is routable. This is the case we
>> assumed,
Non-routable locator should be supported, and it can be supported. In this
case, bypass path calculation should be based on BGP nexthop. Again, please
refer to RFC 8679 regarding how to use context-ID as BGP nexthop for a solution.
Thanks,
-- Yimin
From: Huaimo Chen <huaimo.c...@futurewei.com<mailto:huaimo.c...@futurewei.com>>
Date: Friday, February 21, 2020 at 11:45 PM
To: Yimin Shen <ys...@juniper.net<mailto:ys...@juniper.net>>,
"rt...@ietf.org<mailto:rt...@ietf.org>" <rt...@ietf.org<mailto:rt...@ietf.org>>
Subject: Re: Mail regarding draft-hu-rtgwg-srv6-egress-protection
Hi Yimin,
Thanks much for your comments.
The procedure with details that a PLR uses to compute a backup path has
been added into the draft, which has been uploaded.
Best Regards,
Huaimo
Hi Huaimo, authors,
>>> Node P1's pre-computed backup path for PE3 is from P1 to PE4 via P2.
I’m still concerned that there is no details in this draft about the procedures
how a PLR computes a backup path to the protector, in both of the two cases
below.
[1] the primary locator is routable.
[2] the primary locator is not routable.
Thanks,
-- Yimin
_______________________________________________
rtgwg mailing list
rt...@ietf.org<mailto:rt...@ietf.org>
https://clicktime.symantec.com/3F1LB8RvcSLpHAYLrEmGjgH6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frtgwg<https://clicktime.symantec.com/a/1/iIvjHZeOHLzeBp4K8WquAqttuwJAjnpmp5zlYj2adko=?d=frO-agcgs9Ob-OF68ucVFSzoRkjlWJ0MWrchPwKexaxXfzxSurCkZGTMTtKKczPn9GUN6sKjHig8wqujEH6DfW02-NKIZWnKkGctLmBjrQDBQ0xxe2X5CxS0qR5ThQa9soNeK7mTpiTNTIP6rHC1LNzkDxEuFEKNB0D6ORB7VIoh6ESynjf-Qo2DF35pu1ozeL61u0kVV5aOzKWWbXm6XOEsYffSVygZ7v_h85ESRrAyZhJL48mzKZz9qJK1heESPWtsXW4Cop4Z6LZvSPY18omjlaLJyZzdJ3BapdCjNBvEyZ_NwEwbEiRGwJEsJT7bDj0NXZx_E8U8AzPcky2j55rD_c3XLsGIDzq6JRVgYQssDt-a0mclmA7M9Tfu-o_uItU5MLPp3ZrNNU1DyTn3879gnlZQ6SxJ2oMwPfMG_KqT_FiIE-5rGOEY2uVNDyZiYHdxtun43A%3D%3D&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3TrsjdFhRRm4aE9TBxouLoc6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3F1LB8RvcSLpHAYLrEmGjgH6H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Fwww.ietf.org%2A2A2Fmailman%2A2A2Flistinfo%2A2A2Frtgwg__%2A3BJSUlJSUl%2A21%2A21NEt6yMaO-gk%2A21V-obNn_H2GxE-5f1nt8OkBTJoJf0qTAdCWwntY6AQ4cWAHhLMUjV4C23Pywcm-4%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl%21%21NEt6yMaO-gk%21UjGh8V5stOa02aYOK3_XrRYuSqfuTowH4KJ__K2zMvGSAFukGS5Esaj4p0QDwIE%24>
___________________________________________________________________________
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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
