Subject: Comments on draft-ietf-rtgwg-srv6-egress-protection

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 27 Jul 2020 15:18:23 +0000

Hello,

I am summarizing the questions/comments on the mike on the list with more details for a follow-up from the authors.

1) SRv6 Mirror SID is a new behavior for SRv6 SIDs that needs to be formally introduced, defined (using a pseudocode?) and a IANA code-point allocated for it. E.g. refer https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-16#section-4.6 and for codepoint check https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-16#section-9.2. My question was whether the authors intended to add that in this document or a separate Spring document (may be the chairs can guide here)? Regardless, this would be something that would require review from the Spring WG.

2) Once (1) has been addressed, then it provides the necessary foundation for the review of the IGP encodings for signaling of SRv6 Mirror SIDs (Section 4). I would suggest that this proposal then get reviewed in the LSR WG - whether in this document or as a separate LSR draft is up to the chairs.

Thanks,
Ketan

---

From: Chris Bowers <[email-masked]>
Date: Tue, 28 Jul 2020 14:42:32 -0500

I would also suggest that the authors of
draft-ietf-rtgwg-srv6-egress-protection add a reference to Section 5.1 of
RFC8402 (Segment Routing Architecture) which describes the Mirror SID.

Thanks,
Chris

On Mon, Jul 27, 2020 at 10:18 AM Ketan Talaulikar (ketant) <ketant=
[email-masked]> wrote:

> Hello,
>
> I am summarizing the questions/comments on the mike on the list with more
> details for a follow-up from the authors.
>
> 1) SRv6 Mirror SID is a new behavior for SRv6 SIDs that needs to be
> formally introduced, defined (using a pseudocode?) and a IANA code-point
> allocated for it. E.g. refer
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-16#section-4.6
> and for codepoint check
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-16#section-9.2.
> My question was whether the authors intended to add that in this document
> or a separate Spring document (may be the chairs can guide here)?
> Regardless, this would be something that would require review from the
> Spring WG.
>
> 2) Once (1) has been addressed, then it provides the necessary foundation
> for the review of the IGP encodings for signaling of SRv6 Mirror SIDs
> (Section 4). I would suggest that this proposal then get reviewed in the
> LSR WG - whether in this document or as a separate LSR draft is up to the
> chairs.
>
> Thanks,
> Ketan
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 28 Jul 2020 22:02:14 +0000

Hi Chris,

    Thank you very much for your suggestion.
    We will add the reference accordingly.

Best Regards,
Huaimo
________________________________
From: Chris Bowers <[email-masked]>
Sent: Tuesday, July 28, 2020 3:42 PM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; Ketan Talaulikar (ketant) <ketant=[email-masked]>
Subject: Re: Comments on draft-ietf-rtgwg-srv6-egress-protection

I would also suggest that the authors of draft-ietf-rtgwg-srv6-egress-protection add a reference to Section 5.1 of RFC8402 (Segment Routing Architecture) which describes the Mirror SID.

Thanks,
Chris

On Mon, Jul 27, 2020 at 10:18 AM Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:[email-masked]>> wrote:
Hello,

1) SRv6 Mirror SID is a new behavior for SRv6 SIDs that needs to be formally introduced, defined (using a pseudocode?) and a IANA code-point allocated for it. E.g. refer https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-16#section-4.6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-srv6-network-programming-16%23section-4.6&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C9fe1997188ce49d2dbc208d8332ebfc5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637315623167169013&sdata=EIuE1TCcJ4vfxuEI44V8BGJQ54qIKLUYcfE3Urm2Epk%3D&reserved=0> and for codepoint check https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-16#section-9.2<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-srv6-network-programming-16%23section-9.2&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C9fe1997188ce49d2dbc208d8332ebfc5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637315623167179016&sdata=TdiaIKsK%2FNJ3vZKT9v%2B53u%2FOEhkho67o4A%2FdCKj2bGQ%3D&reserved=0>. My question was whether the authors intended to add that in this document or a separate Spring document (may be the chairs can guide here)? Regardless, this would be something that would require review from the Spring WG.

Thanks,
Ketan

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frtgwg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C9fe1997188ce49d2dbc208d8332ebfc5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637315623167179016&sdata=Rqc%2F%2BgsjPCY1og8UcRA2VyFhk2yZO3Cg3SVeouex96s%3D&reserved=0>

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 28 Jul 2020 22:11:57 +0000

Hi Ketan,

    Thank you very much for your comments and suggestions.
    We will talk to the Spring and LSR chairs regarding to whether a separated Spring and LSR document are needed.

Best Regards,
Huaimo
________________________________
From: Ketan Talaulikar (ketant) <[email-masked]>
Sent: Monday, July 27, 2020 11:18 AM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Comments on draft-ietf-rtgwg-srv6-egress-protection

Hello,

1) SRv6 Mirror SID is a new behavior for SRv6 SIDs that needs to be formally introduced, defined (using a pseudocode?) and a IANA code-point allocated for it. E.g. refer https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-srv6-network-programming-16%23section-4.6&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C860d71998f1c4f225e6f08d8324052b1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637314599147129566&amp;sdata=7pbnGRxtThFnfdXHym%2FXcnydr8rppSN7Kf3zQrYLVO4%3D&amp;reserved=0 and for codepoint check https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-srv6-network-programming-16%23section-9.2&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C860d71998f1c4f225e6f08d8324052b1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637314599147129566&amp;sdata=ZoeH5vkHkGNxXzzd01%2FRt0DDN%2FvEA3dTqjwwEgsFuhU%3D&amp;reserved=0. My question was whether the authors intended to add that in this document or a separate Spring document (may be the chairs can guide here)? Regardless, this would be something that would require review from the Spring WG.

Thanks,
Ketan