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

[Yingzhen Qu <[e-mail]>]

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) <[e-mail]> 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 <[e-mail]> On Behalf Of Yingzhen Qu
> Sent: Monday, February 22, 2021 12:31 PM
> To: [e-mail]
> Cc: Abhay Roy <[e-mail]>; Acee Lindem (acee) <[e-mail]>; Sina Mirtorabi <[e-mail]>
> 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: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Sent: Sunday, February 21, 2021 11:21 AM
> To: Abhay Roy <[e-mail] <mailto:[e-mail]>>; Acee Lindem <[e-mail] <mailto:[e-mail]>>; Sina Mirtorabi <[e-mail] <mailto:[e-mail]>>; Yingzhen Qu <[e-mail] <mailto:[e-mail]>>
> 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