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 <lsr-boun...@ietf.org> On Behalf Of Yingzhen Qu
Sent: Monday, February 22, 2021 12:31 PM
To: lsr@ietf.org
Cc: Abhay Roy <ab...@arrcus.com>; Acee Lindem (acee) <a...@cisco.com>; Sina 
Mirtorabi <smirt...@cisco.com>
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: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>
Sent: Sunday, February 21, 2021 11:21 AM
To: Abhay Roy <ab...@arrcus.com<mailto:ab...@arrcus.com>>; Acee Lindem 
<a...@cisco.com<mailto:a...@cisco.com>>; Sina Mirtorabi 
<smirt...@cisco.com<mailto:smirt...@cisco.com>>; Yingzhen Qu 
<yingzhen...@futurewei.com<mailto:yingzhen...@futurewei.com>>
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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to