Hi Yali, 

See [Acee]. 

On 4/28/20, 6:10 AM, "wangyali" <[email protected]> wrote:

    Hi Acee,

    Please see inline [Yali]. Thanks.

    -----Original Message-----
    From: Acee Lindem (acee) [mailto:[email protected]] 
    Sent: Monday, April 27, 2020 8:27 PM
    To: wangyali <[email protected]>; [email protected]
    Subject: Re: [Lsr] 答复: I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-01.txt

    Hi Yali, 

    On 4/26/20, 10:34 PM, "Lsr on behalf of wangyali" <[email protected] on 
behalf of [email protected]> wrote:

        Dear authors,

        It's valuable work. After reading I have a clarifying question.

        As you defined a Container unknown-tlv and Grouping unknown-sub-tlv in 
each OSPFv3 Extended LSAs defined in [RFC8362], are these used for extension of 
new OSPF Extended LSAs and new attributes in each extended LSA, respectively?

    Yes. 

    [Yali]: Could you give an example to illustrate how to use this model? And 
please add some words to introduce how to use these unkown-tlv and 
unknown-sub-tlv Container/Grouping?

[Acee] As the name implies, you'd use them for TLVs and Sub-TLVs that are not 
supported. 

        For example, if other attributes associated with Link are extended to 
E-Router-LSA TLV for access via NETCONF, does it can be directly augmented leaf 
of the List sub-tlvs in this YANG module? 

        If not, does it need to define a new YANG module used for other Link 
attributes can be accessed via NETCONF?

    Yes. There are many features that utilize the OSPFv3 extended LSA format 
and these will correspond to new models. For example, OSPFv3 segment routing. 

    [Yali]: For example, in RFC8666, the Prefix-SID sub-TLV is a sub-TLV of the 
Intra-Area Prefix TLV. And in draft [ospfv3-extended-lsa-yang-01], you also 
defined grouping intra-area-prefix-tlv which includes a list sub-tlvs. May 
question is that could we directly use the ospfv3-extended-lsa-yang model and 
augment a Prefix-SID sub-TLV leaf in the list sub-tlv and do not need to define 
a new model? If not, why?

[Acee] You'd use them if you supported the augmenting OSPFv3 YANG model. 
However, in that case, then they'd no longer be "unknown". OSPFv3 features 
adding new TLVs and Sub-TLVs will not automatically be supported by all routers 
OSPFv3 routers in the domain. In fact, due to timing there may be features that 
don't even have corresponding OSPFv3 Extended-LSA YANG model augmentations when 
the corresponding Extended-LSAs are advertised. 

    [Yali]: Besides, considering NETCONF and BGP-LS are two parallel solutions 
for exportation, we suggest separate this draft 
[draft-wang-lsr-ifit-node-capability-advertisement-00]. One draft specifies IGP 
Extension for IFIT capability advertisement and others specify IFIT capability 
exportation via NETCONF and BGP-LS, respectively. Do you agree that?

[Acee] I agree that the NETCONF and YANG model should be separate. I didn't 
agree that it is needed in the IGPs. 

Thanks,
Acee

    Thanks,
    Acee

        Best regards,
        Yali

        -----邮件原件-----
        发件人: [email protected] [mailto:[email protected]] 
        发送时间: 2020年4月25日 3:36
        收件人: [email protected]
        抄送: [email protected]
        主题: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-01.txt


        A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
        This draft is a work item of the Link State Routing WG of the IETF.

                Title           : YANG Model for OSPFv3 Extended LSAs
                Authors         : Acee Lindem
                                  Sharmila Palani
                                  Yingzhen Qu
                Filename        : draft-ietf-lsr-ospfv3-extended-lsa-yang-01.txt
                Pages           : 30
                Date            : 2020-04-24

        Abstract:
           This document defines a YANG data model augmenting the IETF OSPF YANG
           model to provide support for OSPFv3 Link State Advertisment (LSA)
           Extensibility as defined in RFC 8362.  OSPFv3 Extended LSAs provide
           extensible TLV-based LSAs for the base LSA types defined in RFC 5340.


        The IETF datatracker status page for this draft is:
        
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/

        There are also htmlized versions available at:
        https://tools.ietf.org/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-01
        
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-01

        A diff from the previous version is available at:
        
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-01


        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.

        Internet-Drafts are also available by anonymous FTP at:
        ftp://ftp.ietf.org/internet-drafts/



        _______________________________________________
        Lsr mailing list
        [email protected]
        https://www.ietf.org/mailman/listinfo/lsr


_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to