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 ) 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 ) Happy to work with you folks on this. Some editorial nits in Section 3.3 "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." 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 Status: https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/ Htmlized: 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 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
