Hi Aijun, Thanks for your detailed review and please check inline below for responses.
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Aijun Wang Sent: Friday, August 19, 2022 5:55 PM To: 'Acee Lindem (acee)' <acee=40cisco....@dmarc.ietf.org>; 'lsr' <lsr@ietf.org> Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address) Hi, All: I have the following comments for this draft, and would like to support its forwarding when the below concerns are addressed. 1. For SRv6 SID’s advertisement, I suggest we should also consider it is advertised as sub-TLVs of OSPF-Stub-Link TLV, as proposed in https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-04#section-4.1. There are situations that such information can be utilized by the routers within the area, as I presented at the IETF 114 meeting (the draft is pending to be updated). Then the following sentence: “SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a specific Neighbor/Link and are therefore advertised as Sub-TLVs of E- Router-Link TLV.” Should be relaxed as: “SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a specific Neighbor/Link and are therefore advertised as Sub-TLVs of Neighbor/Link related TLVs.” Zhibo> This description does not affect the new TLVs. If a new TLV is added, you can include the sub TLV in the new TLV. 2. Support for the “SRv6 Locator TLV” to be included within the existing LSA, rather than to define the new “Locator LSA”. Zhibo> The reason for defining new LSAs is to prevent processing errors on nodes that do not support SRv6. For example, ignoring algorithm fields may cause loops. Of course, using LSinfinity metric is one way to solve this problem, but the protocol specifies the IGP does not generate the RIB/Fib for LSinfinity Metric prefix. The LSinfinity metric does not meet this scenario. In addition, IS-IS also defines a New TOP TLV. The OSPF definition is the same as that of IS-IS. Best Regards Aijun Wang China Telecom From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem (acee) Sent: Saturday, July 30, 2022 1:17 AM To: lsr <lsr@ietf.org<mailto:lsr@ietf.org>> Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org> Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address) As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The extra week is to account for PIST (Post-IETF Stress Syndrome). The corresponding IS-IS draft is already on the RFC Queue and there are implementations. https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/ Thanks, Acee & Chris
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
