Hi Sasha,
Thank you for your comments.
For the procedure (H.Encaps in section 5.1 of SRv6 Network Programming) you
mentioned, which may be used at PLR for TI-LFA
(I-D.ietf-rtgwg-segment-routing-ti-lfa), we will update our draft accordingly
for egress protection.
Regarding to your concerns based on the analogy to SR-MPLS, there should
not be any issue here. The mirror SID here is routable and can be used as
context ID. There is no need to change IPv6 data plane under SRv6 architecture.
Best Regards,
Huaimo
________________________________
From: Alexander Vainshtein <[email protected]>
Sent: Monday, February 24, 2020 12:31 PM
To: Greg Mirsky <[email protected]>
Cc: Yimin Shen <[email protected]>; Huaimo Chen
<[email protected]>; [email protected] <[email protected]>
Subject: Re: Mail regarding draft-hu-rtgwg-srv6-egress-protection
Greg and all,
My description of what happens at the PLR was just an attempt to combine a
message by Zhibo Hu (in which he refers to a specific procedure in the draft
and and the generic definition of this procedure. It is still not clear to me
whether this procedure equally applies to the "regular Binding SID" (bound to
an SR-TE Policy) and to the Mirror SID.
My concerns are based on the following analogy (which may be relevant or not):
In SR-MPLS, handling of the active Binding SID that is bound to an SR-TE Policy
simply means swap of the top label with a new label stack as defined in RFC
3031. But handling of a Mirror SID means that it is treated as the context
kabel so that tge next label is looked up in the context label space it
identifies as defined in RFC 5331; there is no way to handle it correctly if
your MPLS DP only supports the primitives defined in RFC 3031.
I am not sure that similar behavior has ever been defined for the IPv6 DP -even
augmented by the definition of the SRH.
My 2c.
Modification of the SRH by the PLR is in direct contradiction with RFC 8200..
Get Outlook for
Android<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fghei36&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C4ed004c869c141bddbb608d7b94f5b3e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637181622821119835&sdata=qv9wW%2FEO2tVJnK0OqMXd2M2VxnCkSXohuxpXTvftg6E%3D&reserved=0>
________________________________
From: Greg Mirsky <[email protected]>
Sent: Monday, February 24, 2020, 19:13
To: Alexander Vainshtein
Cc: Yimin Shen; Huaimo Chen; [email protected]
Subject: Re: Mail regarding draft-hu-rtgwg-srv6-egress-protection
Hi Sasha,
thank you for bringing the procedure a PLR to the discussion and providing your
understanding of the procedure at PLR:
a. 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
b. Decrement the TTL in the inner IPv6 header
c. Forward the packet towards the Protector node.
is very much different from the text in the draft:
P1 modifies the packet before
sending it to PE4. The modified packet has destination PE4 with
mirror SID A4:1::3, and SRH with PE3's VPN SID A3:1::B100 and the
mirror SID A4:1::3 (i.e., "A3:1::B100, A4:1::3; SL=1").
The former text describes what can be characterized as bypass tunneling, while
the latter is not. And I'm very much concerned that the procedure, as described
in the draft, breaks immutability of SRH and thus violates RFC 8200.
I'm looking forward to hearing from the authors how PLR procedure really works
- as described by you or as documented in the text.
That said, I do not support the adoption of the draft at this point.
Regards,
Greg
On Sun, Feb 23, 2020 at 4:01 AM Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
wrote:
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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2F32XmKo6nSvFvDEanEXdou986H2%3Fu%3Dhttps%253A%252F%252Fmailarchive.ietf.org%252Farch%252Fmsg%252Frtgwg%252FJ2fJ3PF-bIYIeRzeWG83QpqpAR4%252F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C4ed004c869c141bddbb608d7b94f5b3e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637181622821119835&sdata=DBGO28cuY9i9i8nuiDYB0DY3UCEsT1Z1mYUHvCcLIo8%3D&reserved=0>,
“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.,:
a. 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
b. Decrement the TTL in the inner IPv6 header
c. Forward the packet towards the Protector node.
4. 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:
[email protected]<mailto:[email protected]>
-----Original Message-----
From: rtgwg <[email protected]<mailto:[email protected]>> On Behalf
Of Yimin Shen
Sent: Sunday, February 23, 2020 4:10 AM
To: Huaimo Chen <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
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 <[email protected]<mailto:[email protected]>>
Date: Friday, February 21, 2020 at 11:45 PM
To: Yimin Shen <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
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
[email protected]<mailto:[email protected]>
https://clicktime.symantec.com/3F1LB8RvcSLpHAYLrEmGjgH6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frtgwg<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2F3F1LB8RvcSLpHAYLrEmGjgH6H2%3Fu%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Frtgwg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C4ed004c869c141bddbb608d7b94f5b3e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637181622821129830&sdata=skuitBzjlGGOCmPNI6%2BGU5q4UrYc8z2gkb77ECbAaNA%3D&reserved=0>
___________________________________________________________________________
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.
___________________________________________________________________________
_______________________________________________
rtgwg mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/rtgwg<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2F38fPqE2RREeDWfdbMWtDWR26H2%3Fu%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Frtgwg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C4ed004c869c141bddbb608d7b94f5b3e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637181622821129830&sdata=wNQ0gsD33FGnLrvvXrSjJljx1HCUoc511auQUKdKDLQ%3D&reserved=0>
___________________________________________________________________________
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.
___________________________________________________________________________
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
