[Lsr] Re: RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06

[Tianran Zhou]

What do you mean?






Sent from WeLink
发件人： 
je_dr...@yahoo.commailto:je_drake=40yahoo@dmarc.ietf.org>>
收件人： Aijun Wangmailto:wangai...@tsinghua.org.cn>>
抄送： Robert Raszukmailto:rob...@raszuk.net>>;Les Ginsberg 
(ginsberg)mailto:ginsb...@cisco.com>>;Acee 
Lindemmailto:acee.i...@gmail.com>>;Christian 
Hoppsmailto:cho...@chopps.org>>;Mach 
Chenmailto:mach.chen=40huawei@dmarc.ietf.org>>;Routing
 
ADsmailto:rtg-...@ietf.org>>;rtg-...@ietf.org;draft-ietf-lsr-multi-tlv@ietf.org;lsrmailto:lsr@ietf.org>>;last-callmailto:last-c...@ietf.org>>
主题： [Lsr] Re: RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06
时间： 2024-11-12 08:06:09

Yawn

Sent from my iPhone

On Nov 11, 2024, at 6:48 PM, Aijun Wang  wrote:

Hi, Robert and Mach:

Thanks for your comments on this document.
It reveals clearly the issues existing within the documents.

The Chairs declare repeatedly this document reached WG consensus, apparently it 
DOESN’T.

I have submitted the appeal to IESG.
Wish more experts to stand out to ABANDON this error prone, pitfall solution 
being published under the name of LSR, or IETF.

Aijun Wang
China Telecom

On Nov 12, 2024, at 06:55, Robert Raszuk  wrote:


Les,

>  Link identifiers are indeed sub-TLVs.
>  That does not disqualify them from being part of “key” information.

Oh, it was not clear from the draft. Perhaps you can add this detail in the 
next rev.

- - -

If you have multiple parallel links today they will all be listed in the 
sub-TLVs - so they are ok spec wise today.

I am not sure however - assuming you do not include "Example" in section 4.1 
that everyone would be adding them to each TLV fragment.

// But then we have hackathons and interop venus where interop bugs can be 
quickly found and fixed
// if this is how it should all work out.

That is why I do believe a sort of dictionary would be nice to have in either a 
normative spec or reference to such a document or even as a simple wiki page :).

Best,
Robert


On Mon, Nov 11, 2024 at 11:39 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Robert –

Link identifiers are indeed sub-TLVs.
That does not disqualify them from being part of “key” information.

If I have multiple parallel links between two routers, this is how the links 
are uniquely identified. Such information is essential to correctly identify 
the link attribute information which in turn is essential for applications such 
as RSVP-TE, SR=TE, and flex-algo to operate correctly.

If you think this is underspecified, I presume you think it is not possible for 
these applications to work correctly today – which obviously is not the case.

Les

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Monday, November 11, 2024 2:16 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Acee Lindem mailto:acee.i...@gmail.com>>; Christian 
Hopps mailto:cho...@chopps.org>>; Mach Chen 
mailto:40huawei@dmarc.ietf.org>>; 
Routing ADs mailto:rtg-...@ietf.org>>; 
rtg-...@ietf.org; 
draft-ietf-lsr-multi-tlv@ietf.org;
 lsr mailto:lsr@ietf.org>>; last-call 
mailto:last-c...@ietf.org>>
Subject: Re: [Lsr] RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06

Les,

I note that in all of these emails expressing concern no one has provided a 
single example

RFC5305 defines Extended IS Reachability TLV as:

   The proposed extended IS reachability TLV contains a new data
   structure, consisting of:

  7 octets of system ID and pseudonode number
  3 octets of default metric
  1 octet of length of sub-TLVs

Now your draft makes an impression that there are also at the TLV level itself 
optional link identifiers.

4.1.  Example: Extended IS Reachability

   As an example, consider the Extended IS Reachability TLV (type 22).
   A neighbor in this TLV is specified by:

   *  7 octets of system ID and pseudonode number

   *  3 octets of default metric

   *  Optionally one or more of the following link identifiers:

  -  IPv4 interface address and IPv4 neighbor address as specified
 in [RFC5305]

  -  IPv6 interface address and IPv6 neighbor address as specified
 in [RFC6119]

  -  Link Local/Remote Identifiers as specified in [RFC5307]


Can you point to the text in RFC5305 where such IPv4 link identifier is defined 
?

I can only find them to be defined as part of sub-TLVs.

Also I do not see them as LSDB keys in FRR ISIS code ...
Ref: https://github.com/FRRouting/frr/blob/master/isisd/isisd.c

Thx,
R.

From: Acee Lindem mailto:acee.i...@gmail.com>>
Sent: Monday, November 11, 2024 1:42 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; Mach Chen 
mailto:40huawei@dmarc.ietf.org>>; 
Routing ADs mailto:rtg-...@ietf.org>>; 
rtg-...@ietf.org; 
draft-ietf-lsr-multi-tlv@ietf.org

Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

[Tianran Zhou]

Hi Jeff,

Thanks very much for your review and detailed comments.
All are reasonable to me.
We will work through the document and address your comments.

Thanks,
Tianran

From: Jeffrey Haas [mailto:jh...@pfrc.org]
Sent: Wednesday, July 13, 2022 4:37 AM
To: Tianran Zhou 
Cc: Robert Raszuk ; Yingzhen Qu ; 
idr ; grow ; lsr 
Subject: Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

Tianran,

On Jul 11, 2022, at 10:42 PM, Tianran Zhou 
mailto:zhoutianran=40huawei@dmarc.ietf.org>>
 wrote:

Hi Jeff,

Our work is not to propose a new protocol.
https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01
Our idea is to use BMP for IGP monitoring. We just choose BMP as the vehicle.

Thanks for the pointer to this document.  I had not previously read it.

The use case portion of the document is clear and well-written.

I don't pretend to be an expert in any of the IGPs, but here are a few 
observations from my read-through of the document:

- Should the per-adjacency header include something like ifIndex as part of its 
information?  This might help with troubleshooting misconfigured interfaces.
- In places where fields are Reserved, please use text in the form of "MUST be 
set to zero on transmission and SHOULD be ignored on reception".
- Your reason type and statistics type fields should get IANA sections and IANA 
allocation policy for allocating future code points.
- Your statistics TLV could probably be patterned more like that of the main 
BMP RFC.  That would permit more than one statistic to be attached at a time.
   + Statistic Value says that it is always 4 bytes of length.  If it's a fixed 
length, you may not require a length.  But I think you'll want this to be 
variably sized.  Some fields should be a 64-bit gauge; see BMP RFC for examples.
- The document should procedurally describe what happens when a session is 
first established.  For BGP BMP, the full RIB set is exchanged.  For this 
proposal, very likely the intent is that the LSDB is transmitted.  Given the 
incremental nature of IS-IS messages, it may be necessary to describe similar 
"end of rib" procedures that are in the BGP BMP specification in the context of 
your draft.  Afterwards, propagating the raw IS-IS PDUs in your messages will 
likely make sense.

-- Jeff

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

[Tianran Zhou]

Hi Jeff,

Our work is not to propose a new protocol.
https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01
Our idea is to use BMP for IGP monitoring. We just choose BMP as the vehicle.

Best,
Tianran

From: Jeffrey Haas [mailto:jh...@pfrc.org]
Sent: Tuesday, July 12, 2022 12:10 AM
To: Tianran Zhou 
Cc: Robert Raszuk ; Yingzhen Qu ; 
idr ; grow ; lsr 
Subject: Re: [Idr] [GROW] [Lsr] IGP Monitoring Protocol

Tianran,

Please note that nothing prohibits BGP-LS from being distributed over BMP today 
aside from implementation support.  It's just another AFI/SAFI.

-- Jeff



On Jul 11, 2022, at 10:02 AM, Tianran Zhou 
mailto:zhoutianran=40huawei@dmarc.ietf.org>>
 wrote:

Hi Robert,

I see this name very similar to BMP bgp monitoring protocol.
Is this the similar function and scope as BMP?


Best,
Tianran


Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Yingzhen Qumailto:yingzhen.i...@gmail.com>>
抄送： 
idrmailto:i...@ietf.org>>;growmailto:g...@ietf.org>>;lsrmailto:lsr@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 18:01:47

Hi Yingzhen,

Yes I understand that OSPF-GT is a new protocol leveraging some OSPF elements.

And please do not get me wrong ... way before OSPF Transport Instance I wrote 
BGP Transport Instance proposal and I do consider such additions to protocols 
as a very useful thing. In fact honestly recent discussions on UPA/PUA/PULSE 
could be very well served by OSPF-GT in a stateful fashion.

But I just do not see this fits well as a replacement of BGP-LS.

Yes, protocol designers like a swiss army knife approach (not to use nail and 
hammer analogy). However I think custom tools in the toolkit work much better 
for specific tasks :)

Cheers,
R.



On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:
Hi Robert,

Please think of OSPF-GT as a new protocol and it borrows ideas from OSPF. 
BGP-LS is one use case. In LSR WG, there have been proposals asking IGPs to 
carry non-routing information which will have impacts on protocol convergence, 
and OSPF-GT is meant to be the vehicle for such information.

BMP started before YANG, now with NETCONF/YANG or gNMI, you can retrieve the 
entire LSDB or part of it from a router, or subscribe to some data instances.

Thanks,
Yingzhen


On Jul 10, 2022, at 3:44 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi Acee,

My questions were based on section 3.4 of the latest version of the draft.

So I do not think I misinterpreted it.

Thank you,
R.



On Mon, Jul 11, 2022 at 12:38 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Robert Raszuk mailto:rob...@raszuk.net>>
Date: Sunday, July 10, 2022 at 1:32 PM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>, Susan 
Hares mailto:sha...@ndzh.com>>, IDR List 
mailto:i...@ietf.org>>, "g...@ietf.org<mailto:g...@ietf.org> 
g...@ietf.org<mailto:g...@ietf.org>" mailto:g...@ietf.org>>, lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

Hi Yingzhen & OSPF-GT authors,

UP front I must state that anything is better to export IGP information from 
routers to interested nodes than using BGP for it.

But to propose using OSPF to transport ISIS seems pretty brave :) I must admit 
it !

With that I have few questions to the proposal - assuming the use case is to 
distribute links state info in a point to point fashion:

A.What is the advantage - if any - to use a new OSPF instance/process to 
send link state data over a unicast session to a controller ?

It doesn’t have to be unicast, the remote neighbor construct just extends the 
possibilities in OSPF-GT. With an OSPF LSDB, the obvious advantage is all the 
protocol machinery is in place.  Note that LSDB streaming is just but one use 
case and of OSPF-GT. The detals of this application would be specified in a 
separate draft.


B. The draft is pretty silent on the nature of such a p2p session. Please 
be explicit if this is TCP, QUIC or what ?

It is OSPF, OSPF has its own protocol identifier (89). This draft just extends 
OSPF. I think you’ve misinterpreted the draft. Hence, your other questions 
aren’t really applicable or would be answered in a draft of the OSPF/IS-IS LSDB 
usage of OSPF-GT.

Thanks,
Acee



C) The draft is pretty silent on types of authentication for such sessions. 
Security considerations are pretty weak in that respect as well.

   The security considerations for OSPF-GT will be similar to those for
   OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
   used to update OSPF routing, the consequences of attacks will be
   dependent on advertised non-routing information.

I would actually argue that securit

Re: [Lsr] [GROW] [Idr] IGP Monitoring Protocol

[Tianran Zhou]

Hi Robert,

Thanks for sharing your point.
We are actually very open on a new protocol also. We just want to solve real 
problems.
We organized a side meeting in IETF to discuss this. The feedback from that 
meeting is a preference on reusing BMP.  😀

Best,
Tianran






Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Tianran Zhoumailto:zhoutian...@huawei.com>>
抄送： Yingzhen 
Qumailto:yingzhen.i...@gmail.com>>;idrmailto:i...@ietf.org>>;growmailto:g...@ietf.org>>;lsrmailto:lsr@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 23:38:49

Hi,

I think BMP is busy enough that loading more on it will be problematic.

Sourcing from two protocols just to leverage single transport session seems not 
best idea.

IMO opening a new unicast session directly by the producer of subject data is 
best way to share/export it.

Many thx,
R.

On Mon, Jul 11, 2022 at 5:34 PM Tianran Zhou 
mailto:zhoutian...@huawei.com>> wrote:
Hi Robert,

Since our work is just follow the BMP which is in GROW in OPS area, we 
presented this in OPSAWG and GROW.

We want to reuse BMP for IGP with some simple extensions. We do not want to 
create a new protocol only because of the BMP name.

Cheers,
Tianran






Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Tianran Zhoumailto:zhoutian...@huawei.com>>
抄送： Yingzhen 
Qumailto:yingzhen.i...@gmail.com>>;idrmailto:i...@ietf.org>>;growmailto:g...@ietf.org>>;lsrmailto:lsr@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 23:05:56

Hello Tianran,

Oh I was not aware of such document. Did you ever share it with LSR WG before ?

Quick browsing reveals that you have taken a bit different approach .. very IGP 
centric borrowing IGP encoding at the message level.

For example peer state notification I purposely decided not to include as this 
is already reflected in the LSDB.

I will take a more detail read of your spec. Then we can talk if there is some 
overlap or both approaches are so different then it makes sense to progress 
both. One size does not fit all :)

Best,
R.




On Mon, Jul 11, 2022 at 4:54 PM Tianran Zhou 
mailto:zhoutian...@huawei.com>> wrote:
Hi Robert,

This is very interesting to me. We had a protocol design for IGP monitoring:

https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01

It would be a good idea if we can find some common ground.

Cheers,
Tianran






Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Tianran Zhoumailto:zhoutian...@huawei.com>>
抄送： Yingzhen 
Qumailto:yingzhen.i...@gmail.com>>;idrmailto:i...@ietf.org>>;growmailto:g...@ietf.org>>;lsrmailto:lsr@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 22:05:31

Hi Tianran,

Yes it is,

I dedicated entire paragraph in section 1 of the document to highlight that 
point:


   The primary inspiration for this work has been based on the success
   of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
   aspects shares the same high level requirements - point to point
   routing information distribution, protocol observability and enhanced
   operations.  It also needs to be highlighted that BMP (while it
   technically could) does not use native BGP sessions to propagate such
   information, but is running a separate transport.  IMP authors have
   chosen to reuse selected BMP building blocks and BMP operational and
   deployment experience.



Many thx,
R.

On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou 
mailto:zhoutian...@huawei.com>> wrote:
Hi Robert,

I see this name very similar to BMP bgp monitoring protocol.
Is this the similar function and scope as BMP?


Best,
Tianran



Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Yingzhen Qumailto:yingzhen.i...@gmail.com>>
抄送： 
idrmailto:i...@ietf.org>>;growmailto:g...@ietf.org>>;lsrmailto:lsr@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 18:01:47

Hi Yingzhen,

Yes I understand that OSPF-GT is a new protocol leveraging some OSPF elements.

And please do not get me wrong ... way before OSPF Transport Instance I wrote 
BGP Transport Instance proposal and I do consider such additions to protocols 
as a very useful thing. In fact honestly recent discussions on UPA/PUA/PULSE 
could be very well served by OSPF-GT in a stateful fashion.

But I just do not see this fits well as a replacement of BGP-LS.

Yes, protocol designers like a swiss army knife approach (not to use nail and 
hammer analogy). However I think custom tools in the toolkit work much better 
for specific tasks :)

Cheers,
R.



On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:

Re: [Lsr] [GROW] [Idr] IGP Monitoring Protocol

[Tianran Zhou]

Hi Robert,

Since our work is just follow the BMP which is in GROW in OPS area, we 
presented this in OPSAWG and GROW.

We want to reuse BMP for IGP with some simple extensions. We do not want to 
create a new protocol only because of the BMP name.

Cheers,
Tianran






Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Tianran Zhoumailto:zhoutian...@huawei.com>>
抄送： Yingzhen 
Qumailto:yingzhen.i...@gmail.com>>;idrmailto:i...@ietf.org>>;growmailto:g...@ietf.org>>;lsrmailto:lsr@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 23:05:56

Hello Tianran,

Oh I was not aware of such document. Did you ever share it with LSR WG before ?

Quick browsing reveals that you have taken a bit different approach .. very IGP 
centric borrowing IGP encoding at the message level.

For example peer state notification I purposely decided not to include as this 
is already reflected in the LSDB.

I will take a more detail read of your spec. Then we can talk if there is some 
overlap or both approaches are so different then it makes sense to progress 
both. One size does not fit all :)

Best,
R.




On Mon, Jul 11, 2022 at 4:54 PM Tianran Zhou 
mailto:zhoutian...@huawei.com>> wrote:
Hi Robert,

This is very interesting to me. We had a protocol design for IGP monitoring:

https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01

It would be a good idea if we can find some common ground.

Cheers,
Tianran






Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Tianran Zhoumailto:zhoutian...@huawei.com>>
抄送： Yingzhen 
Qumailto:yingzhen.i...@gmail.com>>;idrmailto:i...@ietf.org>>;growmailto:g...@ietf.org>>;lsrmailto:lsr@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 22:05:31

Hi Tianran,

Yes it is,

I dedicated entire paragraph in section 1 of the document to highlight that 
point:


   The primary inspiration for this work has been based on the success
   of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
   aspects shares the same high level requirements - point to point
   routing information distribution, protocol observability and enhanced
   operations.  It also needs to be highlighted that BMP (while it
   technically could) does not use native BGP sessions to propagate such
   information, but is running a separate transport.  IMP authors have
   chosen to reuse selected BMP building blocks and BMP operational and
   deployment experience.



Many thx,
R.

On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou 
mailto:zhoutian...@huawei.com>> wrote:
Hi Robert,

I see this name very similar to BMP bgp monitoring protocol.
Is this the similar function and scope as BMP?


Best,
Tianran



Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Yingzhen Qumailto:yingzhen.i...@gmail.com>>
抄送： 
idrmailto:i...@ietf.org>>;growmailto:g...@ietf.org>>;lsrmailto:lsr@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 18:01:47

Hi Yingzhen,

Yes I understand that OSPF-GT is a new protocol leveraging some OSPF elements.

And please do not get me wrong ... way before OSPF Transport Instance I wrote 
BGP Transport Instance proposal and I do consider such additions to protocols 
as a very useful thing. In fact honestly recent discussions on UPA/PUA/PULSE 
could be very well served by OSPF-GT in a stateful fashion.

But I just do not see this fits well as a replacement of BGP-LS.

Yes, protocol designers like a swiss army knife approach (not to use nail and 
hammer analogy). However I think custom tools in the toolkit work much better 
for specific tasks :)

Cheers,
R.



On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:
Hi Robert,

Please think of OSPF-GT as a new protocol and it borrows ideas from OSPF. 
BGP-LS is one use case. In LSR WG, there have been proposals asking IGPs to 
carry non-routing information which will have impacts on protocol convergence, 
and OSPF-GT is meant to be the vehicle for such information.

BMP started before YANG, now with NETCONF/YANG or gNMI, you can retrieve the 
entire LSDB or part of it from a router, or subscribe to some data instances.

Thanks,
Yingzhen

On Jul 10, 2022, at 3:44 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi Acee,

My questions were based on section 3.4 of the latest version of the draft.

So I do not think I misinterpreted it.

Thank you,
R.



On Mon, Jul 11, 2022 at 12:38 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Robert Raszuk mailto:rob...@raszuk.net>>
Date: Sunday, July 10, 2022 at 1:32 PM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
Cc: Gyan Mishra mailto:hayabusa

Re: [Lsr] [GROW] [Idr] IGP Monitoring Protocol

[Tianran Zhou]

Hi Robert,

This is very interesting to me. We had a protocol design for IGP monitoring:

https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01

It would be a good idea if we can find some common ground.

Cheers,
Tianran






Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Tianran Zhoumailto:zhoutian...@huawei.com>>
抄送： Yingzhen 
Qumailto:yingzhen.i...@gmail.com>>;idrmailto:i...@ietf.org>>;growmailto:g...@ietf.org>>;lsrmailto:lsr@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 22:05:31

Hi Tianran,

Yes it is,

I dedicated entire paragraph in section 1 of the document to highlight that 
point:


   The primary inspiration for this work has been based on the success
   of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
   aspects shares the same high level requirements - point to point
   routing information distribution, protocol observability and enhanced
   operations.  It also needs to be highlighted that BMP (while it
   technically could) does not use native BGP sessions to propagate such
   information, but is running a separate transport.  IMP authors have
   chosen to reuse selected BMP building blocks and BMP operational and
   deployment experience.



Many thx,
R.

On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou 
mailto:zhoutian...@huawei.com>> wrote:
Hi Robert,

I see this name very similar to BMP bgp monitoring protocol.
Is this the similar function and scope as BMP?


Best,
Tianran



Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Yingzhen Qumailto:yingzhen.i...@gmail.com>>
抄送： 
idrmailto:i...@ietf.org>>;growmailto:g...@ietf.org>>;lsrmailto:lsr@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 18:01:47

Hi Yingzhen,

Yes I understand that OSPF-GT is a new protocol leveraging some OSPF elements.

And please do not get me wrong ... way before OSPF Transport Instance I wrote 
BGP Transport Instance proposal and I do consider such additions to protocols 
as a very useful thing. In fact honestly recent discussions on UPA/PUA/PULSE 
could be very well served by OSPF-GT in a stateful fashion.

But I just do not see this fits well as a replacement of BGP-LS.

Yes, protocol designers like a swiss army knife approach (not to use nail and 
hammer analogy). However I think custom tools in the toolkit work much better 
for specific tasks :)

Cheers,
R.



On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:
Hi Robert,

Please think of OSPF-GT as a new protocol and it borrows ideas from OSPF. 
BGP-LS is one use case. In LSR WG, there have been proposals asking IGPs to 
carry non-routing information which will have impacts on protocol convergence, 
and OSPF-GT is meant to be the vehicle for such information.

BMP started before YANG, now with NETCONF/YANG or gNMI, you can retrieve the 
entire LSDB or part of it from a router, or subscribe to some data instances.

Thanks,
Yingzhen

On Jul 10, 2022, at 3:44 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi Acee,

My questions were based on section 3.4 of the latest version of the draft.

So I do not think I misinterpreted it.

Thank you,
R.



On Mon, Jul 11, 2022 at 12:38 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Robert Raszuk mailto:rob...@raszuk.net>>
Date: Sunday, July 10, 2022 at 1:32 PM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>, Susan 
Hares mailto:sha...@ndzh.com>>, IDR List 
mailto:i...@ietf.org>>, "g...@ietf.org<mailto:g...@ietf.org> 
g...@ietf.org<mailto:g...@ietf.org>" mailto:g...@ietf.org>>, lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

Hi Yingzhen & OSPF-GT authors,

UP front I must state that anything is better to export IGP information from 
routers to interested nodes than using BGP for it.

But to propose using OSPF to transport ISIS seems pretty brave :) I must admit 
it !

With that I have few questions to the proposal - assuming the use case is to 
distribute links state info in a point to point fashion:


  1.  What is the advantage - if any - to use a new OSPF instance/process to 
send link state data over a unicast session to a controller ?

It doesn’t have to be unicast, the remote neighbor construct just extends the 
possibilities in OSPF-GT. With an OSPF LSDB, the obvious advantage is all the 
protocol machinery is in place.  Note that LSDB streaming is just but one use 
case and of OSPF-GT. The detals of this application would be specified in a 
separate draft.



  1.  The draft is pretty silent on the nature of such a p2p session. Please be 
explicit if this is T

Re: [Lsr] [GROW] [Idr] IGP Monitoring Protocol

[Tianran Zhou]

Hi Robert,

I see this name very similar to BMP bgp monitoring protocol.
Is this the similar function and scope as BMP?


Best,
Tianran



Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Yingzhen Qumailto:yingzhen.i...@gmail.com>>
抄送： 
idrmailto:i...@ietf.org>>;growmailto:g...@ietf.org>>;lsrmailto:lsr@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 18:01:47

Hi Yingzhen,

Yes I understand that OSPF-GT is a new protocol leveraging some OSPF elements.

And please do not get me wrong ... way before OSPF Transport Instance I wrote 
BGP Transport Instance proposal and I do consider such additions to protocols 
as a very useful thing. In fact honestly recent discussions on UPA/PUA/PULSE 
could be very well served by OSPF-GT in a stateful fashion.

But I just do not see this fits well as a replacement of BGP-LS.

Yes, protocol designers like a swiss army knife approach (not to use nail and 
hammer analogy). However I think custom tools in the toolkit work much better 
for specific tasks :)

Cheers,
R.



On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:
Hi Robert,

Please think of OSPF-GT as a new protocol and it borrows ideas from OSPF. 
BGP-LS is one use case. In LSR WG, there have been proposals asking IGPs to 
carry non-routing information which will have impacts on protocol convergence, 
and OSPF-GT is meant to be the vehicle for such information.

BMP started before YANG, now with NETCONF/YANG or gNMI, you can retrieve the 
entire LSDB or part of it from a router, or subscribe to some data instances.

Thanks,
Yingzhen

On Jul 10, 2022, at 3:44 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi Acee,

My questions were based on section 3.4 of the latest version of the draft.

So I do not think I misinterpreted it.

Thank you,
R.



On Mon, Jul 11, 2022 at 12:38 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Robert Raszuk mailto:rob...@raszuk.net>>
Date: Sunday, July 10, 2022 at 1:32 PM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>, Susan 
Hares mailto:sha...@ndzh.com>>, IDR List 
mailto:i...@ietf.org>>, "g...@ietf.org 
g...@ietf.org" mailto:g...@ietf.org>>, lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

Hi Yingzhen & OSPF-GT authors,

UP front I must state that anything is better to export IGP information from 
routers to interested nodes than using BGP for it.

But to propose using OSPF to transport ISIS seems pretty brave :) I must admit 
it !

With that I have few questions to the proposal - assuming the use case is to 
distribute links state info in a point to point fashion:


  1.  What is the advantage - if any - to use a new OSPF instance/process to 
send link state data over a unicast session to a controller ?

It doesn’t have to be unicast, the remote neighbor construct just extends the 
possibilities in OSPF-GT. With an OSPF LSDB, the obvious advantage is all the 
protocol machinery is in place.  Note that LSDB streaming is just but one use 
case and of OSPF-GT. The detals of this application would be specified in a 
separate draft.



  1.  The draft is pretty silent on the nature of such a p2p session. Please be 
explicit if this is TCP, QUIC or what ?

It is OSPF, OSPF has its own protocol identifier (89). This draft just extends 
OSPF. I think you’ve misinterpreted the draft. Hence, your other questions 
aren’t really applicable or would be answered in a draft of the OSPF/IS-IS LSDB 
usage of OSPF-GT.

Thanks,
Acee



C) The draft is pretty silent on types of authentication for such sessions. 
Security considerations are pretty weak in that respect as well.

   The security considerations for OSPF-GT will be similar to those for
   OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
   used to update OSPF routing, the consequences of attacks will be
   dependent on advertised non-routing information.

I would actually argue that security considerations of p2p remote neighbors are 
actually quite different from security considerations of flooding data.

Along the same lines security is not about protecting your routing ... it is 
much more about protecting the entire network by exposing critical information 
externally to non authorized parties.

D) Are there any PUB-SUB options possible for OSPF-GT ?

E) Is there any filtering possible for OSPF-GT ?

F) Are you envisioning use of OSPF-GT proxies and if so are you planning to add 
this to the document ?

G) How are you going to address Receivers which do not support OSPF-GT parser ?

H) As you know many operators are attracted to BGP-LS based on the fact that it 
offers the same view of information irrespective of what is the protocol 
producing the data. Is there some thought on such normalization in the OSP

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Tianran Zhou]

Hi Chairs and the WG,

I support the adoption of this document.

Cheers,
Tianran

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 10:17 PM
To: lsr@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Based on the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.

These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.

We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.

Thanks,
Acee and Chris

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

[Tianran Zhou]

Hi Thomas,

I think questions from both Ketan and Gyan on the IE usage are very important. 
The value should be described clearly in the draft. So that people now how to 
implement and use them.
Here your replay to Ketan on the mplsTopLabelType is clear to me. You want to 
account the traffic with different IGP distribution, to see if your network 
runs correct.
The SrSidType seems more complex.
"Since it describes that a particular adjacency is chosen to forward the packet 
instead of a prefix. If IE 89, ForwardingStatus is drop, we understand that 
result of that decision lead to the drop and this enables to narrow down 
forwarding issues in segment routing networks more efficiently and quickly."
Could you please make this use case more clear joint with IE89?
And this case want to justify the value of Adjacency SID. Is there any other 
use cases for accounting other sid types?

Thanks,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of 
thomas.g...@swisscom.com
Sent: Saturday, August 15, 2020 2:01 PM
To: ket...@cisco.com; han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; ops...@ietf.org
Subject: Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan,

?  This helps identification of specific SR-MPLS segment types as well as 
differentiating them from LDP, RSVP-TE, etc.

To be precise, the existing MPLS Label Type identifier differentiates from LDP, 
RSVP-TE. Not the new SrSidType IPFIX IE being proposed.

?  What value is provided for IPFIX analysis if the SR Prefix SID was being 
signalled via OSPF or ISIS?

It is important to distinguish between intend and result.

If you migrate from one label distribution protocol to another, a network 
operator want's to understand if the data plane is still forwarding packets 
with the label distribution protocol which needs to be removed or not. IE46 
enables that by looking at the result of the forwarded traffic and not at the 
intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section-3, 
describes the context.


?  What value is provided for IPFIX analysis if it was a Adjacency SID or a LAN 
Adjacency SID?

Quote from RFC8402. "Segment Routing (SR) leverages the source routing 
paradigm". Means that not the routing protocol does all the forwarding 
decisions, the node can change the forwarding by pushing additional labels.. 
With IPFIX SrSidType we are able to cover this dimension in IPFIX. Enabling to 
analyze the result of this decision. The example with " Adjacency SID or a LAN 
Adjacency SID" is not very useful because the difference of the two is the 
topology among the adjacency. If you compare " Adjacency SID with Prefix SID", 
that makes much more sense. Since it describes that a particular adjacency is 
chosen to forward the packet instead of a prefix. If IE 89, ForwardingStatus is 
drop, we understand that result of that decision lead to the drop and this 
enables to narrow down forwarding issues in segment routing networks more 
efficiently and quickly.


?  am asking for WG to weigh the implementation complexities

For the WG and me, I would be important if you can describe more detailed what 
you mean with implementation complexities. I would like to have a better 
understanding where your fear is coming from. I would appreciate if you could 
differentiate between MPLS Label Type identifier, IE46, from which label 
protocol the label was coming from and SrSidType which SID type was used..

Best wishes
Thomas

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Saturday, August 15, 2020 7:09 AM
To: Graf Thomas, INI-NET-DCF 
mailto:thomas.g...@swisscom.com>>; 
han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; 
ops...@ietf.org
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Thomas,

I should have been more clear in my email.

The proposal/suggestion is to add the following to the IPFIX MPLS Label type 
identifier registry:
-  SR Prefix SID
-  SR Adjacency SID
-  SR Binding SID
-  SR BGP Peering SID
-  ... and so on

This helps identification of specific SR-MPLS segment types as well as 
differentiating them from LDP, RSVP-TE, etc.

And my questions were:
1)  What value is provided for IPFIX analysis if the SR Prefix SID was 
being signalled via OSPF or ISIS?
2)  What value is provided for IPFIX analysis if it was a Adjacency SID or 
a LAN Adjacency SID?

I am asking for WG to weigh the implementation complexities and overheads with 
the proposed details of SR-MPLS segments in IPFIX against the benefit (if any) 
that they provide for the flow analysis and monitoring.

Thanks,
Ketan

From: thomas.g...@swisscom.com 
mailto:thomas.g...@swisscom.com>>
Sent: 15 August 2020 09:40
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
han...@gredler.at
Cc: lsr@ietf.org

Re: [Lsr] New Version Notification for draft-wang-lsr-igp-extensions-ifit-00.txt

[Tianran Zhou]

There is no convincable reason why IGP can not.

Some suggestions are about Netconf.

But Yali showed Netconf can not meet the requirement.


Tianran

--
Sent from WeLink

发件人：Les Ginsberg (ginsberg) 
收件人：Lizhenbin ;lsr 
抄 送：wangyali 
时 间：2020-07-18 04:34:51
主 题：Re: [Lsr] New Version Notification for 
draft-wang-lsr-igp-extensions-ifit-00.txt

Robin/Yali –
The argument here is circular.
You are saying “if the IGPs advertised ifit information/capability then it 
would be used”.
Sure.
But the question that was discussed three back was whether IGPs were the right 
vehicle to advertise this information or whether it should be done in other 
ways.
Please reread the thread: 
https://mailarchive.ietf.org/arch/browse/lsr/?gbt=1&index=5GdFCy7zg8eCIGvQZpmAbOtrTjQ
Les
From: Lizhenbin mailto:lizhen...@huawei.com>>
Sent: Friday, July 17, 2020 6:12 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: wangyali mailto:wangyal...@huawei.com>>
Subject: 答复: New Version Notification for 
draft-wang-lsr-igp-extensions-ifit-00.txt

Hi Les,

I add one more case for your reference. There are several SR-Policy/SR-Tunnel 
implementations which depend on the configuration on the devices other than the 
controller. If the IFIT capability is enabled for these SR-Policy/Tunnels, IGP 
will be helpful for the ingress node to learn the capabilities of other nodes 
along the SR-Policy/Tunnel.

Best Regards,

Robin


发件人: Lsr [lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>] 代表 wangyali 
[wangyal...@huawei.com<mailto:wangyal...@huawei.com>]
发送时间: 2020年7月17日 20:19
收件人: Les Ginsberg (ginsberg); lsr@ietf.org<mailto:lsr@ietf.org>
主题: Re: [Lsr] New Version Notification for 
draft-wang-lsr-igp-extensions-ifit-00.txt
Dear Les,
Many thanks for your quick feedback. We are very appreciate all of your 
insightful comments and advices. ☺
Please let me clarify the one of requirements is that the ingress node cannot 
insert IFIT instruction for packets going into a path unless the egress node 
signals its capability of processing IFIT data fields.
Actually, taking your suggestions and those of others into account, we tried to 
use NETCONF for query node capability. However, in the scenario of SR-BE, the 
ingress node controls a path along which packets are transmitted, which is not 
included in a centralized controller. Therefore, extensions to IGP for node’s 
capability advertisement is considered as an efficient way but NETCONF doesn't 
work.
Best regards,
Yali
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, July 17, 2020 5:25 AM
To: wangyali mailto:wangyal...@huawei.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: New Version Notification for 
draft-wang-lsr-igp-extensions-ifit-00.txt

Yali -

While it is kind of you to acknowledge many of us for our comments, in many 
cases (myself included) what we told you is that this does not belong in the 
IGPs.

Putting out a new draft which continues to push for advertising ifit in IGPs 
(even if in different TLVs) does not indicate that you are heeding our message. 
😊

Les

> -Original Message-

> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> wangyali

> Sent: Thursday, July 16, 2020 8:20 AM

> To: lsr@ietf.org<mailto:lsr@ietf.org>

> Subject: [Lsr] FW: New Version Notification for draft-wang-lsr-igp-

> extensions-ifit-00.txt

>

> Dear LSR WG,

>

> We've uploaded a new revision of draft-wang-lsr-igp-extensions-ifit-00 to

> replace draft-wang-lsr-ifit-node-capability-advertisement. In this new

> revision, Node and Link Attribute TLVs are extended to IGP for signaling the

> supported IFIT capability of egress and/or intermediate nodes to the ingress

> nodes.

>

> The changes in this revision are:

>

> 1. added Link Attribute TLVs extension to IGP to signal IFIT Capability at 
> link

> granularity.

> 2. updated Application section, which illustrates such advertisements would

> helpful for avoiding the leak of IFIT-specific header and metadata, as well 
> as,

> for ingress routers to gather each router's IFIT capability for achieving the

> computation of TE paths or loose TE paths that be able to fulfill the 
> visibility of

> on-path OAM data.

> 3. updated Acknowledgements sections, in which, the authors would like to

> thank Acee Lindem, Christian Hopps, Robert Raszuk, Les Ginsberg, Jeff

> Tantsura, Rakesh Gandhi, Tony Li and Greg Mirsky for the comments.

> 4. adding China Telecom into the author list.

>

> We are looking forward to hearing your feedback and comments, and try to

> achieve consensus.

>

> Thanks,

> Yali

>

>

> -Original Message-

> From: <mailto:internet-dra...@ietf.org&g

Re: [Lsr] Request WG adoption of TTZ

[Tianran Zhou]

Thanks. I am really glad to understand the LSR chair's thoughts.
Well OK. I understand LSR would like a high bar for IGP extension.
But your comparison with " research WG or a technical journal " makes no sense. 
It's common sense.
And your statement on the complexity twisted too many none engineer reasons.
I would like the IETF to be more pure on technique.
Anyway, I respect the tradition of this WG.
I just want to know if the WG request for interop and implementation report for 
every draft?

Thanks,
Tianran

-Original Message-
From: Christian Hopps [mailto:cho...@chopps.org] 
Sent: Thursday, July 16, 2020 7:54 PM
To: Tianran Zhou 
Cc: Christian Hopps ; Henk Smit ; 
lsr@ietf.org; Huaimo Chen 
Subject: Re: [Lsr] Request WG adoption of TTZ

My comments about what the WG should be doing are "As WGChair", I'm not 
commenting directly on TTZ, but on the broader comments/questions below.

> On Jul 16, 2020, at 6:19 AM, Tianran Zhou  wrote:
> 
> Hi Henk,
> 
> Thanks very much for your long email.
> I fully agree with what you said on the criterion. This is generally always 
> correct.
> But still you cannot score a draft with it.
> That means I can probably say most of the IETF RFCs has  no use.
> I can also list one hundred RFCs that is not implemented.

This is not what we strive for in LSR.

>  Are you going to obsolete them all?

No, but we as a WG can strive to not contribute to this problem.

> Who knows if they are useful in the future?

LSR is not a research WG or a technical journal.

> If you find it no use, just not to implement it. How could it make your 
> system complex?

This statement flies in the face of market realty.

People who have to fill RFPs from prospective customers, knowing that they are 
competing against other vendors filling those same RFPs out, can tell you why 
you can't just "not implement RFCs" if you don't want to, even when they will 
never actually be used by those same customers. The short answer is: RFPs are 
very often not written by the engineers that actually build and run the 
customer's networks; however, answers to RFPs have a direct impact on which 
vendors products are purchased by the customers.

So lots of unused RFCs leads to lots of useless code being written to win 
customers, which then leads to huge protocol code bases that are too complex 
and fragile, as well as protocols that are hard to comprehend and thus manage 
properly, and so ultimately destabalize the internet -- we have failed at this 
point.

This may be less of an issue with other WGs; however, the IGPs are a *critical* 
part of the internet infrastructure, and they need to be treated as such, and 
we should strive to do so.

Thanks,
Chris.

> 
> Best,
> Tianran
> 
> -----Original Message-
> From: Henk Smit [mailto:henk.i...@xs4all.nl]
> Sent: Thursday, July 16, 2020 4:46 PM
> To: Tianran Zhou 
> Cc: Huaimo Chen ; lsr@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> 
> Hello Tianran,
> 
> Warning, long email again.
> 
>> What's the criterion to evaluate the benefit?
> 
> As people have asked before, did any provider or enterprise ever use rfc8099 
> in their network ?
> 
> As I wrote, one of my criteria is rfc1925. I like technology to be 
> understandable. I like protocols to be (relatively) easy to implement. The 
> more unused cruft there is, the further we get away from that goal.
> 
> 
> I'll give you an example. Did you, or your company ever implement rfc2973 ? 
> That's mesh-groups in IS-IS.
> I'm sure some customers put it on their wishlist.
> Did any provider or customer ever use it ?
> I asked this question at my last job, and nobody knew the answer. I suspect 
> nobody in the world ever used mesh-groups.
> 
> Around the time I got in touch with IS-IS, in spring 1996, there was a 
> problem that was seen 2 of the 3 largest ISPs in the US (UUnet and iMCI). 
> Both networks melted because of IS-IS. All routers in their networks were 
> 100% cpu time running IS-IS, busy exchanging LSPs. While no progress was 
> made. The only solution was to reboot all routers in the backbone at the same 
> time (several hundred routers).
> This happened more than once in both networks.
> 
> To relieve the burden of flooding, mesh-groups were implemented, and rfc2973 
> was written. However, a short while later I became the sole IS-IS programmer 
> for that router vendor. I was able to reproduce the problem in the lab.
> I then realized what the issue was. A fix of 10 lines of extra code fixed the 
> problem. No customer ever reported those meltdowns again. That fix was the 
> real solution.
> Not writing another RFC.
> 
> In the mean-time, we have an extra RFC, about mesh-groups.
> Every book and manual o

Re: [Lsr] Request WG adoption of TTZ

[Tianran Zhou]

Hi Henk,

Thanks very much for your long email.
I fully agree with what you said on the criterion. This is generally always 
correct. 
But still you cannot score a draft with it.
That means I can probably say most of the IETF RFCs has  no use. 
I can also list one hundred RFCs that is not implemented. Are you going to 
obsolete them all?
Who knows if they are useful in the future?
If you find it no use, just not to implement it. How could it make your system 
complex?

Best,
Tianran

-Original Message-
From: Henk Smit [mailto:henk.i...@xs4all.nl] 
Sent: Thursday, July 16, 2020 4:46 PM
To: Tianran Zhou 
Cc: Huaimo Chen ; lsr@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ


Hello Tianran,

Warning, long email again.

> What's the criterion to evaluate the benefit?

As people have asked before, did any provider or enterprise ever use rfc8099 in 
their network ?

As I wrote, one of my criteria is rfc1925. I like technology to be 
understandable. I like protocols to be (relatively) easy to implement. The more 
unused cruft there is, the further we get away from that goal.


I'll give you an example. Did you, or your company ever implement rfc2973 ? 
That's mesh-groups in IS-IS.
I'm sure some customers put it on their wishlist.
Did any provider or customer ever use it ?
I asked this question at my last job, and nobody knew the answer. I suspect 
nobody in the world ever used mesh-groups.

Around the time I got in touch with IS-IS, in spring 1996, there was a problem 
that was seen 2 of the 3 largest ISPs in the US (UUnet and iMCI). Both networks 
melted because of IS-IS. All routers in their networks were 100% cpu time 
running IS-IS, busy exchanging LSPs. While no progress was made. The only 
solution was to reboot all routers in the backbone at the same time (several 
hundred routers).
This happened more than once in both networks.

To relieve the burden of flooding, mesh-groups were implemented, and rfc2973 
was written. However, a short while later I became the sole IS-IS programmer 
for that router vendor. I was able to reproduce the problem in the lab.
I then realized what the issue was. A fix of 10 lines of extra code fixed the 
problem. No customer ever reported those meltdowns again. That fix was the real 
solution.
Not writing another RFC.

In the mean-time, we have an extra RFC, about mesh-groups.
Every book and manual on IS-IS has to spent time explaining what mesh-groups 
are. Every vendor has to implement it.
Even when nobody in the world is using it. Mesh-groups were a superfluous idea. 
What I (and many others) are saying is that we don't want to specify and 
implement unnecessary things.
Even when nobody is using such a thing, it will live on forever.

> What I see the TTZ does have benefit.

Yes, TTZ and proxy-areas have benefit. Nobody is disagreeing.

But what people don't like is the new concept of a zone.
If you can abstract exactly one area into exactly one proxy-LSP, that is good 
enough for 99.9 % of cases. In OSPF it is harder to split or merge an area. In 
IS-IS it is a lot easier. So a network operator can design and change his areas 
first. And then implement proxy-areas as she/he wishes. Without much downtime.

If we introduce the concept of a "zone", someone is going to have to explain 
that to everybody in the world who uses IS-IS.
Have you ever taught a class on IS-IS to people who don't know routing 
protocols very well ?

> I am also wandering how it hurts the protocol in the long run ?

Adding stuff that nobody uses makes everything more complex.
I know it seems as if the goal over the last 15 years was to make every thing 
more complex. So what's the problem with adding yet another RFC ?

But I like simple things.

henk.


Tianran Zhou wrote on 2020-07-16 02:41:

> > "Adding a new concept, with very little benefit, hurts the protocol 
> > in the long run. The ability to abstract an area, and not also a 
> > zone, is strong enough to be worthwhile, imho."
> 
> Your conclusion here seems very subjective.
> What's the criterion the evaluate the benefit? What I see the TTZ does 
> have benefit.
> I am also wandering how it hurts the protocol in the long run?
> 
> 
> Tianran

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Tianran Zhou]

Hi Henk,

"Adding a new concept, with very little benefit, hurts the protocol in the long 
run. The ability to abstract an area, and not also a zone, is strong enough to 
be worthwhile, imho."

Your conclusion here seems very subjective.
What's the criterion the evaluate the benefit? What I see the TTZ does have 
benefit.
I am also wandering how it hurts the protocol in the long run?


Tianran


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Henk Smit
Sent: Wednesday, July 15, 2020 8:22 PM
To: Huaimo Chen 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Huaimo Chen wrote on 2020-07-14 06:09:

>  2). IS-IS TTZ abstracts a zone to a single node. A zone is any target 
> block or piece of an IS-IS area, which is to be abstracted. This seems 
> more flexible and convenient to users.

I don't agree that this convenience is really beneficial.
I actually think this convenience is a downside.


Link-state protocols are not easy to understand. And we already have the 
misfortune that IS-IS and OSPF use different names for things.
Adding the new concept of a "zone", while we already have the concept of an 
area makes things only more complex.

How often will this new flexibility be used in the real world ?
I still haven't seen an answer to Christian Hopp's simple question:
"Has RFC8099 been deployed by anyone ?"
Anyone who has an answer ?

My favorite rule of RFC1925 is rule 12:
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.

Adding a new concept, with very little benefit, hurts the protocol in the long 
run. The ability to abstract an area, and not also a zone, is strong enough to 
be worthwhile, imho.

henk.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

[Tianran Zhou]

I think I understand your clarification.
Let me conclude, so your logic is:
We can use IGP to signal labels, though entropy label is not included. So we 
can use IGP to signal entropy label capability.

If so, this logic is not straight forward to me.

Tianran

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Tuesday, June 2, 2020 4:31 PM
To: Tianran Zhou ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Tianran,

On 02/06/2020 10:25, Tianran Zhou wrote:
> Peter,
> 
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Tuesday, June 2, 2020 4:10 PM
> To: Tianran Zhou ; lsr@ietf.org
> Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
> 
> Tianran,
> 
> On 02/06/2020 08:14, Tianran Zhou wrote:
>> Hi Peter,
>>
>> I do not understand how RFC8667 relates to ELC signaling.
> 
> RFC 8667 - IS-IS Extensions for Segment Routing
> 
>> RFC 8667 "have been defined to signal labels", but "This draft defines a 
>> mechanism to signal the ELC using IS-IS."
> 
> yes, and as labels are now signaled by IGPs, we provide a method to signal 
> ELC/ERLD by IGPs as well.
> 
> ZTR> RFC8667 signals different SID. 

no, RFC8667 is ISIS extension for SR MPLS.

> But draft-ietf-ospf-mpls-elc is about entropy label. Or do you mean entropy 
> label is also signaled by IGP?

no, entropy label is not signaled AFAIK.

> 
>>
>> On the other hand, RFC 8667 is the extension for segment routing.
>> Is this draft only for segment routing, or be generic?
> 
> the requirement document is RFC8662, which is SR specific.
> 
> ZTR> "This draft" I mean draft-ietf-ospf-mpls-elc. So is 
> draft-ietf-ospf-mpls-elc SR specific?

SR was a primary motivation.

regards,
Peter



> 
> Thanks,
> Tianran
> 
>>
>> Another thing I am not clear is the difference between "multi-area" and 
>> "multi-domain" here after:
>>  "Even though ELC is a property of the node, in some cases it is
>>  advantageous to associate and advertise the ELC with a prefix.  In a
>>  multi-area network, routers may not know the identity of the prefix
>>  originator in a remote area, or may not know the capabilities of such
>>  originator.  Similarly, in a multi-domain network, the identity of
>>  the prefix originator and its capabilities may not be known to the
>>  ingress LSR."
> 
> 
> multi area is single IGP with multiple areas. Mutli domain is multiple IGPs.
> 
> thanks,
> Peter
> 
>>
>> Tianran
>>
>> -Original Message-
>> From: Peter Psenak [mailto:ppse...@cisco.com]
>> Sent: Monday, June 1, 2020 6:56 PM
>> To: Tianran Zhou ; lsr@ietf.org
>> Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
>>
>> Tianran,
>>
>> On 01/06/2020 12:49, Tianran Zhou wrote:
>>> Hi Authors,
>>>
>>> I see the following words in the introduction.
>>> "   Recently, mechanisms have been defined to signal labels via link-
>>>   state Interior Gateway Protocols (IGP) such as IS-IS [RFC8667].  "
>>>
>>> It's not clear to me what the " mechanisms " are. Could you please add some 
>>> reference or text on this?
>>
>> the reference is there - RFC8667.
>>
>>
>> thanks,
>> Peter
>>
>>>
>>> Thanks,
>>> Tianran
>>>
>>> -Original Message-
>>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
>>> internet-dra...@ietf.org
>>> Sent: Monday, June 1, 2020 4:42 PM
>>> To: i-d-annou...@ietf.org
>>> Cc: lsr@ietf.org
>>> Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.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   : Signaling Entropy Label Capability and Entropy 
>>> Readable Label Depth Using OSPF
>>>Authors : Xiaohu Xu
>>>  Sriganesh Kini
>>>  Peter Psenak
>>>  Clarence Filsfils
>>>  Stephane Litkowski
>>>  Matthew Bocci
>>> Filename: draft-ietf-ospf-mpls-elc-15.txt
>>> Pages   : 9
>>> Date: 2020-06-01
>>>
>>> Abstract:
>>&g

Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

[Tianran Zhou]

Peter,

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Tuesday, June 2, 2020 4:10 PM
To: Tianran Zhou ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Tianran,

On 02/06/2020 08:14, Tianran Zhou wrote:
> Hi Peter,
> 
> I do not understand how RFC8667 relates to ELC signaling.

RFC 8667 - IS-IS Extensions for Segment Routing

> RFC 8667 "have been defined to signal labels", but "This draft defines a 
> mechanism to signal the ELC using IS-IS."

yes, and as labels are now signaled by IGPs, we provide a method to signal 
ELC/ERLD by IGPs as well.

ZTR> RFC8667 signals different SID. But draft-ietf-ospf-mpls-elc is about 
entropy label. Or do you mean entropy label is also signaled by IGP?

> 
> On the other hand, RFC 8667 is the extension for segment routing.
> Is this draft only for segment routing, or be generic?

the requirement document is RFC8662, which is SR specific.

ZTR> "This draft" I mean draft-ietf-ospf-mpls-elc. So is 
draft-ietf-ospf-mpls-elc SR specific?

Thanks,
Tianran

> 
> Another thing I am not clear is the difference between "multi-area" and 
> "multi-domain" here after:
> "Even though ELC is a property of the node, in some cases it is
> advantageous to associate and advertise the ELC with a prefix.  In a
> multi-area network, routers may not know the identity of the prefix
> originator in a remote area, or may not know the capabilities of such
> originator.  Similarly, in a multi-domain network, the identity of
> the prefix originator and its capabilities may not be known to the
> ingress LSR."


multi area is single IGP with multiple areas. Mutli domain is multiple IGPs.

thanks,
Peter

> 
> Tianran
> 
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Monday, June 1, 2020 6:56 PM
> To: Tianran Zhou ; lsr@ietf.org
> Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
> 
> Tianran,
> 
> On 01/06/2020 12:49, Tianran Zhou wrote:
>> Hi Authors,
>>
>> I see the following words in the introduction.
>> "   Recently, mechanisms have been defined to signal labels via link-
>>  state Interior Gateway Protocols (IGP) such as IS-IS [RFC8667].  "
>>
>> It's not clear to me what the " mechanisms " are. Could you please add some 
>> reference or text on this?
> 
> the reference is there - RFC8667.
> 
> 
> thanks,
> Peter
> 
>>
>> Thanks,
>> Tianran
>>
>> -Original Message-
>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
>> internet-dra...@ietf.org
>> Sent: Monday, June 1, 2020 4:42 PM
>> To: i-d-annou...@ietf.org
>> Cc: lsr@ietf.org
>> Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.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   : Signaling Entropy Label Capability and Entropy 
>> Readable Label Depth Using OSPF
>>   Authors : Xiaohu Xu
>> Sriganesh Kini
>> Peter Psenak
>> Clarence Filsfils
>> Stephane Litkowski
>> Matthew Bocci
>>  Filename: draft-ietf-ospf-mpls-elc-15.txt
>>  Pages   : 9
>>  Date: 2020-06-01
>>
>> Abstract:
>>  Multiprotocol Label Switching (MPLS) has defined a mechanism to load-
>>  balance traffic flows using Entropy Labels (EL).  An ingress Label
>>  Switching Router (LSR) cannot insert ELs for packets going into a
>>  given Label Switched Path (LSP) unless an egress LSR has indicated
>>  via signaling that it has the capability to process ELs, referred to
>>  as the Entropy Label Capability (ELC), on that LSP.  In addition, it
>>  would be useful for ingress LSRs to know each LSR's capability for
>>  reading the maximum label stack depth and performing EL-based load-
>>  balancing, referred to as Entropy Readable Label Depth (ERLD).  This
>>  document defines a mechanism to signal these two capabilities using
>>  OSPFv2 and OSPFv3 and BGP-LS.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-15
>> https://datatr

Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

[Tianran Zhou]

Hi Peter,

I do not understand how RFC8667 relates to ELC signaling.
RFC 8667 "have been defined to signal labels", but "This draft defines a 
mechanism to signal the ELC using IS-IS."

On the other hand, RFC 8667 is the extension for segment routing. 
Is this draft only for segment routing, or be generic?

Another thing I am not clear is the difference between "multi-area" and 
"multi-domain" here after:
   "Even though ELC is a property of the node, in some cases it is
   advantageous to associate and advertise the ELC with a prefix.  In a
   multi-area network, routers may not know the identity of the prefix
   originator in a remote area, or may not know the capabilities of such
   originator.  Similarly, in a multi-domain network, the identity of
   the prefix originator and its capabilities may not be known to the
   ingress LSR."

Tianran

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Monday, June 1, 2020 6:56 PM
To: Tianran Zhou ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Tianran,

On 01/06/2020 12:49, Tianran Zhou wrote:
> Hi Authors,
> 
> I see the following words in the introduction.
> "   Recently, mechanisms have been defined to signal labels via link-
> state Interior Gateway Protocols (IGP) such as IS-IS [RFC8667].  "
> 
> It's not clear to me what the " mechanisms " are. Could you please add some 
> reference or text on this?

the reference is there - RFC8667.


thanks,
Peter

> 
> Thanks,
> Tianran
> 
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
> Sent: Monday, June 1, 2020 4:42 PM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.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   : Signaling Entropy Label Capability and Entropy 
> Readable Label Depth Using OSPF
>  Authors : Xiaohu Xu
>Sriganesh Kini
>Peter Psenak
>Clarence Filsfils
>Stephane Litkowski
>Matthew Bocci
>   Filename: draft-ietf-ospf-mpls-elc-15.txt
>   Pages   : 9
>   Date: 2020-06-01
> 
> Abstract:
> Multiprotocol Label Switching (MPLS) has defined a mechanism to load-
> balance traffic flows using Entropy Labels (EL).  An ingress Label
> Switching Router (LSR) cannot insert ELs for packets going into a
> given Label Switched Path (LSP) unless an egress LSR has indicated
> via signaling that it has the capability to process ELs, referred to
> as the Entropy Label Capability (ELC), on that LSP.  In addition, it
> would be useful for ingress LSRs to know each LSR's capability for
> reading the maximum label stack depth and performing EL-based load-
> balancing, referred to as Entropy Readable Label Depth (ERLD).  This
> document defines a mechanism to signal these two capabilities using
> OSPFv2 and OSPFv3 and BGP-LS.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-15
> https://datatracker.ietf.org/doc/html/draft-ietf-ospf-mpls-elc-15
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-mpls-elc-15
> 
> 
> 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

[Tianran Zhou]

Hi Authors,

I see the following words in the introduction.
"   Recently, mechanisms have been defined to signal labels via link-
   state Interior Gateway Protocols (IGP) such as IS-IS [RFC8667].  "

It's not clear to me what the " mechanisms " are. Could you please add some 
reference or text on this?

Thanks,
Tianran

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Monday, June 1, 2020 4:42 PM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.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   : Signaling Entropy Label Capability and Entropy 
Readable Label Depth Using OSPF
Authors : Xiaohu Xu
  Sriganesh Kini
  Peter Psenak
  Clarence Filsfils
  Stephane Litkowski
  Matthew Bocci
Filename: draft-ietf-ospf-mpls-elc-15.txt
Pages   : 9
Date: 2020-06-01

Abstract:
   Multiprotocol Label Switching (MPLS) has defined a mechanism to load-
   balance traffic flows using Entropy Labels (EL).  An ingress Label
   Switching Router (LSR) cannot insert ELs for packets going into a
   given Label Switched Path (LSP) unless an egress LSR has indicated
   via signaling that it has the capability to process ELs, referred to
   as the Entropy Label Capability (ELC), on that LSP.  In addition, it
   would be useful for ingress LSRs to know each LSR's capability for
   reading the maximum label stack depth and performing EL-based load-
   balancing, referred to as Entropy Readable Label Depth (ERLD).  This
   document defines a mechanism to signal these two capabilities using
   OSPFv2 and OSPFv3 and BGP-LS.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-15
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-mpls-elc-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-mpls-elc-15


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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

[Tianran Zhou]

Hi Acee,

Please let’s firstly align on the same use case we discussed.
I talked about the TE. And the path computation entity can use the IFIT 
capability information for the path decision. On the other hand if the path is 
decided, the capability information can help the entity to deploy a suitable 
IFIT option.
So did you talk about the BE? Node only know the next hop, not the whole path. 
So the management system need the trace to get the path information. How BE 
could use the IFIT capability is another use case. Is this you want to know?

Tianran

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, April 8, 2020 7:04 PM
To: Tianran Zhou ; Jeff Tantsura 
; Les Ginsberg (ginsberg) 
; Tony Li 
Cc: Greg Mirsky ; ops...@ietf.org; 
draft-song-opsawg-ifit-framew...@ietf.org; 
draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

Tianran,

You keep missing my point. Even if the potential transit nodes advertise the 
capability, the management function doesn’t know which nodes will be transited 
in the path. Hence, you’re second use case is misguided.

Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Tianran Zhou mailto:zhoutian...@huawei.com>>
Date: Wednesday, April 8, 2020 at 2:51 AM
To: Acee Lindem mailto:a...@cisco.com>>, Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>, "Les Ginsberg 
(ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>,
 Tony Li mailto:tony1ath...@gmail.com>>
Cc: Greg Mirsky mailto:gregimir...@gmail.com>>, 
"ops...@ietf.org<mailto:ops...@ietf.org>" 
mailto:ops...@ietf.org>>, 
"draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>"
 
mailto:draft-song-opsawg-ifit-framew...@ietf.org>>,
 
"draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org<mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>"
 
mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>>,
 "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

Hi Acee,

Tracing is of course useful.
Here we  also consider to combine the traffic engineering and monitoring. So 
the transit nodes are visible.
For the loose TE, the intermediate SR nodes construct the segment monitoring.

Tianran

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, April 8, 2020 4:29 AM
To: Tianran Zhou mailto:zhoutian...@huawei.com>>; Jeff 
Tantsura mailto:jefftant.i...@gmail.com>>; Les 
Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Tony Li mailto:tony1ath...@gmail.com>>
Cc: Greg Mirsky mailto:gregimir...@gmail.com>>; 
draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>;
 lsr@ietf.org<mailto:lsr@ietf.org>; ops...@ietf.org<mailto:ops...@ietf.org>; 
draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org<mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>
Subject: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

Speaking as WG member:

With respect to your use case for transit router advertisement… What I was 
unsuccessfully trying to articulate to you during the interim was that the 
management system will typically not know the exact path between two endpoints 
so the use case is flawed. In fact, many times tracing is used by the 
management system to discover the path – as in traceroute…

Thanks,
Acee



From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Date: Tuesday, April 7, 2020 at 3:22 AM
To: Acee Lindem mailto:a...@cisco.com>>, Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>, "Les Ginsberg 
(ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>,
 Tony Li mailto:tony1ath...@gmail.com>>
Cc: Greg Mirsky mailto:gregimir...@gmail.com>>, 
"draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>"
 
mailto:draft-song-opsawg-ifit-framew...@ietf.org>>,
 "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"ops...@ietf.org<mailto:ops...@ietf.org>" 
mailto:ops...@ietf.org>>, 
"draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org<mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>"
 
mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>>
Subject: RE: [Lsr] I,Scope of FIT Capability: a node or a link?

Hi Acee,

About the “IFIT specific information channel”, as in 
https://datatracker.ietf.org/doc/draft-qin-idr-sr-policy-ifit/
we propose to use bgp enabled sr-policy for IFIT auto deployment.
It’s reasonable to incorporate both traffic engineering and monitoring.

Thanks,
Tianran

发件人: Acee Lindem (acee) [mailto:a...@cisco.co

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

[Tianran Zhou]

Hi Acee,

Tracing is of course useful.
Here we  also consider to combine the traffic engineering and monitoring. So 
the transit nodes are visible.
For the loose TE, the intermediate SR nodes construct the segment monitoring.

Tianran

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, April 8, 2020 4:29 AM
To: Tianran Zhou ; Jeff Tantsura 
; Les Ginsberg (ginsberg) 
; Tony Li 
Cc: Greg Mirsky ; 
draft-song-opsawg-ifit-framew...@ietf.org; lsr@ietf.org; ops...@ietf.org; 
draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org
Subject: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

Speaking as WG member:

With respect to your use case for transit router advertisement… What I was 
unsuccessfully trying to articulate to you during the interim was that the 
management system will typically not know the exact path between two endpoints 
so the use case is flawed. In fact, many times tracing is used by the 
management system to discover the path – as in traceroute…

Thanks,
Acee



From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Date: Tuesday, April 7, 2020 at 3:22 AM
To: Acee Lindem mailto:a...@cisco.com>>, Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>, "Les Ginsberg 
(ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>,
 Tony Li mailto:tony1ath...@gmail.com>>
Cc: Greg Mirsky mailto:gregimir...@gmail.com>>, 
"draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>"
 
mailto:draft-song-opsawg-ifit-framew...@ietf.org>>,
 "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"ops...@ietf.org<mailto:ops...@ietf.org>" 
mailto:ops...@ietf.org>>, 
"draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org<mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>"
 
mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>>
Subject: RE: [Lsr] I,Scope of FIT Capability: a node or a link?

Hi Acee,

About the “IFIT specific information channel”, as in 
https://datatracker.ietf.org/doc/draft-qin-idr-sr-policy-ifit/
we propose to use bgp enabled sr-policy for IFIT auto deployment.
It’s reasonable to incorporate both traffic engineering and monitoring.

Thanks,
Tianran

发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2020年4月7日 2:54
收件人: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Tony Li mailto:tony1ath...@gmail.com>>
抄送: Greg Mirsky mailto:gregimir...@gmail.com>>; 
draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>;
 lsr@ietf.org<mailto:lsr@ietf.org>; ops...@ietf.org<mailto:ops...@ietf.org>; 
Tianran Zhou mailto:zhoutian...@huawei.com>>; 
draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org<mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>
主题: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

Speaking as WG member – It seems that additional IFIT-specific information is 
required to make this useful and the IGPs are certainly not the case. 
Additionally, the point was made that an IFIT specific information channel 
would anyway be required to provision the telemetry generation.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Jeff 
Tantsura mailto:jefftant.i...@gmail.com>>
Date: Monday, April 6, 2020 at 2:33 PM
To: "Les Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>,
 Tony Li mailto:tony1ath...@gmail.com>>
Cc: Greg Mirsky mailto:gregimir...@gmail.com>>, 
"draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>"
 
mailto:draft-song-opsawg-ifit-framew...@ietf.org>>,
 "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"ops...@ietf.org<mailto:ops...@ietf.org>" 
mailto:ops...@ietf.org>>, Tianran Zhou 
mailto:zhoutian...@huawei.com>>, 
"draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org<mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>"
 
mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>>
Subject: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

+1
Please do not take my comments about link vs node capabilities, as support for 
the solution, they are semantical.

Cheers,
Jeff
On Apr 6, 2020, 8:58 AM -0700, Tony Li 
mailto:tony1ath...@gmail.com>>, wrote:


This discussion is interesting, but please do not ignore the considerable 
feedback from multiple folks indicating that this advertisement does not belong 
in the IGP at all (regardless of scope).
My opinion on that has not changed.


+1

IS-IS is not the correct place to implement Service Discovery mechanisms. The 
management plane already has ample mechanisms for service and capability 
discovery.

Tony


___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

[Tianran Zhou]

Hi Acee,

>Why wouldn’t you just provision it via a YANG subscription?

YANG subscription is about exporting data to the collector. Here we firstly 
need to enable IFIT measurement along the path.

>An SR Policy could be identified by a  tuple in the 
>subscription? There can be many candidate SR policies but only the best-path 
>is active. You’d need to update all the candidate policies in order to assure 
>your iFIT tracing is enabled on the corresponding SR path.

Yes. But that’s how SR-Policy encoded in BGP and PCEP. There may be different 
algorithms/logic from the path computation entities, which generate multiple 
candidate paths. I think both granularity, SR-policy and Candidate Path, are 
useful. Like the discussion on node or link granularity.

>Why would you want to put this in BGP?

SR-Policy is encoded in BGP. And not just BGP, but also PCEP.
https://datatracker.ietf.org/doc/draft-chen-pce-sr-policy-ifit/


Best Wishes,
Tianran

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, April 8, 2020 4:25 AM
To: Tianran Zhou ; Jeff Tantsura 
; Les Ginsberg (ginsberg) 
; Tony Li 
Cc: Greg Mirsky ; 
draft-song-opsawg-ifit-framew...@ietf.org; lsr@ietf.org; ops...@ietf.org; 
draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org
Subject: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

Speaking as WG member:

Hi Tianran,

The more I look, the less I like this. We have a YANG infra-structure for 
telemetry data using YANG pub/sub. It is being implement and deployed over both 
NETCONF and proprietary transports. Why would we want to take just this type of 
telemetry out and handle it differently??? See an inline below…

From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Date: Tuesday, April 7, 2020 at 3:22 AM
To: Acee Lindem mailto:a...@cisco.com>>, Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>, "Les Ginsberg 
(ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>,
 Tony Li mailto:tony1ath...@gmail.com>>
Cc: Greg Mirsky mailto:gregimir...@gmail.com>>, 
"draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>"
 
mailto:draft-song-opsawg-ifit-framew...@ietf.org>>,
 "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"ops...@ietf.org<mailto:ops...@ietf.org>" 
mailto:ops...@ietf.org>>, 
"draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org<mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>"
 
mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>>
Subject: RE: [Lsr] I,Scope of FIT Capability: a node or a link?

Hi Acee,

About the “IFIT specific information channel”, as in 
https://datatracker.ietf.org/doc/draft-qin-idr-sr-policy-ifit/
we propose to use bgp enabled sr-policy for IFIT auto deployment.
It’s reasonable to incorporate both traffic engineering and monitoring.

I think this is a terrible idea. Why wouldn’t you just provision it via a YANG 
subscription? An SR Policy could be identified by a  tuple in 
the subscription? There can be many candidate SR policies but only the 
best-path is active. You’d need to update all the candidate policies in order 
to assure your iFIT tracing is enabled on the corresponding SR path. Why would 
you want to put this in BGP?

Acee


Thanks,
Tianran

发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2020年4月7日 2:54
收件人: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Tony Li mailto:tony1ath...@gmail.com>>
抄送: Greg Mirsky mailto:gregimir...@gmail.com>>; 
draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>;
 lsr@ietf.org<mailto:lsr@ietf.org>; ops...@ietf.org<mailto:ops...@ietf.org>; 
Tianran Zhou mailto:zhoutian...@huawei.com>>; 
draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org<mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>
主题: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

Speaking as WG member – It seems that additional IFIT-specific information is 
required to make this useful and the IGPs are certainly not the case. 
Additionally, the point was made that an IFIT specific information channel 
would anyway be required to provision the telemetry generation.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Jeff 
Tantsura mailto:jefftant.i...@gmail.com>>
Date: Monday, April 6, 2020 at 2:33 PM
To: "Les Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>,
 Tony Li mailto:tony1ath...@gmail.com>>
Cc: Greg Mirsky mailto:gregimir...@gmail.com>>, 
"draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>"
 
mailto:draft-song-opsawg-ifit-framew...@ietf.org>>,
 "lsr@ietf.org<

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

[Tianran Zhou]

Hi Acee,

About the “IFIT specific information channel”, as in 
https://datatracker.ietf.org/doc/draft-qin-idr-sr-policy-ifit/
we propose to use bgp enabled sr-policy for IFIT auto deployment.
It’s reasonable to incorporate both traffic engineering and monitoring.

Thanks,
Tianran

发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2020年4月7日 2:54
收件人: Jeff Tantsura ; Les Ginsberg (ginsberg) 
; Tony Li 
抄送: Greg Mirsky ; 
draft-song-opsawg-ifit-framew...@ietf.org; lsr@ietf.org; ops...@ietf.org; 
Tianran Zhou ; 
draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org
主题: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

Speaking as WG member – It seems that additional IFIT-specific information is 
required to make this useful and the IGPs are certainly not the case. 
Additionally, the point was made that an IFIT specific information channel 
would anyway be required to provision the telemetry generation.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Jeff 
Tantsura mailto:jefftant.i...@gmail.com>>
Date: Monday, April 6, 2020 at 2:33 PM
To: "Les Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>,
 Tony Li mailto:tony1ath...@gmail.com>>
Cc: Greg Mirsky mailto:gregimir...@gmail.com>>, 
"draft-song-opsawg-ifit-framew...@ietf.org<mailto:draft-song-opsawg-ifit-framew...@ietf.org>"
 
mailto:draft-song-opsawg-ifit-framew...@ietf.org>>,
 "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"ops...@ietf.org<mailto:ops...@ietf.org>" 
mailto:ops...@ietf.org>>, Tianran Zhou 
mailto:zhoutian...@huawei.com>>, 
"draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org<mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>"
 
mailto:draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org>>
Subject: Re: [Lsr] I,Scope of FIT Capability: a node or a link?

+1
Please do not take my comments about link vs node capabilities, as support for 
the solution, they are semantical.

Cheers,
Jeff
On Apr 6, 2020, 8:58 AM -0700, Tony Li 
mailto:tony1ath...@gmail.com>>, wrote:


This discussion is interesting, but please do not ignore the considerable 
feedback from multiple folks indicating that this advertisement does not belong 
in the IGP at all (regardless of scope).
My opinion on that has not changed.


+1

IS-IS is not the correct place to implement Service Discovery mechanisms. The 
management plane already has ample mechanisms for service and capability 
discovery.

Tony


___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

[Tianran Zhou]

Hi Greg,

Thanks very much for your interest on both IFIT framework and IFIT capability 
draft. And thanks for your review comments.
Your perspective on both drafts are correct.
On the node or link capability, thanks for your suggestion.
I agree with both you and Jeff. The link capability can make the information 
more clear and accurate for different scenarios.
Why we only considered the node capability? That’s the trade off to reduce 
complexity. We just want to start from simple cases.
If the WG think link capability is necessary, we would like to add link 
capabilities to the update.

Cheers,
Tianran

发件人: Greg Mirsky [mailto:gregimir...@gmail.com]
发送时间: 2020年4月5日 10:33
收件人: draft-wang-lsr-ifit-node-capability-advertisem...@ietf.org; lsr@ietf.org; 
draft-song-opsawg-ifit-framew...@ietf.org; ops...@ietf.org
主题: I,Scope of FIT Capability: a node or a link?

Dear All,
I've read these two drafts with interest. In light of the discussion on the LSR 
WG list, I've been thinking about the scenarios where IFIT is being used.
draft-song-opsawg-ifit-framework defines the overall IFIT architecture that, as 
I understand it, applicable to different methods of collecting and transporting 
telemetry information. draft-wang-lsr-ifit-node-capability-advertisement is 
based on the view that IFIT is a node-wide capability advertised as a binary 
flag for each listed method of collecting telemetry information (Option-Type 
enabled Flag). On-path telemetry collection is performed in the fast path, 
i.e., at a link layer. But a node might include ports with different 
capabilities. How such a heterogeneous, IFIT-wise, node will advertise IFIT 
Capability? To better use available resources for telemetry information 
collection, it might be helpful to advertise IFIT as a capability of a link, 
not of a node?
What do you think?

Regards,
Greg
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Tianran Zhou]

Hi Greg,
Thanks for your replay. Please see in line.

Cheers,
Tianran

发件人: Greg Mirsky [mailto:gregimir...@gmail.com]
发送时间: 2020年4月4日 6:13
收件人: Tianran Zhou 
抄送: wangyali ; Acee Lindem (acee) ; Les 
Ginsberg (ginsberg) ; Christian Hopps ; 
lsr@ietf.org
主题: Re: [Lsr] 答复: A new version of I-D, 
draft-liu-lsr-isis-ifit-node-capability-02

Hi Tianran,
thank you for your kind attention to my questions. Please find my notes 
in-lined below under the GIM>> tag.

Kind regards,
Greg

On Thu, Apr 2, 2020 at 11:33 PM Tianran Zhou 
mailto:zhoutian...@huawei.com>> wrote:
Hi Greg,

Good questions. Please see my reply in line.

Thanks,
Tianran

From: Greg Mirsky [mailto:gregimir...@gmail.com<mailto:gregimir...@gmail.com>]
Sent: Friday, April 3, 2020 6:58 AM
To: wangyali mailto:wangyal...@huawei.com>>
Cc: Acee Lindem (acee) mailto:a...@cisco.com>>; Les Ginsberg 
(ginsberg) mailto:ginsb...@cisco.com>>; Christian Hopps 
mailto:cho...@chopps.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Tianran Zhou 
mailto:zhoutian...@huawei.com>>
Subject: Re: [Lsr] 答复: A new version of I-D, 
draft-liu-lsr-isis-ifit-node-capability-02

Hi Yali, et al,
thank you for the interesting discussion. I have several questions about the 
purpose of advertising ifit capabilities in IGP (and in general):

  *   Do you see a capability to export telemetry information as a mandatory or 
optional?
What’s the context with this question? Frankly, I did not have a deep well 
thinking on this question. But in our case, I wish it’s mandatory.
GIM>> If it is mandatory, then all nodes in a domain support IFIT and, 
consequently, there's no need to advertise the capability in the homogeneous, 
IFIT-wise, domain. Would you agree?

ZTR>> I am sorry, I did not understand  your question before. Yes, you are 
right. So here we assume that not all nodes support IFIT, and different nodes 
may support different data plane options.

  *   Do you expect that a segment route to be constructed to prefer 
ifit-capable nodes comparing to nodes that are not?
Yes. This is one use case. As my echo to Robert, we want to achieve the SLA 
assurance network. We think the capability for visibility to verify the SLA 
compliance, and also the capability to get the accurate measurement for path 
computation should be considered. Should be considered from the very beginning 
when we compute the path.
GIM>> I understand that IFIT-capability might be used as one of CSPF 
constraints. But, as I think of it, it can simply be discovered in the course 
of running on-path telemetry collection. Would you agree?

ZTR>>We also considered some options for the IFIT-capability discovery. It 
seems what we proposed here is more elegant and straight forward.
Thank you for your kind consideration of my questions.

Regards,
Greg

On Wed, Apr 1, 2020 at 8:13 PM wangyali 
mailto:wangyal...@huawei.com>> wrote:
Hi Acee, Chris and Les,

This is Yali. Many thanks for your kind comments and suggestion.

Besides of signaling MSD by IGP node CAPABILITY TLV, we learned that there's 
another RFC7883 that advertising S-BFD discriminators in IS-IS. In my 
understand, BFD is a protocol to detect faults in the bidirectional path 
between two forwarding engines, including interface, data links, etc.

Similarly, IFIT provides a complete framework of a family of on-path telemetry 
techniques, which are used to monitoring performance metrics of service flows, 
e.g. packet loss, delay. So we consider there's a same methodology with S-BFD 
that advertising IFIT node capabilities.

Please let us know your comments and opinion. Thanks.

Best regards,
Yali

-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com<mailto:a...@cisco.com>]
发送时间: 2020年4月1日 20:29
收件人: Tianran Zhou mailto:zhoutian...@huawei.com>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Christian 
Hopps mailto:cho...@chopps.org>>
抄送: lsr@ietf.org<mailto:lsr@ietf.org>; wangyali 
mailto:wangyal...@huawei.com>>
主题: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Speak as WG Member...

On 4/1/20, 8:08 AM, "Acee Lindem (acee)" 
mailto:a...@cisco.com>> wrote:

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" 
mailto:lsr-boun...@ietf.org> on behalf of 
zhoutian...@huawei.com<mailto:zhoutian...@huawei.com>> 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,
Tianra

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

[Tianran Zhou]

Hi Les,

Please let me justify.
IMHO, compute a path based on the IFIT capability is the first step that we can 
correctly get the in-situ telemetry information.
And then, based on the reactive control mentioned in the IFIT framework, we can 
adjust/re-compute the path according to the update of the telemetry information.

Tianran

-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
Sent: Thursday, April 2, 2020 8:47 PM
To: Christian Hopps ; Robert Raszuk 
Cc: wangyali ; Acee Lindem (acee) ; 
lsr@ietf.org; Tianran Zhou 
Subject: RE: [Lsr] A new version of I-D, 
draft-liu-lsr-isis-ifit-node-capability-02

Robert -

First, +1 to what Chris has said.

There is nothing in the lfit-capability draft that defines any information that 
can be used by IGPs to do what you suggest.
Perhaps it is possible that information gleaned via a telemetry application 
could be used by the IGPs to do something like what you suggest - but this 
draft is not discussing/defining that. It is simply proposing to advertise 
information about the capabilities of the lfit application on a given node. 

   Les

> -Original Message-
> From: Christian Hopps 
> Sent: Thursday, April 02, 2020 5:13 AM
> To: Robert Raszuk 
> Cc: Christian Hopps ; Les Ginsberg (ginsberg) 
> ; wangyali ; Acee Lindem
> (acee) ; lsr@ietf.org; Tianran Zhou 
> 
> Subject: Re: [Lsr] A new version of I-D, 
> draft-liu-lsr-isis-ifit-node-capability-02
> 
> We have defined a perfectly acceptable and quite powerful way to do 
> query and configuration for routers, it's YANG. I'd like to hear why 
> the the IETF standard mechanism for query and configuration can't work 
> for this application.
> 
> Telemetry is important, I don't think anyone has said or would say 
> that it isn't, but that seems orthogonal to this discussion.
> 
> Thanks,
> Chris.
> [as WG member]
> 
> 
> > On Apr 2, 2020, at 5:17 AM, Robert Raszuk  wrote:
> >
> > Hi Les,
> >
> > I would like to respectfully disagree with your assessment.
> >
> > The fact that today's IGP (or for that matter BGP) routing is static 
> > from the
> perspective of not taking into consideration real performance 
> measurements from the data plane to me is a bug not a feature.
> >
> > Building SPT based on static link metrics which in vast majority of 
> > cases
> today are emulated circuits on someone else IP backbone. It was a 
> great idea when you constructed the network with connection oriented 
> paradigm (Sonet,SDH, dark fiber, TDM ...) not connection less often best 
> effort one.
> >
> > So I find this proposal very useful and would vote for adopting it in LSR 
> > WG.
> To me in-situ telemetry is not just some monitoring tool. It is an 
> extremely important element to influence how we compute reachability 
> or at least how we choose active forwarding paths from protocol RIBs to main 
> RIB.
> >
> > If we extended IGPs to carry TE information, if we extended them to
> enable flexible algorithm based path computation I fail to understand 
> why would we resist to natively enable all of the above with getting 
> the inputs from real networks to be used as to the parameters to the 
> above mentioned tools.
> >
> > Kind regards,
> > R.
> >
> > On Thu, Apr 2, 2020 at 8:32 AM Les Ginsberg (ginsberg)
>  wrote:
> > Yali -
> >
> > There is a very significant difference between having IGPs advertise 
> > an
> identifier for a service that they use as clients (BFD) and having 
> IGPs advertise a set of capabilities/options for a telemetry 
> application which has no direct bearing on the function of the routing 
> protocol.
> >
> > You are not the first to find using IGPs to flood application 
> > information very
> convenient.  But this is not the appropriate role for the IGPs and 
> over the years we have consistently resisted attempts to do so.
> >
> > Everything advertised in Router Capabilities today has some close
> relationship with the operation of the protocol. Do some of the 
> existing advertisements "bend the rules" a bit more than I would 
> prefer? Yes - but there has always been at least a close relationship 
> to routing protocol function.
> > Here there is none.
> >
> > If you feel compelled to use IGPs to advertise application 
> > information, you
> have RF6823 available (at least for IS-IS). But it is a "high bar" 
> since it requires you also to use a separate IS-IS instance dedicated 
> to advertising the application information (see RFC8202).
> > I think Chris Hopps's suggestion to use Netconf/YANG to 
> > configure/retrieve
> what you ne

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

[Tianran Zhou]

Hi Greg,

Good questions. Please see my reply in line.

Thanks,
Tianran

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Friday, April 3, 2020 6:58 AM
To: wangyali 
Cc: Acee Lindem (acee) ; Les Ginsberg (ginsberg) 
; Christian Hopps ; lsr@ietf.org; 
Tianran Zhou 
Subject: Re: [Lsr] 答复: A new version of I-D, 
draft-liu-lsr-isis-ifit-node-capability-02

Hi Yali, et al,
thank you for the interesting discussion. I have several questions about the 
purpose of advertising ifit capabilities in IGP (and in general):

  *   Do you see a capability to export telemetry information as a mandatory or 
optional?
What’s the context with this question? Frankly, I did not have a deep well 
thinking on this question. But in our case, I wish it’s mandatory.

  *   Do you expect that a segment route to be constructed to prefer 
ifit-capable nodes comparing to nodes that are not?
Yes. This is one use case. As my echo to Robert, we want to achieve the SLA 
assurance network. We think the capability for visibility to verify the SLA 
compliance, and also the capability to get the accurate measurement for path 
computation should be considered. Should be considered from the very beginning 
when we compute the path.
Thank you for your kind consideration of my questions.

Regards,
Greg

On Wed, Apr 1, 2020 at 8:13 PM wangyali 
mailto:wangyal...@huawei.com>> wrote:
Hi Acee, Chris and Les,

This is Yali. Many thanks for your kind comments and suggestion.

Besides of signaling MSD by IGP node CAPABILITY TLV, we learned that there's 
another RFC7883 that advertising S-BFD discriminators in IS-IS. In my 
understand, BFD is a protocol to detect faults in the bidirectional path 
between two forwarding engines, including interface, data links, etc.

Similarly, IFIT provides a complete framework of a family of on-path telemetry 
techniques, which are used to monitoring performance metrics of service flows, 
e.g. packet loss, delay. So we consider there's a same methodology with S-BFD 
that advertising IFIT node capabilities.

Please let us know your comments and opinion. Thanks.

Best regards,
Yali

-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com<mailto:a...@cisco.com>]
发送时间: 2020年4月1日 20:29
收件人: Tianran Zhou mailto:zhoutian...@huawei.com>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Christian 
Hopps mailto:cho...@chopps.org>>
抄送: lsr@ietf.org<mailto:lsr@ietf.org>; wangyali 
mailto:wangyal...@huawei.com>>
主题: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Speak as WG Member...

On 4/1/20, 8:08 AM, "Acee Lindem (acee)" 
mailto:a...@cisco.com>> wrote:

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" 
mailto:lsr-boun...@ietf.org> on behalf of 
zhoutian...@huawei.com<mailto:zhoutian...@huawei.com>> 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:ginsb...@cisco.com<mailto:ginsb...@cisco.com>]
Sent: Wednesday, April 1, 2020 1:47 PM
To: Tianran Zhou 
mailto:zhoutian...@huawei.com>>; Christian Hopps 
mailto:cho...@chopps.org>>
Cc: wangyali mailto:wangyal...@huawei.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
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 
mailto:zhoutian...@huawei.com>>
> Sent: Tuesday, March 31, 2020 7:53 PM
> To: Christian Hopps mailto:cho...@chopps.org>>
> Cc: wangyali mailto:wangyal...@huawei.com>>; 
Les Ginsberg (ginsberg)
> mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
> Subject: RE: [Lsr] A new version of 

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

[Tianran Zhou]

Hi Robert,

You provide the perfect examples. That is exactly what we want to do with the 
IFIT control plane.
While we used to consider resources as the cost(static or dynamic) for the path 
computation, here we also need to consider the IFIT capability that the node 
can support.
We want to achieve the SLA assurance network, not only we can compute a best 
performance path, but also we can provide corresponding SLA visibility and 
measurement on this path.

Cheers,
Tianran

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, April 3, 2020 5:17 AM
To: Jeff Tantsura 
Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org; Christian Hopps 
; Acee Lindem (acee) ; Tianran Zhou 
; wangyali 
Subject: Re: [Lsr] A new version of I-D, 
draft-liu-lsr-isis-ifit-node-capability-02

Jeff.

> The role of a routing protocol is to distribute: reachability (doh :-))
> and any additional data that could influence routing decision wrt 
> reachability.

The bolded text is precisely the point here.

So let me provide a very simple example.

Today routers already compute CSPF. Moreover today routers are asked to use 
custom/flexible algorithm to choose reachability paths.

So just imagine an operator who says:

Please compute my SPT with the consideration that end to end inband jitter is 
not greater then 10 ms otherwise I do not want to see nodes which do not meet 
that criteria in the reachability graph for application X.

or

Please compute my SPT with the consideration that end to end drop rate is not 
greater then  5pps otherwise I do not want to see nodes which do not meet that 
criteria in the reachability graph for application Y.

etc ...

If you consider such constrains to provide reachability for applications you 
will likely see value that in-situ telemetry is your friend here. Really best 
friend as without him you can not do the proper end to end path exclusion for 
SPT computations.

Hint: All per link extensions which were added to IGPs are not going to help 
here as drops or jitter may equally happen in the routers fabric on fabric to 
LC boundaries or on the line cards and links. So you need end to end test 
stream.

Many thx,
R.

PS. As we are talking LSR here it is strange that joining virtual LSR meeting 
is not for everyone. I was waiting and tried three times today for host 
approval to join which was not granted.

On Thu, Apr 2, 2020 at 11:00 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Robert,

This is unnecessary leakage of management plane into control plane.
The role of a routing protocol is to distribute: reachability (doh :-)) and any 
additional data that could influence routing decision wrt reachability.
There are precedences of using IGP’s for different tasks, e.g. RFC 5088 and 
similar, however should we do it again?

Specifically to use case described - I really don’t see how this information 
would be used in routing decisions (PCE computation). Moreover, if the end-goal 
is to build a connected graph of the devices that have a coherent iFIT feature 
set it would require reoptimization on every change and quite complex 
computation logic (talking SR - on top of regular constrains, MSD, etc).I’d 
also think that there’s mandatory configuration of name-spaces and features 
supported, in other words - autodiscovery is meaningless, it would still 
require as per device configuration (hello YANG). Most of telemetry solutions 
are designed to pass thought nodes that don’t support it transparently, so the 
real requirement is really to know the sink-node (the one that is egress of the 
telemetry domain and must remove all additional encapsulations).

As to the last point - we already have a kitchen-sink routing protocol  ;-)

Cheers,
Jeff
On Apr 2, 2020, 6:10 AM -0700, Robert Raszuk 
mailto:rob...@raszuk.net>>, wrote:


Hi Les,

Ok very well.

So till this draft provides a text or reference to some other document how IGPs 
may use inband telemetry data for real path selection it does not fit to LSR 
charter. Fair.

Hi Chris,

I am afraid we are looking at this from completely different perspectives.

I consider this data to be a necessity for routing and you simply treat it as 
some opaque telemetry. If we would think of it in the latter sense sure you 
would be right. IGP is not a configuration push protocol. Sufficient to observe 
how BGP became one :)

Many thx,
R.


On Thu, Apr 2, 2020 at 8:46 AM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Robert -

First, +1 to what Chris has said.

There is nothing in the lfit-capability draft that defines any information that 
can be used by IGPs to do what you suggest.
Perhaps it is possible that information gleaned via a telemetry application 
could be used by the IGPs to do something like what you suggest - but this 
draft is not discussing/defining that. It is simply proposing to advertise 
information about the capabilities of the lfit application on a given node..

   Les

> -Original Messag

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

[Tianran Zhou]

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:ginsb...@cisco.com] 
Sent: Wednesday, April 1, 2020 1:47 PM
To: Tianran Zhou ; Christian Hopps 
Cc: wangyali ; lsr@ietf.org
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 
> Sent: Tuesday, March 31, 2020 7:53 PM
> To: Christian Hopps 
> Cc: wangyali ; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org
> 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:cho...@chopps.org]
> Sent: Wednesday, April 1, 2020 10:00 AM
> To: Tianran Zhou 
> Cc: Christian Hopps ; wangyali 
> ; Les Ginsberg (ginsberg) ; 
> lsr@ietf.org
> 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 
> 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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Tianran Zhou]

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

Cheers,
Tianran

-Original Message-
From: Christian Hopps [mailto:cho...@chopps.org] 
Sent: Wednesday, April 1, 2020 10:00 AM
To: Tianran Zhou 
Cc: Christian Hopps ; wangyali ; Les 
Ginsberg (ginsberg) ; lsr@ietf.org
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  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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Tianran Zhou]

Hi Chris,

Please see in line.

Thanks,
Tianran

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



> On Mar 31, 2020, at 6:31 AM, wangyali  wrote:
> 
> 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".

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.

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.

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.

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.

> 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.

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.

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]

> 
> Best regards,
> Yali
> 
> 
> -邮件原件-
> 发件人: Christian Hopps [mailto:cho...@chopps.org] 
> 发送时间: 2020年3月30日 17:48
> 收件人: wangyali 
> 抄送: Christian Hopps ; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org
> 主题: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
> 
> 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  wrote:
>> 
>> 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 adde