Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

["Acee Lindem (acee)" <[e-mail]>]

There is also a difference between some of the existing applications advertised in IGP capabilities. For example, MSD is used with the routing information to construct SR paths. The information for all these OAM mechanisms doesn't share this affinity. Also, it seems like a slippery slope in what is needed for each of the mechanism. 
Thanks,
Acee

On 4/1/20, 4:01 AM, "Lsr on behalf of Tianran Zhou" <[e-mail] on behalf of [e-mail]> wrote:

    Hi Les,
    
    Thanks very much for your suggestion. I have a quick look at rfc6823. Sounds like a good idea. I will think about it.
    
    Cheers,
    Tianran
    
    -----Original Message-----
    From: Les Ginsberg (ginsberg) [mailto:[e-mail]] 
    Sent: Wednesday, April 1, 2020 1:47 PM
    To: Tianran Zhou <[e-mail]>; Christian Hopps <[e-mail]>
    Cc: wangyali <[e-mail]>; [e-mail]
    Subject: RE: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
    
    Tianran -
    
    I am very much in agreement with the points Chris has made.
    
    IGPs do not exist to advertise capabilities/configure applications - which seems to me to be what you are proposing here.
    The fact that you can easily define the encodings does not make it the right thing to do.
    
    This issue was discussed at length in the context of https://tools.ietf.org/html/rfc6823 . If you were proposing to use GENAPP I would not object - though I do think Chris has correctly pointed out that NETCONF/YANG is likely a more appropriate solution for your use case.
    
       Les
    
    
    > -----Original Message-----
    > From: Tianran Zhou <[e-mail]>
    > Sent: Tuesday, March 31, 2020 7:53 PM
    > To: Christian Hopps <[e-mail]>
    > Cc: wangyali <[e-mail]>; Les Ginsberg (ginsberg) 
    > <[e-mail]>; [e-mail]
    > Subject: RE: [Lsr] A new version of I-D, 
    > draft-liu-lsr-isis-ifit-node-capability-02
    > 
    > Hi Chris,
    > Thanks for your quick reply, and please see inline.
    > 
    > Cheers,
    > Tianran
    > 
    > -----Original Message-----
    > From: Christian Hopps [mailto:[e-mail]]
    > Sent: Wednesday, April 1, 2020 10:00 AM
    > To: Tianran Zhou <[e-mail]>
    > Cc: Christian Hopps <[e-mail]>; wangyali 
    > <[e-mail]>; Les Ginsberg (ginsberg) <[e-mail]>; 
    > [e-mail]
    > Subject: Re: [Lsr] A new version of I-D, 
    > draft-liu-lsr-isis-ifit-node-capability-02
    > 
    > 
    > 
    > > On Mar 31, 2020, at 9:28 PM, Tianran Zhou <[e-mail]>
    > wrote:
    > >
    > > ZTR> Let's not boil the ocean to compare NETCONF/YANG or routing
    > protocol, which is better. But I did not see the modification to 
    > routing protocol with some TLVs is a heavy work, or more complex than 
    > NETCONF/YANG.  I see both are available and useful.
    > 
    > I'm not sure what you mean by boiling the ocean. I'm saying that YANG 
    > is built and intended for querying capabilities and configuring 
    > routers. Why isn't that where you are looking first for configuring your monitoring application?
    > 
    > ZTR> I know NETCONF can do both query and configuration. And I know
    > resent YANG-Push improvements to reduce the polling.  But routing 
    > protocol solutions are also widely used for this. There are already 
    > many RFCs and implementation practices. We considered both ways, and 
    > aimed for different scenarios.
    > 
    > You don't see the major difference between writing a YANG model vs 
    > modifying all of the standard IETF routing protocols?
    > 
    > ZTR> I know many differences between NETCONF and routing protocol.
    > There are many details on both interfaces, implementations, scenarios 
    > when comparing them. That's what I mean boil the ocean.
    > Here I do not know what's the "major difference" you mean?
    > 
    > Thanks,
    > Chris.
    
    _______________________________________________
    Lsr mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/lsr