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

From: wangyali <[email-masked]>
Date: Mon, 9 Mar 2020 08:20:32 +0000

Dear all,

I'm Yali. Following is a new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02 I submitted recently.

Please let me know your questions and comments. Thank you.

Name:               draft-liu-lsr-isis-ifit-node-capability

Revision:  02

Title:                  IS-IS Extensions for Advertising IFIT Node Capability

Document date:       2020-03-09

Group:               Individual Submission

Pages:               7

URL:            https://www.ietf.org/internet-drafts/draft-liu-lsr-isis-ifit-node-capability-02.txt

Status:         https://datatracker.ietf.org/doc/draft-liu-lsr-isis-ifit-node-capability/

Htmlized:       https://tools.ietf.org/html/draft-liu-lsr-isis-ifit-node-capability-02

Htmlized:       https://datatracker.ietf.org/doc/html/draft-liu-lsr-isis-ifit-node-capability

Diff:           https://www.ietf.org/rfcdiff?url2=draft-liu-lsr-isis-ifit-node-capability-02

Abstract:

   This document defines a way for an Intermediate System to

   Intermediate System (IS-IS) routers to advertise IFIT(in-situ Flow

   Information Telemetry) capabilities.  This document extends a new

   optional sub-TLV in the IS-IS Router CAPABILITY TLV [RFC7981], which

   allows a router to announce its IFIT node capabilities within an IS-

   IS level or the entire routing domain.  Such advertisements enable

   IFIT applications in the network domain.

Best Regards,
Yali WANG
E: [email-masked]<mailto:[email-masked]>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 9 Mar 2020 21:06:44 +0000

Yali -

What is missing for me is an explanation of why IFIT Capability information is something that is appropriate to be sent using IGP Router Capability advertisements.

Generally speaking, we prefer to restrict IGP advertisements to information which is of direct use to the protocol. However, it is fair to say that we have relaxed this restriction in some cases e.g.:

https://www.iana.org/go/rfc7883
https://www.iana.org/go/rfc8491

However, even in these cases the information advertised is of value to some entity executing on the protocol peers - even if not directly by the IGP itself.

I see no such value add here i.e., the IFIT capability information may well be of value to a controller but I do not see any use case for any entity on protocol peers.
So why should we use IGPs to send this information to all other IGP peers when none of them can make use of this information?

    Les

From: Lsr <[email-masked]> On Behalf Of wangyali
Sent: Monday, March 09, 2020 1:21 AM
To: [email-masked]
Subject: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Dear all,

Revision:  02

Pages:               7

Abstract:

Best Regards,
Yali WANG

---

From: wangyali <[email-masked]>
Date: Tue, 10 Mar 2020 08:57:14 +0000

Dear Les,

Thanks a lot for your comments. I will take your suggestion to add description on how to use the IFIT Capability information when the submission is opened.

As described in my reply to Acee, following is my quick reply:

IFIT is deployed in a specific domain referred as the IFIT domain. One network domain may consists of multiple IFIT domain. Within the IFIT domain, one or more IFIT-options are added into packet at the IFIT-enabled head node that is referred to as the “IFIT encapsulating node”. Then IFIT data fields MAY be updated by IFIT transit nodes that the packet traverses. Finally, the data fields are removed at a device that is referred to as the “IFIT decapsulating node”.

The IFIT data fields must not leak to other domains. So, the IFIT encapsulating node need to know if the decapsulating node is able to support the IFIT capability. So that it can decide whether to add the IFIT-option or not.

The solution is similar to RFC8491. We use IGP to advertise the capability, so that head node can use. By using BGP-LS, a centralized controller can also learn the IFIT Capability of nodes to determine whether a particular IFIT Option type can be supported in a given network.

Best regards,
Yali

发件人: Les Ginsberg (ginsberg) [mailto:[email-masked]]
发送时间: 2020年3月10日 5:07
收件人: wangyali <[email-masked]>; [email-masked]
主题: RE: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Yali –

However, even in these cases the information advertised is of value to some entity executing on the protocol peers – even if not directly by the IGP itself.

    Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of wangyali
Sent: Monday, March 09, 2020 1:21 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Dear all,

I’m Yali. Following is a new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02 I submitted recently.

Revision:  02

Pages:               7

Abstract:

Best Regards,
Yali WANG

---

From: Christian Hopps <[email-masked]>
Date: Mon, 30 Mar 2020 05:47:42 -0400

Hi Yali,

I think the overall concept of ifit is interesting enough. My concern is that we aren't adding things to routing protocols (in particular IGPs) simply to allow for another way of configuring applications in the network. This is what netconf/YANG etc, are for.

If I were trying to code this system up as a solution to sell it to customers (I'm not but..), rather than starting off by trying to modify all the IETF routing protocols to add capability advertisements (hard sell), I'd use the protocols for router discovery (already done, no standards action needed), and then netconf/restconf/whatever YANG to determine the router's capability for doing IFIT stuff, just as I would to configure those same capabilities.

Since you aren't trying to enable/disable/configure IFIT protocols with the IGP/routing protocols (this is good!), why can't you just use the same mechanism you use for enable/disable/configure for discovery as well?

Thanks,
Chris.
[as WG member]

> On Mar 10, 2020, at 4:57 AM, wangyali <[email-masked]> wrote:
> 
> Dear Les,
>  
> E: [email-masked]
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: wangyali <[email-masked]>
Date: Tue, 31 Mar 2020 10:31:11 +0000

Hi Christian,

Many thanks for your interest and question. I think netconf could also be a valid option.

However, this draft is not "configuring applications in the network". The proposed solution is an easy and efficient way to advertise and collect IFIT node capabilities. The method is same as discussed in RFC8491 to signal MSD information.

One use case is to add IFIT into SR-policy through both PCEP and BGP. So when SR-policy is deployed, IFIT functionality can be triggered automatically for the candidate path. From this point, both the path computation and IFIT option selection may take the IFIT node capability into consideration.

Best regards,
Yali

-----邮件原件-----
发件人: Christian Hopps [mailto:[email-masked]] 
发送时间: 2020年3月30日 17:48
收件人: wangyali <[email-masked]>
抄送: Christian Hopps <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
主题: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Hi Yali,

Thanks,
Chris.
[as WG member]

---

From: Christian Hopps <[email-masked]>
Date: Tue, 31 Mar 2020 06:59:59 -0400

> On Mar 31, 2020, at 6:31 AM, wangyali <[email-masked]> wrote:
> 
> Hi Christian,
> 
> However, this draft is not "configuring applications in the network".

Yes, and please note that I recognized that later in my email. However, while this particular draft is not trying to directly configure an application, it's only use is in support of that function, so in a sense it *is* about configuring an application in the network.

> The proposed solution is an easy and efficient way to advertise and collect IFIT node capabilities. The method is same as discussed in RFC8491 to signal MSD information.

MSD is directly related to forwarding packets. Monitoring the network is generally seen as a separate application. The IGPs always represent an "easy" way to advertise anything you want about a node, but that's not justification to do so.

There are other ways to query a router for it's capabilities for configuring applications that run on it, YANG is an industry standard low-bar solution, that doesn't require you change the routing protocols.

> One use case is to add IFIT into SR-policy through both PCEP and BGP. So when SR-policy is deployed, IFIT functionality can be triggered automatically for the candidate path. From this point, both…

Perhaps this isn't the right way to go about configuring IFIT, as it requires changes to all the routing protocols. There are other ways to do this that doesn't require changing or impacting all the routing protocols.

Thanks,
Chris.
[as WG member]

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 1 Apr 2020 01:28:38 +0000

Hi Chris,

Please see in line.

Thanks,
Tianran

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Tuesday, March 31, 2020 7:00 PM
To: wangyali <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
Subject: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

ZTR> I actually do not understand how "directly related to forwarding packets" relates to *suitable for IGP*, otherwise not. But IFIT is a special monitoring application. It will add telemetry instructions directly into the forwarding packets. So that device can process the packet when forwarding it. Since the instruction is attached at the ingress, the egress node need to remove it to prevent the info leak.  In this sense, I would conclude this IFIT capability is directly related to forwarding packets.

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.

ZTR> I feel it's very elegant to integrate IFIT into SR-Policy. So that the monitoring works close with the traffic engineering. There are already BGP and PECP extensions for SR-Policy (WG adopted). Very small changes are needed for IFIT extensions, e.g. 
https://datatracker.ietf.org/doc/draft-qin-idr-sr-policy-ifit/

Cheers,
Tianran

Thanks,
Chris.
[as WG member]

---

From: Christian Hopps <[email-masked]>
Date: Tue, 31 Mar 2020 21:59:34 -0400

> On Mar 31, 2020, at 9:28 PM, Tianran Zhou <[email-masked]> wrote:
> 

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?

You don't see the major difference between writing a YANG model vs modifying all of the standard IETF routing protocols?

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Tue, 31 Mar 2020 22:00:01 -0400

Sorry that was "as WG member" btw.

> On Mar 31, 2020, at 9:59 PM, Christian Hopps <[email-masked]> wrote:
> 
> 
>

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 1 Apr 2020 02:53:22 +0000

Hi Chris, 
Thanks for your quick reply, and please see inline.

Cheers,
Tianran

-----Original Message-----
From: Christian Hopps [mailto:[email-masked]] 
Sent: Wednesday, April 1, 2020 10:00 AM
To: Tianran Zhou <[email-masked]>
Cc: Christian Hopps <[email-masked]>; wangyali <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Subject: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

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.

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 1 Apr 2020 05:46:47 +0000

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

> From: Tianran Zhou <[email-masked]>
> Sent: Tuesday, March 31, 2020 7:53 PM
> To: Christian Hopps <[email-masked]>
> Cc: wangyali <[email-masked]>; Les Ginsberg (ginsberg)
> <[email-masked]>; [email-masked]
> Subject: RE: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
> 
> Hi Chris,
> Cc: Christian Hopps <[email-masked]>; wangyali
> <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>;
> [email-masked]
> > 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.