Hi Les, Thank you for the review and comments. Please see my answers inline.
Thanks, Yingzhen > On Feb 23, 2021, at 11:15 PM, Les Ginsberg (ginsberg) <[email protected]> > wrote: > > Yingzhen β > > Thanx for incorporating my suggestion to use the Application Identifiers > Registry created in RFC 6823 ( > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#app-ids-251 > > <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#app-ids-251> > ) to allow sharing of application IDs between IS-IS and OSPF. > I think, however, that we may well want to revise the format of this registry > β which is currently very IS-IS centric. Things we may want to consider > requesting from IANA: > > Specifying whether the ID can be used by OSPF, IS-IS, or both. > Moving the registry from the IS-IS TLV Codepoints registry to Interior > Gateway Protocol (IGP) Parameters > (https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml > <https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml> ) > > Happy to work with you folks on this. > > Some editorial nits in Section 3.3 [Yingzhen]: Happy to work with you on the registry. > > βIn some cases, it is desirable to limit the number of BGP-LS > [RFC5572] sessions with a controller to the a one or two routers in > > s/to the a/to > > an OSPF domain. However, many times those router(s) do not have full > visibility to the complete topology of all the areas. To solve this > problem without extended the BGP-LS domain, the OSPF LSAs for non- > > s/extended/extending > > local area could be flooded over the OSPF transport instance topology > using remote neighbors Section 4.7.1.β > [Yingzhen]: Thank you for catching these, will fix these nits in the next version. > > Les > > From: Lsr <[email protected]> On Behalf Of Yingzhen Qu > Sent: Monday, February 22, 2021 12:31 PM > To: [email protected] > Cc: Abhay Roy <[email protected]>; Acee Lindem (acee) <[email protected]>; Sina > Mirtorabi <[email protected]> > Subject: [Lsr] Fwd: New Version Notification for > draft-acee-lsr-ospf-transport-instance-02.txt > > Hi, > > We submitted a new version of this draft with detailed OSPFv2 and OSPFv3 > encodings. Please review and send your comments. > > Thanks, > Yingzhen > > > > From: [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>> > Sent: Sunday, February 21, 2021 11:21 AM > To: Abhay Roy <[email protected] <mailto:[email protected]>>; Acee Lindem > <[email protected] <mailto:[email protected]>>; Sina Mirtorabi <[email protected] > <mailto:[email protected]>>; Yingzhen Qu <[email protected] > <mailto:[email protected]>> > Subject: New Version Notification for > draft-acee-lsr-ospf-transport-instance-02.txt > > > A new version of I-D, draft-acee-lsr-ospf-transport-instance-02.txt > has been successfully submitted by Yingzhen Qu and posted to the > IETF repository. > > Name: draft-acee-lsr-ospf-transport-instance > Revision: 02 > Title: OSPF Transport Instance Extensions > Document date: 2021-02-19 > Group: Individual Submission > Pages: 14 > URL: > https://www.ietf.org/archive/id/draft-acee-lsr-ospf-transport-instance-02.txt > <https://www.ietf.org/archive/id/draft-acee-lsr-ospf-transport-instance-02.txt> > > Status: > https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/ > <https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/> > Htmlized: > https://datatracker.ietf.org/doc/html/draft-acee-lsr-ospf-transport-instance > <https://datatracker.ietf.org/doc/html/draft-acee-lsr-ospf-transport-instance> > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-acee-lsr-ospf-transport-instance-02 > <https://www.ietf.org/rfcdiff?url2=draft-acee-lsr-ospf-transport-instance-02> > > Abstract: > OSPFv2 and OSPFv3 include a reliable flooding mechanism to > disseminate routing topology and Traffic Engineering (TE) information > within a routing domain. Given the effectiveness of these > mechanisms, it is convenient to envision using the same mechanism for > dissemination of other types of information within the domain. > However, burdening OSPF with this additional information will impact > intra-domain routing convergence and possibly jeopardize the > stability of the OSPF routing domain. This document presents > mechanism to relegate this ancillary information to a separate OSPF > instance and minimize the impact. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org > <http://tools.ietf.org/>. > > The IETF Secretariat
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
