[Lsr] LSR IETF 108 agenda posted

[Yingzhen Qu]

Hi all,

The draft agenda has been posted:
https://datatracker.ietf.org/meeting/108/materials/agenda-108-lsr-00.html

Please let me know if you have any questions or if we missed anything.

Presenters,

We have a packed schedule, so please prepare your presentation accordingly.
Please email me your slides when ready.

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

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

Re: [Lsr] Request WG adoption of TTZ

[Les Ginsberg (ginsberg)]

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



I actually think not  having more configuration across the network to enable a 
new feature is more useful even if

you don't do this operation every single day (especially if you want to roll 
back).





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.



Agree in general.



I would say this is no more complex than what has been adopted already or the 
slew of proposals we have been seeing here.



I too think as some other said we should have ideally adopted only one proposal 
by merging whatever possible.

As  that is not the case and 2 parallel proposals have already been accepted as 
WG experimental track, and given the interest/support on this particular topic

I would think it's reasonable to continue this experiment in IS-IS too as is 
done in OSPF.



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.

You are right, of course. IS-IS TTZ draft focuses

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

[Les Ginsberg (ginsberg)]

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  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.  An ingress router cannot insert IFIT-Data-Fields for

>packets going into a path unless an egress router has indicated via

>signaling that it has the capability to process IFIT-Data-Fields.  In

>addition, such advertisements would be useful for ingress routers to

>gather each router's IFIT capability for achieving the computation of

>Traffic Engineering (TE) paths or loose TE paths that be able to

>fulfill the visibility of on-path OAM data.

>

>

>

>

>

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

>

> The IETF Secretariat

>

>

> ___

> 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] Request WG adoption of TTZ

[Huaimo Chen]

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  on behalf of Uma Chunduri 

Sent: Wednesday, July 15, 2020 1:38 PM
To: Acee Lindem (acee) 
Cc: 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 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.



I actually think not  having more configuration across the network to enable a 
new feature is more useful even if

you don't do this operation every single day (especially if you want to roll 
back).





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.



Agree in general.



I would say this is no more complex than what has been adopted already or the 
slew of proposals we have been seeing here.



I too think as some other said we should have ideally adopted only one proposal 
by merging whatever possible.

As  that is not the case and 2 parallel proposals have already been accepted as 
WG experimental track, and given the interest/support on this particular topic

I would think it's reasonable to continue this experiment in IS-IS too as is 
done in OSPF.



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.

You are right, of course. IS-IS TTZ draft focuses on abstracting a zone (i.e., 
block) of an IS-IS area to a single node.

RFC 8099 is for abstracting a zone of an OSPF area to its edges full mesh.  So, 
afais, IS-IS TTZ is much better than RFC 8099 regarding improving network 
scalability.


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.

Thanks for pointing this;


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.

I would leave this to folks who want to deploy, if these advantages matter for 
them or not matter much.

Thank you!

--
Uma C.




Thanks,
Acee





--

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

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

[wangyali]

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 ; wangyali ; 
Huanan Chen ; Liumin (Lucy) 
; Ran Pang ; Liumin (Lucy) 

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.  An ingress router cannot insert IFIT-Data-Fields for
   packets going into a path unless an egress router has indicated via
   signaling that it has the capability to process IFIT-Data-Fields.  In
   addition, such advertisements would be useful for ingress routers to
   gather each router's IFIT capability for achieving the computation of
   Traffic Engineering (TE) paths or loose TE paths that be able to
   fulfill the visibility of on-path OAM data.



  


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.

The IETF Secretariat


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

Re: [Lsr] Request WG adoption of TTZ

[Christian Hopps]

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

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

[Henk Smit]

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