Hi, Zhibo: OK.
Regarding to the point #1, it is better to relax the description for more broader applications of SRv6 SID information. You can also keep it in the current status because it doesn’t not say “MUST only” be included in the mentioned TLVs. Regarding to point #2, using the newly defined LSA may be one more clean way to introduce the SRv6 Locator information within the existing OSPF network, or else, we must exploit the LSInfinity field, which may introduce more confusions when different router interprets its meaning differently. Let’s constrain the LSInfinity within its original purpose. Aijun Wang China Telecom > On Aug 19, 2022, at 18:27, Huzhibo <huzhibo=40huawei....@dmarc.ietf.org> > wrote: > > 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 <lsr-boun...@ietf.org> On Behalf Of Acee Lindem > (acee) > Sent: Saturday, July 30, 2022 1:17 AM > To: lsr <lsr@ietf.org> > Cc: 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
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
