Re: [Lsr] Request WG adoption of TTZ

2020-07-17 Thread tony . li

Hi Huaimo,

> > “reducing the service interruption, making operations to be simple, and 
> so on”
>  does not require introduction of zones.  We can already do so using areas – 
> including merging/splitting of an area.
> 
> [HC]: Smooth merging/splitting of an area seems not reduce the service 
> interruption while Area Proxy is abstracting an existing IS-IS area to a 
> single node because the adjacency ups and downs. IS-IS TTZ seems reduce the 
> service interruption while it is abstracting a zone to a single node since it 
> provides a smooth transferring from a zone to the single node. In addition, 
> operations on IS-IS TTZ for abstracting a zone to a single node seems simpler 
> than creating a new L1 area (through merging/splitting of an area in some 
> cases) and abstracting the L1 area to a single node.
> 
> > Until you demonstrate something compelling which cannot be done with an 
> > area but can be done with a zone, I simply do not see why we need to 
> > introduce zones to the protocol..
> 
> [HC]: It seems that “reducing the service interruption, making operations to 
> be simpler" provided by IS-IS TTZ with a zone should be compelling enough.
> 


My apologies if this comes off as too preachy, but perhaps it will help if we 
are a bit more explicit about out thinking in case language is gettiing in the 
way. 


Engineering is all about trade-offs. With everything that we design there are 
benefits (hopefully) and costs (hopefully obvious). In any design, we want the 
benefits to outweigh the costs. Unfortunately, the evaluation of those benefits 
and costs are subjective. 

You’ve just seen Area Proxy go through a major revision because some of us felt 
that the costs (a couple of extra TLV code points) were too high.  Some of us 
disagree. ;-)

No one is suggesting that the zone concept has no value. No one is saying that 
smooth transitions have no value. It’s very clear that they do.  If we could do 
that with zero costs, we certainly would. However, the costs are non-zero in 
additional complexity and additional code.

What we’re trying to tell you is that in our humble opnion, the tradeoff isn’t 
in favor of TTZ. The costs are higher than the benefits.

There is no definitive right answer in subjective situations. We, as a 
community, have to come to rough consensus. Frequently to get there, there have 
to be compromises and tough decisions.

Regards,
Tony

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


Re: [Lsr] Request WG adoption of TTZ

2020-07-17 Thread Huaimo Chen
Hi Les,


> “reducing the service interruption, making operations to be simple, and 
so on”

 does not require introduction of zones.  We can already do so using areas – 
including merging/splitting of an area.


[HC]: Smooth merging/splitting of an area seems not reduce the service 
interruption while Area Proxy is abstracting an existing IS-IS area to a single 
node because the adjacency ups and downs. IS-IS TTZ seems reduce the service 
interruption while it is abstracting a zone to a single node since it provides 
a smooth transferring from a zone to the single node. In addition, operations 
on IS-IS TTZ for abstracting a zone to a single node seems simpler than 
creating a new L1 area (through merging/splitting of an area in some cases) and 
abstracting the L1 area to a single node.

> Until you demonstrate something compelling which cannot be done with an area 
> but can be done with a zone, I simply do not see why we need to introduce 
> zones to the protocol.

[HC]: It seems that “reducing the service interruption, making operations to be 
simpler" provided by IS-IS TTZ with a zone should be compelling enough.

Best Regards,
Huaimo

From: Les Ginsberg (ginsberg) 
Sent: Thursday, July 16, 2020 5:39 PM
To: Huaimo Chen ; Acee Lindem (acee) 

Cc: lsr@ietf.org 
Subject: RE: [Lsr] Request WG adoption of TTZ


Huaimo –



I am not going to comment on the history issues – though I understand why that 
is of significance to you.



Otherwise, I don’t think you are appreciating the key point many of us are 
making – which is that we do not need to introduce a new concept “zone” (subset 
of an area).

It is sufficient to operate on an area.



  “reducing the service interruption, making operations to be simple, and 
so on”



does not require introduction of zones.  We can already do so using areas – 
including merging/splitting of an area.



The argument then against moving forward with both Area Proxy and TTZ is that 
they are redundant.



Until you demonstrate something compelling which cannot be done with an area 
but can be done with a zone, I simply do not see why we need to introduce zones 
to the protocol.



Les







From: Lsr  On Behalf Of Huaimo Chen
Sent: Thursday, July 16, 2020 12:16 PM
To: Acee Lindem (acee) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Acee,



> Conversely, now that the IS-IS TTZ has adopted the Area Proxy mechanisms of 
> having an Area/Zone leader generate a single LSP representing the Area/Zone, 
> the two proposals are very similar.



[HC]:  It looks like the other way around. In 2013, IS-IS TTZ .00 draft 
describes the mechanism of having a Zone DR (called TTZ-DR) to generate a 
single LSP for representing the single node abstracted from the Zone. DR and 
Leader are just two different names of the same node. In 2018, Area Proxy .00 
draft presents the mechanism of having an Area leader to generate a single LSP 
representing the node abstracted from the Area. There are some big differences 
between IS-IS TTZ and Area Proxy even though they are similar.



>I think that the two proposals that have already been adopted as experimental 
>are VERY different in the way they solve the problem of better LSDB 
>scalability across an IS-IS routing domain.



[HC]: The three proposals (the two adopted as experimental recently and IS-IS 
TTZ) are all very different even though they solve the same problem for better 
LSDB scalability. It is would be reasonable and beneficial to allow IS-IS TTZ 
to move forward also as experimental.



>I agree with Henk, Les, and John that the purported advantages of TTZ are not 
>required. These advantages being arbitrary abstraction boundaries and a 
>description of the transition mechanisms.



[HC]: It seems that reducing the service interruption, making operations to be 
simple, and so on are expected by users in general.



Best Regards,

Huaimo



From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Uma 
Chunduri mailto:umac.i...@gmail.com>>
Sent: Wednesday, July 15, 2020 1:38 PM
To: Acee Lindem (acee) mailto:a...@cisco.com>>
Cc: lsr@ietf.org mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Request WG adoption of TTZ



Acee,



In-line ..



On Wed, Jul 15, 2020 at 10:14 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

Speaking as WG member…



See inline.



From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Uma 
Chunduri mailto:umac.i...@gmail.com>>
Date: Wednesday, July 15, 2020 at 12:52 PM
To: Henk Smit mailto:henk.i...@xs4all.nl>>
Cc: "l...@ietf...org" mailto:lsr@ietf.org>>, 
Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Subject: Re: [Lsr] Request WG adoption of TTZ







On Wed, Jul 15, 2020 at 5:22 AM Henk Smit 
mailto:henk.i...@xs4all.nl>> wrote:

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 

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

2020-07-17 Thread 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=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
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] 代表 wangyali 
[wangyal...@huawei.com]
发送时间: 2020年7月17日 20:19
收件人: Les Ginsberg (ginsberg); 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
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

> 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:  
> internet-dra...@ietf.org 
> [mailto:internet-dra...@ietf.org]

> Sent: Monday, July 13, 2020 9:15 PM

> To: Tianran Zhou 
> 

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

2020-07-17 Thread Les Ginsberg (ginsberg)
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 months 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=5GdFCy7zg8eCIGvQZpmAbOtrTjQ

   Les


From: Lizhenbin 
Sent: Friday, July 17, 2020 6:12 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Cc: wangyali 
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] 代表 wangyali [wangyal...@huawei.com]
发送时间: 2020年7月17日 20:19
收件人: Les Ginsberg (ginsberg); 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
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

> 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: internet-dra...@ietf.org 
> [mailto:internet-dra...@ietf.org]

> Sent: Monday, July 13, 2020 9:15 PM

> To: Tianran Zhou mailto:zhoutian...@huawei.com>>; 
> wangyali

> mailto:wangyal...@huawei.com>>; Huanan Chen 
> mailto:chenhu...@chinatelecom.cn>>;

> Liumin (Lucy) mailto:lucy.liu...@huawei.com>>; Ran 
> Pang

> mailto:pang...@chinaunicom.cn>>; Liumin (Lucy) 
> mailto:lucy.liu...@huawei.com>>

> Subject: New Version Notification for draft-wang-lsr-igp-extensions-ifit-

> 00.txt

>

>

> A new version of I-D, draft-wang-lsr-igp-extensions-ifit-00.txt

> has been successfully submitted by Yali Wang and posted to the IETF

> repository.

>

> Name:   draft-wang-lsr-igp-extensions-ifit

> Revision:   

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

2020-07-17 Thread Lizhenbin
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] 代表 wangyali [wangyal...@huawei.com]
发送时间: 2020年7月17日 20:19
收件人: Les Ginsberg (ginsberg); 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 ; 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

> 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: internet-dra...@ietf.org 
> [mailto:internet-dra...@ietf.org]

> Sent: Monday, July 13, 2020 9:15 PM

> To: Tianran Zhou mailto:zhoutian...@huawei.com>>; 
> wangyali

> mailto:wangyal...@huawei.com>>; Huanan Chen 
> mailto:chenhu...@chinatelecom.cn>>;

> Liumin (Lucy) mailto:lucy.liu...@huawei.com>>; Ran 
> Pang

> mailto:pang...@chinaunicom.cn>>; Liumin (Lucy) 
> mailto:lucy.liu...@huawei.com>>

> Subject: New Version Notification for draft-wang-lsr-igp-extensions-ifit-

> 00.txt

>

>

> A new version of I-D, draft-wang-lsr-igp-extensions-ifit-00.txt

> has been successfully submitted by Yali Wang and posted to the IETF

> repository.

>

> Name:   draft-wang-lsr-igp-extensions-ifit

> Revision:  00

> Title:  IGP Extensions for In-situ Flow Information Telemetry 
> (IFIT)

> Capability Advertisement

> Document date:2020-07-12

> Group:  Individual Submission

> Pages:   12

> URL:
> https://www.ietf.org/internet-drafts/draft-wang-lsr-igp-

> extensions-ifit-00.txt

> Status: 
> https://datatracker.ietf.org/doc/draft-wang-lsr-igp-extensions-

> 

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

2020-07-17 Thread wangyali
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 ; 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

> 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: internet-dra...@ietf.org 
> [mailto:internet-dra...@ietf.org]

> Sent: Monday, July 13, 2020 9:15 PM

> To: Tianran Zhou mailto:zhoutian...@huawei.com>>; 
> wangyali

> mailto:wangyal...@huawei.com>>; Huanan Chen 
> mailto:chenhu...@chinatelecom.cn>>;

> Liumin (Lucy) mailto:lucy.liu...@huawei.com>>; Ran 
> Pang

> mailto:pang...@chinaunicom.cn>>; Liumin (Lucy) 
> mailto:lucy.liu...@huawei.com>>

> Subject: New Version Notification for draft-wang-lsr-igp-extensions-ifit-

> 00.txt

>

>

> A new version of I-D, draft-wang-lsr-igp-extensions-ifit-00.txt

> has been successfully submitted by Yali Wang and posted to the IETF

> repository.

>

> Name:   draft-wang-lsr-igp-extensions-ifit

> Revision:  00

> Title:  IGP Extensions for In-situ Flow Information Telemetry 
> (IFIT)

> Capability Advertisement

> Document date:2020-07-12

> Group:  Individual Submission

> Pages:   12

> URL:
> https://www.ietf.org/internet-drafts/draft-wang-lsr-igp-

> extensions-ifit-00.txt

> Status: 
> https://datatracker.ietf.org/doc/draft-wang-lsr-igp-extensions-

> ifit/

> Htmlized:   
> https://tools.ietf.org/html/draft-wang-lsr-igp-extensions-ifit-00

> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-igp-

> extensions-ifit

>

>

> Abstract:

>This document extends Node and Link Attribute TLVs to Interior

>Gateway Protocols (IGP) to advertise supported In-situ Flow

>Information Telemetry (IFIT) capabilities at node and/or link

>granularity.  

Re: [Lsr] Request WG adoption of TTZ

2020-07-17 Thread Christian Hopps


> On Jul 16, 2020, at 11:18 PM, Tianran Zhou  wrote:
> 
> 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.

[As a general IETF participant]

I believe we all would like this, but real-world dynamics impose none-the-less.

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

[chair hat] We always prefer to have this. We do not always get it, 
unfortunately.

Thanks,
Chris.

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