Subject: [Lsr] Fwd: New Version Notification for draft-acee-lsr-ospf-transport-instance-02.txt

From: Yingzhen Qu <[email-masked]>
Date: Mon, 22 Feb 2021 12:30:44 -0800

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-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> Sent: Sunday, February 21, 2021 11:21 AM
> To: Abhay Roy <[email-masked] <mailto:[email-masked]>>; Acee Lindem <[email-masked] <mailto:[email-masked]>>; Sina Mirtorabi <[email-masked] <mailto:[email-masked]>>; Yingzhen Qu <[email-masked] <mailto:[email-masked]>>
> 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 24 Feb 2021 07:15:40 +0000

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-masked]> On Behalf Of Yingzhen Qu
Sent: Monday, February 22, 2021 12:31 PM
To: [email-masked]
Cc: Abhay Roy <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Sina Mirtorabi <[email-masked]>
Subject: [Lsr] Fwd: New Version Notification for draft-acee-lsr-ospf-transport-instance-02.txt

Hi,

Thanks,
Yingzhen

________________________________
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, February 21, 2021 11:21 AM
To: Abhay Roy <[email-masked]<mailto:[email-masked]>>; Acee Lindem <[email-masked]<mailto:[email-masked]>>; Sina Mirtorabi <[email-masked]<mailto:[email-masked]>>; Yingzhen Qu <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-acee-lsr-ospf-transport-instance-02.txt

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:

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

---

From: Yingzhen Qu <[email-masked]>
Date: Wed, 24 Feb 2021 20:37:54 -0800

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-masked]> 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:
>  
> 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> )
>  

[Yingzhen]: Happy to work with you on the registry. 
>  
> “In some cases, it is desirable to limit the number of BGP-LS
>    using remote neighbors Section 4.7.1.”
>  
[Yingzhen]: Thank you for catching these, will fix these nits in the next version.