Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Acee,

Thank you very much for your comments.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo

From: Acee Lindem (acee) 
Sent: Tuesday, July 7, 2020 4:33 PM
To: Huaimo Chen ; Christian Hopps 

Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ


Speaking as WG member:



Hi Huaimo,



Independent of the major issue with Area Proxy differentiation, I have a couple 
other issues that I didn’t want to include in the same Email thread.



  1.  You can’t describe IS-IS protocol details and then just include OSPF 
encodings and expect the readers to intuit the OSPF specific details. These 
area abstraction drafts modify basic protocol mechanisms and OSPF details would 
be better specified in an update to RFC 8099 then just adding encodings to this 
IS-IS TTZ draft.
[HC]: We will add more OSPF details. I am OK for OSPF details to be in an 
update to RFC 8099.
  2.  The draft uses the term IS-IS Pseudo-node yet this is defined in IS-IS as 
a specific LSP to represent a multi-access network. I don’t know if the usage 
of the terminology was meant to differentiate the mechanisms from Area Proxy 
but I find the repurposing of the term pseudo-node in the context of IS-IS very 
confusing.
[HC]: We will change it to another term.
  3.  The document keeps referring to  “edges full mess” and I believe you mean 
“edges full mesh”.

[HC]: You are right. It should be "edges full mesh".



Thanks,

Acee



From: Lsr  on behalf of Huaimo Chen 

Date: Tuesday, July 7, 2020 at 12:01 PM
To: Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Chris,



Thank you very much for your questions.

My answers/explanations are inline below with prefix [HC].



Best Regards,

Huaimo



From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?



[HC]: There are some differences even though they looks similar.

At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.

Area Proxy abstracts an existing area to a single pseudo node.

TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.

An area is different from a zone in general.



Secondly, the ways in which they are applied to an area for scalability are 
different.

When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.

These differences will produce different user experiences.

For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.

For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.



Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.



BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.

In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.



There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?



[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for 
the new solution are defined in the document.

Thanks,
Chris.
[chair hat]


> On Jun 18, 2020, at 11:38 PM, Huaimo Chen  wrote:
>
> Hi Chris and Acee, and everyone,
>
>
>
> I would like to request working group adoption of "Topology-Transparent 
> Zone"
>
> (TTZ for short) 
> https://datatracker.ietf.org/doc/draft-chen-isis-ttz/

Re: [Lsr] Request WG adoption of TTZ

[tony . li]

Hi Aijun,

Subdividing an existing area is entirely possible with Area Proxy.  You just 
have to split the area and then apply Area Proxy.  ;-)

Tony


> On Jul 7, 2020, at 7:36 PM, Aijun Wang  wrote:
> 
> Hi, Les:
> 
> Using TTZ to sub divide the existing area seems more attractive. It seems TTZ 
> can accomplish all the functions Area Proxy can provide, but area proxy can’t 
> cover the scenarios that TTZ can solve.
> Why don’t we prefer to TTZ?
> 
> Aijun Wang
> China Telecom
> 
>> On Jul 8, 2020, at 08:53, Les Ginsberg (ginsberg) 
>>  wrote:
>> 
>> 
>> Huaimo –
>>  
>> Sorry for ascribing area merging properties to zones... As the base protocol 
>> mechanism in IS-IS can be used both to split and merge areas I was thinking 
>> zones could be used the same way, but I see on closer reading that you have 
>> restricted a zone to be a subset of an area (which could also be the area 
>> itself).
>>  
>> I think this does not detract from the main point I am trying to make – 
>> which is that unless there is reason to believe that operators would prefer 
>> to use zones rather than split an area (when necessary), this does not serve 
>> as a significant differentiator between TTZ and area-proxy.
>> I think you need a more compelling differentiator to justify proceeding with 
>> both drafts.
>>  
>> In this regard I am agreeing with the points made by other folks (notably 
>> Chris and Tony), that the introduction of zones may well be adding unneeded 
>> complexity.
>>  
>> Just my opinion of course…
>>  
>>Les
>>  
>>  
>> From: Huaimo Chen  
>> Sent: Tuesday, July 07, 2020 12:42 PM
>> To: Les Ginsberg (ginsberg) ; Christian Hopps 
>> 
>> Cc: lsr@ietf.org; lsr-cha...@ietf.org
>> Subject: Re: [Lsr] Request WG adoption of TTZ
>>  
>> Hi Les,
>>  
>> > I think what you are highlighting is that w TTZ an operator could apply 
>> > the solution to a subset of an area (which you call a zone) – or to a set 
>> > of areas (which you also call a zone). This presumes that it is expected 
>> > that a customer would want to operate in a mode where the interconnections 
>> > do not follow area boundaries. It isn’t clear to me that this is a 
>> > compelling requirement. If there are operators who feel otherwise I would 
>> > appreciate them speaking up and educating us on the requirements.
>>  
>> How do you get that TTZ could be used to a set of areas (which you also call 
>> a zone)? 
>> A zone is a piece or block of an area.  In an area, we can define one or 
>> more zones. All these zones are within this area. For a set of areas, we can 
>> define one or more zones in each of these areas.. But we can not define a 
>> zone crossing multiple areas.
>>  
>> Best Regards,
>> Huaimo
>> From: Les Ginsberg (ginsberg) > >
>> Sent: Tuesday, July 7, 2020 3:29 PM
>> To: Huaimo Chen > >; Christian Hopps > >
>> Cc: lsr@ietf.org  mailto:lsr@ietf.org>>; 
>> lsr-cha...@ietf.org  > >
>> Subject: RE: [Lsr] Request WG adoption of TTZ
>>  
>> Huaimo –
>>  
>> I think what you are highlighting is that w TTZ an operator could apply the 
>> solution to a subset of an area (which you call a zone) – or to a set of 
>> areas (which you also call a zone). This presumes that it is expected that a 
>> customer would want to operate in a mode where the interconnections do not 
>> follow area boundaries. It isn’t clear to me that this is a compelling 
>> requirement. If there are operators who feel otherwise I would appreciate 
>> them speaking up and educating us on the requirements.
>>  
>> Absent that, it seems if you want to differentiate TTZ from Area-Proxy you 
>> should be focusing on things other than the flexibility of zones over areas.
>>  
>>Les
>>  
>>  
>> From: Huaimo Chen > > 
>> Sent: Tuesday, July 07, 2020 11:13 AM
>> To: Les Ginsberg (ginsberg) > >; Christian Hopps > >
>> Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
>> 
>> Subject: Re: [Lsr] Request WG adoption of TTZ
>>  
>> Hi Les,
>>  
>> Thank you very much for your comments.
>>  
>> There are still some differences between Area Proxy and TTZ regarding to 
>> IS-IS with smooth area splitting and merging. 
>>  
>> At first, the operations/configurations are different. 
>> Using Area Proxy, two steps are needed. One step is to split an IS-IS 
>> area to multiple areas through some configurations. The other step is to 
>> abstract an existing IS-IS area to a single pseudo node through another set 
>> of configurations. 
>> Using TTZ, only one step is needed, which is to abstract a zone to a 
>> single pseudo node.
>> From operations' point of view, TTZ seems simpler.
>>  
>> Secondly, TTZ provides smooth transferring between a zone and its single 
>> ps

Re: [Lsr] Request WG adoption of TTZ

[Aijun Wang]

Hi, Les:

Using TTZ to sub divide the existing area seems more attractive. It seems TTZ 
can accomplish all the functions Area Proxy can provide, but area proxy can’t 
cover the scenarios that TTZ can solve.
Why don’t we prefer to TTZ?

Aijun Wang
China Telecom

> On Jul 8, 2020, at 08:53, Les Ginsberg (ginsberg) 
>  wrote:
> 
> 
> Huaimo –
>  
> Sorry for ascribing area merging properties to zones.. As the base protocol 
> mechanism in IS-IS can be used both to split and merge areas I was thinking 
> zones could be used the same way, but I see on closer reading that you have 
> restricted a zone to be a subset of an area (which could also be the area 
> itself).
>  
> I think this does not detract from the main point I am trying to make – which 
> is that unless there is reason to believe that operators would prefer to use 
> zones rather than split an area (when necessary), this does not serve as a 
> significant differentiator between TTZ and area-proxy.
> I think you need a more compelling differentiator to justify proceeding with 
> both drafts.
>  
> In this regard I am agreeing with the points made by other folks (notably 
> Chris and Tony), that the introduction of zones may well be adding unneeded 
> complexity.
>  
> Just my opinion of course…
>  
>Les
>  
>  
> From: Huaimo Chen  
> Sent: Tuesday, July 07, 2020 12:42 PM
> To: Les Ginsberg (ginsberg) ; Christian Hopps 
> 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
>  
> Hi Les,
>  
> > I think what you are highlighting is that w TTZ an operator could apply the 
> > solution to a subset of an area (which you call a zone) – or to a set of 
> > areas (which you also call a zone). This presumes that it is expected that 
> > a customer would want to operate in a mode where the interconnections do 
> > not follow area boundaries. It isn’t clear to me that this is a compelling 
> > requirement. If there are operators who feel otherwise I would appreciate 
> > them speaking up and educating us on the requirements.
>  
> How do you get that TTZ could be used to a set of areas (which you also call 
> a zone)? 
> A zone is a piece or block of an area.  In an area, we can define one or more 
> zones. All these zones are within this area. For a set of areas, we can 
> define one or more zones in each of these areas.. But we can not define a 
> zone crossing multiple areas.
>  
> Best Regards,
> Huaimo
> From: Les Ginsberg (ginsberg) 
> Sent: Tuesday, July 7, 2020 3:29 PM
> To: Huaimo Chen ; Christian Hopps 
> 
> Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
> Subject: RE: [Lsr] Request WG adoption of TTZ
>  
> Huaimo –
>  
> I think what you are highlighting is that w TTZ an operator could apply the 
> solution to a subset of an area (which you call a zone) – or to a set of 
> areas (which you also call a zone). This presumes that it is expected that a 
> customer would want to operate in a mode where the interconnections do not 
> follow area boundaries. It isn’t clear to me that this is a compelling 
> requirement. If there are operators who feel otherwise I would appreciate 
> them speaking up and educating us on the requirements.
>  
> Absent that, it seems if you want to differentiate TTZ from Area-Proxy you 
> should be focusing on things other than the flexibility of zones over areas..
>  
>Les
>  
>  
> From: Huaimo Chen  
> Sent: Tuesday, July 07, 2020 11:13 AM
> To: Les Ginsberg (ginsberg) ; Christian Hopps 
> 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
>  
> Hi Les,
>  
> Thank you very much for your comments.
>  
> There are still some differences between Area Proxy and TTZ regarding to 
> IS-IS with smooth area splitting and merging. 
>  
> At first, the operations/configurations are different. 
> Using Area Proxy, two steps are needed. One step is to split an IS-IS 
> area to multiple areas through some configurations. The other step is to 
> abstract an existing IS-IS area to a single pseudo node through another set 
> of configurations. 
> Using TTZ, only one step is needed, which is to abstract a zone to a 
> single pseudo node.
> From operations' point of view, TTZ seems simpler.
>  
> Secondly, TTZ provides smooth transferring between a zone and its single 
> pseudo node. That is that a zone can be smoothly transferred to a single 
> pseudo node, and the pseudo node can be smoothly rolled back to the zone.  
> Smooth IS-IS area splitting and merging can not be used for abstracting an 
> existing IS-IS area to a single pseudo node in Area Proxy. 
>  
> Best Regards,
> Huaimo
> From: Les Ginsberg (ginsberg) 
> Sent: Tuesday, July 7, 2020 12:52 PM
> To: Huaimo Chen ; Christian Hopps 
> 
> Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
> Subject: RE: [Lsr] Request WG adoption of TTZ
>  
> Huaimo –
>  
> In regards to merging/splitting areas, IS-IS base protocol provides a way to 
> do this hitlessly (this was discussed some years ag

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Chris,

Thank you very much for your comments.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo

From: Christian Hopps
Sent: Tuesday, July 7, 2020 9:21 PM
To: Huaimo Chen
Cc: Christian Hopps; Acee Lindem (acee); lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



> On Jul 7, 2020, at 8:42 PM, Huaimo Chen  wrote:
>
> Hi Acee and Chris,
>
> Thank you very much for your comments.
>
> > I agree with Chris – when the IS-IS TTZ draft adopted the approach of 
> > having the area/zone leader originate a single LSP abstracting the 
> > zone/area last Oct, the main differentiation between the two approaches is 
> > the zone/area terminology. The other substantive difference is the fact 
> > that the Area Proxy draft includes a much more comprehensive specification 
> > of the protocol mechanisms required for area/zone abstraction. I have no 
> > doubt that the Area Proxy details could also be amended from area proxy to 
> > TTZ, but that is exactly Chris’s point with which I agree – there 
> > essentially isn’t a difference.
>
> Thanks,
> Acee
>
> There are really some differences between TTZ and Area Proxy, which are 
> listed below for OSPF and IS-IS:
> Differences between OSPF TTZ and OSPF Area Proxy (note: assume that OSPF 
> Area Proxy is similar to IS-IS Area Proxy even though OSPF Area Proxy is not 
> defined in the Area Proxy draft) include:
> 1).  It seems that OSPF Area Proxy can not be amended to OSPF TTZ. OSPF 
> TTZ abstracts a zone to a single pseudo node. This abstraction is supported 
> by the extensions to OSPF, and some of these extensions are not defined in 
> OSPF Area Proxy. For example, the extensions for the edge nodes of the zone 
> are not defined in OSPF Area Proxy.
> 2).  OSPF Area Proxy abstracts an existing OSPF area to a single pseudo 
> node.  OSPF TTZ abstracts a zone to a single pseudo node. A zone is a piece 
> or block of an OSPF area. An OSPF area is different from a zone in general.
> 3). The ways in which they are applied to an OSPF area for scalability 
> are different. When an OSPF area becomes bigger and bigger, we may have 
> scalability issues. Using OSPF TTZ, we can abstract one or a few zones in the 
> OSPF area to one or few pseudo nodes smoothly without any interface down. 
> Using OSPF Area Proxy, we need split the existing OSPF area into multiple 
> OSPF areas, and then abstract one or a few OSPF areas to one or few pseudo 
> nodes. Some people may like the one step operation in OSPF TTZ. Others may 
> like the two step operations in OSPF Area Proxy.
> 4). The user experiences are different. For splitting an existing OSPF 
> area into multiple OSPF areas, users may need put more efforts since it 
> causes service interruptions in general. While splitting an OSPF area into 
> multiple OSPF areas, the area numbers configured on some interfaces will be 
> changed and each of these interfaces will be down with its old area number 
> and then up with its new area number.. These interface downs and ups will 
> cause service interruptions in general.. For defining zones in an OSPF area, 
> users may need less efforts since abstracting a zone to a single pseudo node 
> is smooth without any interface down.
> 5). OSPF TTZ provides smooth transferring between a zone and its single 
> pseudo node. That is that a zone can be smoothly transferred to a single 
> pseudo node, and the pseudo node can be smoothly rolled back to the zone..

I think the fact that the above is mixing terms (e.g., OSPF Area Proxy, which 
doesn't exist, and OSPF doesn't have pseudo-nodes) is really highlighting the 
fact that, as Acee pointed out, perhaps its not a good idea to be trying to 
update/modify OSPF TTZ (RFC8099), and at the same time introduce something new 
to IS-IS. It's very confusing right now to have these things all mixed together 
like this.

[HC]: OSPF Area Proxy does not exist and it seems that Tony is not interested 
in it. In this case, I think that abstracting a zone to a single node should be 
moved forward.  It should extends RFC 8099, not update/modify RFC 8099.
For IS-IS TTZ, it just needs two new TLVs now, which can be reduced to one. It 
seems there is not much confusing. I think that it should be moved forward too.
For the terms such as pseudo nodes, they can be easily changed if they are not 
good.

Thanks,
Chris.
[As WG member]

>
> Differences between IS-IS TTZ and IS-IS Area Proxy are similar to
> the above 1). 2). 3). and 5) between OSPF TTZ and OSPF Area Proxy.
>
> Best Regards,
> Huaimo
> From: Acee Lindem (acee) 
> Sent: Tuesday, July 7, 2020 3:41 PM
> To: Huaimo Chen ; Christian Hopps 
> 
> Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
> Subject: Re: [Lsr] Request WG adoption of TTZ
>
> Speaking as WG member:
>
> I agree with Chris – when the IS-IS TTZ draft adopted the approach of having 
> the area/zone leader originate a singl

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Tony and Chris,

Thank you very much for your comments.

Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.
This strikes me as the important difference from area proxy. It certainly adds 
complexity to things, I wonder if it's worth it?
It is worth it because it reduces service interruption and improves 
customer experiences.

When users plan to do these operations on a network, they will select a 
maintenance window. During this window, there should be minimum service traffic 
being transported in the network. However, there is still some live traffic in 
the network even during this window in general. If we do not provide smooth 
transferring between a zone/area and its single pseudo node, some live traffic 
will be lost even during this window while doing the transferring.

There are some challenges for providing smooth transferring between a zone 
and its single pseudo node. I believe that we will be able to have a good 
enough solution. We have had a prototype implementation of smooth transferring 
a zone to the zone edges' full mess in OSPF. The testing shows that a zone 
(block of an OSPF area) is smoothly transferred to its edges’ full mess without 
any routing disruptions.  In addition, we have spent lots of time and efforts 
on smooth transferring between a zone and its single pseudo node. Moreover, we 
may get suggestions from the experts in IETF, especially in LSR WG.

Best Regards,
Huaimo


From: Tony Li  on behalf of tony...@tony.li 

Sent: Tuesday, July 7, 2020 3:08 PM
To: Christian Hopps 
Cc: Huaimo Chen ; lsr@ietf.org ; 
lsr-cha...@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ

Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.

This strikes me as the important difference from area proxy. It certainly adds 
complexity to things, I wonder if it's worth it?


FWIW, we looked at this quite seriously a while ago. Turning abstraction on and 
off is simply not a daily occurrence. Doing it properly requires careful 
thought and planning.
Where are the boundaries? What prefixes will be advertised and with what 
metrics? How will the affect traffic flow?

The corner cases that happen when you are in this transition are large. We have 
to deal with the issue of the metrics that are abstracted away.  We chose to go 
down the path
of intra-area vs. inter-area metrics, exactly as OSPF does. But if you do this, 
then you have an issue: the metrics are different when abstraction is enabled 
or disabled and
different nodes will compute different paths depending on which LSPs have 
propagated to them. This seemed like a wonderful opportunity for forwarding 
loops. This
is especially problematic when abstraction is enabled, as there is now an 
entire area’s worth of LSPs that need to age out before you can be assured of 
consistency.
Yes, you can try to purge them, but purges aren’t the most reliable thing in 
the world.

Net net, we felt that the complexity exceeded the benefit. Yes, there is 
benefit there, but from the pragmatic viewpoint of making it work in 
production, the risks and costs seemed very high.
We expect that operators would want to make the change in a maintenance window 
anyway, and as long as you’re having a maintenance window, you might as well do 
things the
simpler way.

Regards,
Tony

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

Re: [Lsr] Request WG adoption of TTZ

[Christian Hopps]

> On Jul 7, 2020, at 8:42 PM, Huaimo Chen  wrote:
> 
> Hi Acee and Chris,
> 
> Thank you very much for your comments.
> 
> > I agree with Chris – when the IS-IS TTZ draft adopted the approach of 
> > having the area/zone leader originate a single LSP abstracting the 
> > zone/area last Oct, the main differentiation between the two approaches is 
> > the zone/area terminology. The other substantive difference is the fact 
> > that the Area Proxy draft includes a much more comprehensive specification 
> > of the protocol mechanisms required for area/zone abstraction. I have no 
> > doubt that the Area Proxy details could also be amended from area proxy to 
> > TTZ, but that is exactly Chris’s point with which I agree – there 
> > essentially isn’t a difference.
> 
> Thanks,
> Acee
> 
> There are really some differences between TTZ and Area Proxy, which are 
> listed below for OSPF and IS-IS:
> Differences between OSPF TTZ and OSPF Area Proxy (note: assume that OSPF 
> Area Proxy is similar to IS-IS Area Proxy even though OSPF Area Proxy is not 
> defined in the Area Proxy draft) include:
> 1).  It seems that OSPF Area Proxy can not be amended to OSPF TTZ. OSPF 
> TTZ abstracts a zone to a single pseudo node. This abstraction is supported 
> by the extensions to OSPF, and some of these extensions are not defined in 
> OSPF Area Proxy. For example, the extensions for the edge nodes of the zone 
> are not defined in OSPF Area Proxy.
> 2).  OSPF Area Proxy abstracts an existing OSPF area to a single pseudo 
> node.  OSPF TTZ abstracts a zone to a single pseudo node. A zone is a piece 
> or block of an OSPF area. An OSPF area is different from a zone in general.
> 3). The ways in which they are applied to an OSPF area for scalability 
> are different. When an OSPF area becomes bigger and bigger, we may have 
> scalability issues. Using OSPF TTZ, we can abstract one or a few zones in the 
> OSPF area to one or few pseudo nodes smoothly without any interface down. 
> Using OSPF Area Proxy, we need split the existing OSPF area into multiple 
> OSPF areas, and then abstract one or a few OSPF areas to one or few pseudo 
> nodes. Some people may like the one step operation in OSPF TTZ. Others may 
> like the two step operations in OSPF Area Proxy.
> 4). The user experiences are different. For splitting an existing OSPF 
> area into multiple OSPF areas, users may need put more efforts since it 
> causes service interruptions in general. While splitting an OSPF area into 
> multiple OSPF areas, the area numbers configured on some interfaces will be 
> changed and each of these interfaces will be down with its old area number 
> and then up with its new area number.. These interface downs and ups will 
> cause service interruptions in general.. For defining zones in an OSPF area, 
> users may need less efforts since abstracting a zone to a single pseudo node 
> is smooth without any interface down.
> 5). OSPF TTZ provides smooth transferring between a zone and its single 
> pseudo node. That is that a zone can be smoothly transferred to a single 
> pseudo node, and the pseudo node can be smoothly rolled back to the zone..

I think the fact that the above is mixing terms (e.g., OSPF Area Proxy, which 
doesn't exist, and OSPF doesn't have pseudo-nodes) is really highlighting the 
fact that, as Acee pointed out, perhaps its not a good idea to be trying to 
update/modify OSPF TTZ (RFC8099), and at the same time introduce something new 
to IS-IS. It's very confusing right now to have these things all mixed together 
like this.

Thanks,
Chris.
[As WG member]

> 
> Differences between IS-IS TTZ and IS-IS Area Proxy are similar to
> the above 1). 2). 3). and 5) between OSPF TTZ and OSPF Area Proxy.
> 
> Best Regards,
> Huaimo
> From: Acee Lindem (acee) 
> Sent: Tuesday, July 7, 2020 3:41 PM
> To: Huaimo Chen ; Christian Hopps 
> 
> Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> Speaking as WG member:
> 
> I agree with Chris – when the IS-IS TTZ draft adopted the approach of having 
> the area/zone leader originate a single LSP abstracting the zone/area last 
> Oct, the main differentiation between the two approaches is the zone/area 
> terminology. The other substantive difference is the fact that the Area Proxy 
> draft includes a much more comprehensive specification of the protocol 
> mechanisms required for area/zone abstraction. I have no doubt that the Area 
> Proxy details could also be amended from area proxy to TTZ, but that is 
> exactly Chris’s point with which I agree – there essentially isn’t a 
> difference.
> 
> Thanks,
> Acee
> From: Lsr  on behalf of Huaimo Chen 
> 
> Date: Tuesday, July 7, 2020 at 12:01 PM
> To: Christian Hopps 
> Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> Hi Chris,
> 
> Thank you very much for your questions.
> My answers/explanations are inline b

Re: [Lsr] Request WG adoption of TTZ

[Tony Li]

Hi Huaimo,

> Differences between OSPF TTZ and OSPF Area Proxy (note: assume that OSPF 
> Area Proxy is similar to IS-IS Area Proxy even though OSPF Area Proxy is not 
> defined in the Area Proxy draft) include:


That’s an unfortunate assumption.  We have not defined OSPF Area Proxy because 
it’s frankly well outside of our expertise.

The hierarchical structures of OSPF and IS-IS are intrinsically different.  
While legacy IS-IS allows L2 traffic to transit an L1L2 area, my understanding 
is that when OSPF traffic leaves Area 0, it won’t be coming 
back.  While I don’t particularly like this aspect of the OSPF architecture, 
it’s NOT what we were out to fix.  

So, please don’t assume anything about OSPF Area Proxy.  

Tony

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

Re: [Lsr] Request WG adoption of TTZ

[Les Ginsberg (ginsberg)]

Huaimo -

Sorry for ascribing area merging properties to zones. As the base protocol 
mechanism in IS-IS can be used both to split and merge areas I was thinking 
zones could be used the same way, but I see on closer reading that you have 
restricted a zone to be a subset of an area (which could also be the area 
itself).

I think this does not detract from the main point I am trying to make - which 
is that unless there is reason to believe that operators would prefer to use 
zones rather than split an area (when necessary), this does not serve as a 
significant differentiator between TTZ and area-proxy.
I think you need a more compelling differentiator to justify proceeding with 
both drafts.

In this regard I am agreeing with the points made by other folks (notably Chris 
and Tony), that the introduction of zones may well be adding unneeded 
complexity.

Just my opinion of course...

   Les


From: Huaimo Chen 
Sent: Tuesday, July 07, 2020 12:42 PM
To: Les Ginsberg (ginsberg) ; Christian Hopps 

Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Les,

> I think what you are highlighting is that w TTZ an operator could apply the 
> solution to a subset of an area (which you call a zone) - or to a set of 
> areas (which you also call a zone). This presumes that it is expected that a 
> customer would want to operate in a mode where the interconnections do not 
> follow area boundaries. It isn't clear to me that this is a compelling 
> requirement. If there are operators who feel otherwise I would appreciate 
> them speaking up and educating us on the requirements.

How do you get that TTZ could be used to a set of areas (which you also call a 
zone)?
A zone is a piece or block of an area.  In an area, we can define one or more 
zones. All these zones are within this area. For a set of areas, we can define 
one or more zones in each of these areas. But we can not define a zone crossing 
multiple areas.

Best Regards,
Huaimo

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, July 7, 2020 3:29 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org mailto:lsr@ietf.org>>; 
lsr-cha...@ietf.org 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] Request WG adoption of TTZ


Huaimo -



I think what you are highlighting is that w TTZ an operator could apply the 
solution to a subset of an area (which you call a zone) - or to a set of areas 
(which you also call a zone). This presumes that it is expected that a customer 
would want to operate in a mode where the interconnections do not follow area 
boundaries. It isn't clear to me that this is a compelling requirement. If 
there are operators who feel otherwise I would appreciate them speaking up and 
educating us on the requirements.



Absent that, it seems if you want to differentiate TTZ from Area-Proxy you 
should be focusing on things other than the flexibility of zones over areas..



   Les





From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Sent: Tuesday, July 07, 2020 11:13 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org; 
lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Les,



Thank you very much for your comments.



There are still some differences between Area Proxy and TTZ regarding to 
IS-IS with smooth area splitting and merging.



At first, the operations/configurations are different.

Using Area Proxy, two steps are needed. One step is to split an IS-IS area 
to multiple areas through some configurations. The other step is to abstract an 
existing IS-IS area to a single pseudo node through another set of 
configurations.

Using TTZ, only one step is needed, which is to abstract a zone to a single 
pseudo node.

From operations' point of view, TTZ seems simpler.



Secondly, TTZ provides smooth transferring between a zone and its single 
pseudo node. That is that a zone can be smoothly transferred to a single pseudo 
node, and the pseudo node can be smoothly rolled back to the zone.

Smooth IS-IS area splitting and merging can not be used for abstracting an 
existing IS-IS area to a single pseudo node in Area Proxy.



Best Regards,

Huaimo



From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, July 7, 2020 12:52 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org mailto:lsr@ietf.org>>; 
lsr-cha...@ietf.org 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] Request WG adoption of TTZ



Huaimo -



In regards to merging/splitting areas, IS-IS base protocol provides a way to do 
this hitlessly (this was discussed 

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Acee and Chris,

Thank you very much for your comments.


> I agree with Chris – when the IS-IS TTZ draft adopted the approach of having 
> the area/zone leader originate a single LSP abstracting the zone/area last 
> Oct, the main differentiation between the two approaches is the zone/area 
> terminology. The other substantive difference is the fact that the Area Proxy 
> draft includes a much more comprehensive specification of the protocol 
> mechanisms required for area/zone abstraction. I have no doubt that the Area 
> Proxy details could also be amended from area proxy to TTZ, but that is 
> exactly Chris’s point with which I agree – there essentially isn’t a 
> difference.



Thanks,

Acee


There are really some differences between TTZ and Area Proxy, which are 
listed below for OSPF and IS-IS:
Differences between OSPF TTZ and OSPF Area Proxy (note: assume that OSPF 
Area Proxy is similar to IS-IS Area Proxy even though OSPF Area Proxy is not 
defined in the Area Proxy draft) include:
1).  It seems that OSPF Area Proxy can not be amended to OSPF TTZ. OSPF TTZ 
abstracts a zone to a single pseudo node. This abstraction is supported by the 
extensions to OSPF, and some of these extensions are not defined in OSPF Area 
Proxy. For example, the extensions for the edge nodes of the zone are not 
defined in OSPF Area Proxy.
2).  OSPF Area Proxy abstracts an existing OSPF area to a single pseudo 
node.  OSPF TTZ abstracts a zone to a single pseudo node. A zone is a piece or 
block of an OSPF area. An OSPF area is different from a zone in general.
3). The ways in which they are applied to an OSPF area for scalability are 
different. When an OSPF area becomes bigger and bigger, we may have scalability 
issues. Using OSPF TTZ, we can abstract one or a few zones in the OSPF area to 
one or few pseudo nodes smoothly without any interface down. Using OSPF Area 
Proxy, we need split the existing OSPF area into multiple OSPF areas, and then 
abstract one or a few OSPF areas to one or few pseudo nodes. Some people may 
like the one step operation in OSPF TTZ. Others may like the two step 
operations in OSPF Area Proxy.
4). The user experiences are different. For splitting an existing OSPF area 
into multiple OSPF areas, users may need put more efforts since it causes 
service interruptions in general. While splitting an OSPF area into multiple 
OSPF areas, the area numbers configured on some interfaces will be changed and 
each of these interfaces will be down with its old area number and then up with 
its new area number. These interface downs and ups will cause service 
interruptions in general. For defining zones in an OSPF area, users may need 
less efforts since abstracting a zone to a single pseudo node is smooth without 
any interface down.
5). OSPF TTZ provides smooth transferring between a zone and its single 
pseudo node. That is that a zone can be smoothly transferred to a single pseudo 
node, and the pseudo node can be smoothly rolled back to the zone.

Differences between IS-IS TTZ and IS-IS Area Proxy are similar to
the above 1). 2). 3). and 5) between OSPF TTZ and OSPF Area Proxy.

Best Regards,
Huaimo

From: Acee Lindem (acee) 
Sent: Tuesday, July 7, 2020 3:41 PM
To: Huaimo Chen ; Christian Hopps 

Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ


Speaking as WG member:



I agree with Chris – when the IS-IS TTZ draft adopted the approach of having 
the area/zone leader originate a single LSP abstracting the zone/area last Oct, 
the main differentiation between the two approaches is the zone/area 
terminology. The other substantive difference is the fact that the Area Proxy 
draft includes a much more comprehensive specification of the protocol 
mechanisms required for area/zone abstraction. I have no doubt that the Area 
Proxy details could also be amended from area proxy to TTZ, but that is exactly 
Chris’s point with which I agree – there essentially isn’t a difference.



Thanks,
Acee

From: Lsr  on behalf of Huaimo Chen 

Date: Tuesday, July 7, 2020 at 12:01 PM
To: Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Chris,



Thank you very much for your questions.

My answers/explanations are inline below with prefix [HC].



Best Regards,

Huaimo



From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?



[HC]: There are some differences even though they looks similar.

At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.

Area Proxy abstracts an existing area to a single pseudo node.

TTZ abstracts a zone to a single pseudo n

[Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

[Amanda Baber via RT]

Peter, should we go ahead?

thanks,
Amanda

On Tue Jul 07 20:14:48 2020, a...@cisco.com wrote:
> Gunter is on vacation...
> Thanks,
> Acee
> 
> On 7/6/20, 1:14 PM, "Amanda Baber via RT" 
> wrote:
> 
> Hi Ketan, Peter,
> 
> I believe we're waiting for Gunter to approve as the remaining expert,
> but we can move ahead if Peter confirms that we don't need to wait.
> 
> Best regards,
> Amanda
> 
> On Mon Jul 06 03:46:02 2020, ket...@cisco.com wrote:
> > Hi Amanda/All,
> >
> > I thought that there was an agreement to assign bit 0x0010 for
> > draft-ietf-lsr-ospf-bfd-strict-mode and 0x0020 for draft-ietf-
> > lsr-
> > dynamic-flooding?
> >
> > Thanks,
> > Ketan
> >
> > -Original Message-
> >  From: Amanda Baber via RT 
> > Sent: 04 July 2020 07:53
> > To: Acee Lindem (acee) 
> > Cc: Peter Psenak (ppsenak) ; mraj...@juniper.net;
> > lsr@ietf.org; Ketan Talaulikar (ketant) ;
> > gunter.van_de_ve...@nokia.com; aretana.i...@gmail.com;
> > alvaro.ret...@futurewei.com; acee=40cisco@dmarc.ietf.org
> > Subject: [IANA #1173602] Re: IANA early allocation request for draft-
> > ietf-lsr-ospf-bfd-strict-mode
> >
> > Hi Peter, all,
> >
> > > > For both Peter and Gunter: the Flooding Request bit registration
> > > > is
> > > > described in the registry as a temporary allocation, but this may
> > > > have been an mistake The RFC 7120 temporary early allocation
> > > > procedure is meant for registries that require RFC publication
> > > > for
> > > > permanent registration. In theory, if the experts agree,
> > > > permanent
> > > > registrations can be made in Expert Review registries at any
> > > > time.
> > > > Would there be an issue with removing the "TEMPORARY" designation
> > > > from that registration?
> > >
> > > please go ahead and remove the TEMPORARY.
> >
> > The "TEMPORARY" designation has been removed from the draft-ietf-lsr-
> > dynamic-flooding registration in LLS Type 1 Extended Options and
> > Flags, currently still assigned 0x0010:
> >
> > https://www.iana.org/assignments/ospf-lls-tlvs
> >
> > thanks,
> > Amanda
> 
> 

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

Re: [Lsr] Request WG adoption of TTZ

[Acee Lindem (acee)]

Speaking as WG member:

Hi Huaimo,

Independent of the major issue with Area Proxy differentiation, I have a couple 
other issues that I didn’t want to include in the same Email thread.


  1.  You can’t describe IS-IS protocol details and then just include OSPF 
encodings and expect the readers to intuit the OSPF specific details. These 
area abstraction drafts modify basic protocol mechanisms and OSPF details would 
be better specified in an update to RFC 8099 then just adding encodings to this 
IS-IS TTZ draft.
  2.  The draft uses the term IS-IS Pseudo-node yet this is defined in IS-IS as 
a specific LSP to represent a multi-access network. I don’t know if the usage 
of the terminology was meant to differentiate the mechanisms from Area Proxy 
but I find the repurposing of the term pseudo-node in the context of IS-IS very 
confusing.
  3.  The document keeps referring to  “edges full mess” and I believe you mean 
“edges full mesh”.


Thanks,
Acee

From: Lsr  on behalf of Huaimo Chen 

Date: Tuesday, July 7, 2020 at 12:01 PM
To: Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Chris,

Thank you very much for your questions.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo

From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?

[HC]: There are some differences even though they looks similar.
At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.
Area Proxy abstracts an existing area to a single pseudo node.
TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.
An area is different from a zone in general.

Secondly, the ways in which they are applied to an area for scalability are 
different.
When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.
These differences will produce different user experiences.
For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.
For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.

Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.

BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.
In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.


There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?

[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for 
the new solution are defined in the document.

Thanks,
Chris.
[chair hat]


> On Jun 18, 2020, at 11:38 PM, Huaimo Chen  wrote:
>
> Hi Chris and Acee, and everyone,
>
>
>
> I would like to request working group adoption of "Topology-Transparent 
> Zone"
>
> (TTZ for short) https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ .
>
>
>
> This draft comprises the following solutions for helping to improve 
> scalability:
>
> 1) abstracting a zone to a single pseudo node in IS-IS,
>
> 2) abstracting a zone to a single pseudo node in OSPF,
>
> 3) abstracting a zone to zone edges' full mess in IS-IS, and
>
> 4) transferring smoothly between a zone and a single pseudo node.
>
> A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or
>
> non-backbone area).
>
>
>
> When a network area becomes (too) big, we can reduce its size in the sense
>
> of its LSDB size through abstracting a zone to a single pseudo node or
>
> a

Re: [Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

[Acee Lindem (acee)]

Gunter is on vacation... 
Thanks,
Acee

On 7/6/20, 1:14 PM, "Amanda Baber via RT"  wrote:

Hi Ketan, Peter,

I believe we're waiting for Gunter to approve as the remaining expert, but 
we can move ahead if Peter confirms that we don't need to wait.

Best regards,
Amanda

On Mon Jul 06 03:46:02 2020, ket...@cisco.com wrote:
> Hi Amanda/All,
> 
> I thought that there was an agreement to assign bit 0x0010 for
> draft-ietf-lsr-ospf-bfd-strict-mode and 0x0020 for draft-ietf-lsr-
> dynamic-flooding?
> 
> Thanks,
> Ketan
> 
> -Original Message-
>  From: Amanda Baber via RT 
> Sent: 04 July 2020 07:53
> To: Acee Lindem (acee) 
> Cc: Peter Psenak (ppsenak) ; mraj...@juniper.net;
> lsr@ietf.org; Ketan Talaulikar (ketant) ;
> gunter.van_de_ve...@nokia.com; aretana.i...@gmail.com;
> alvaro.ret...@futurewei.com; acee=40cisco@dmarc.ietf.org
> Subject: [IANA #1173602] Re: IANA early allocation request for draft-
> ietf-lsr-ospf-bfd-strict-mode
> 
> Hi Peter, all,
> 
> > > For both Peter and Gunter: the Flooding Request bit registration is
> > > described in the registry as a temporary allocation, but this may
> > > have been an mistake The RFC 7120 temporary early allocation
> > > procedure is meant for registries that require RFC publication for
> > > permanent registration. In theory, if the experts agree, permanent
> > > registrations can be made in Expert Review registries at any time.
> > > Would there be an issue with removing the "TEMPORARY" designation
> > > from that registration?
> >
> > please go ahead and remove the TEMPORARY.
> 
> The "TEMPORARY" designation has been removed from the draft-ietf-lsr-
> dynamic-flooding registration in LLS Type 1 Extended Options and
> Flags, currently still assigned 0x0010:
> 
> https://www.iana.org/assignments/ospf-lls-tlvs
> 
> thanks,
> Amanda


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

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Les,

> I think what you are highlighting is that w TTZ an operator could apply the 
> solution to a subset of an area (which you call a zone) – or to a set of 
> areas (which you also call a zone). This presumes that it is expected that a 
> customer would want to operate in a mode where the interconnections do not 
> follow area boundaries. It isn’t clear to me that this is a compelling 
> requirement. If there are operators who feel otherwise I would appreciate 
> them speaking up and educating us on the requirements.

How do you get that TTZ could be used to a set of areas (which you also call a 
zone)?
A zone is a piece or block of an area.  In an area, we can define one or more 
zones. All these zones are within this area. For a set of areas, we can define 
one or more zones in each of these areas. But we can not define a zone crossing 
multiple areas.

Best Regards,
Huaimo

From: Les Ginsberg (ginsberg) 
Sent: Tuesday, July 7, 2020 3:29 PM
To: Huaimo Chen ; Christian Hopps 

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


Huaimo –



I think what you are highlighting is that w TTZ an operator could apply the 
solution to a subset of an area (which you call a zone) – or to a set of areas 
(which you also call a zone). This presumes that it is expected that a customer 
would want to operate in a mode where the interconnections do not follow area 
boundaries. It isn’t clear to me that this is a compelling requirement. If 
there are operators who feel otherwise I would appreciate them speaking up and 
educating us on the requirements.



Absent that, it seems if you want to differentiate TTZ from Area-Proxy you 
should be focusing on things other than the flexibility of zones over areas..



   Les





From: Huaimo Chen 
Sent: Tuesday, July 07, 2020 11:13 AM
To: Les Ginsberg (ginsberg) ; Christian Hopps 

Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Les,



Thank you very much for your comments.



There are still some differences between Area Proxy and TTZ regarding to 
IS-IS with smooth area splitting and merging.



At first, the operations/configurations are different.

Using Area Proxy, two steps are needed. One step is to split an IS-IS area 
to multiple areas through some configurations. The other step is to abstract an 
existing IS-IS area to a single pseudo node through another set of 
configurations.

Using TTZ, only one step is needed, which is to abstract a zone to a single 
pseudo node.

From operations' point of view, TTZ seems simpler.



Secondly, TTZ provides smooth transferring between a zone and its single 
pseudo node. That is that a zone can be smoothly transferred to a single pseudo 
node, and the pseudo node can be smoothly rolled back to the zone.

Smooth IS-IS area splitting and merging can not be used for abstracting an 
existing IS-IS area to a single pseudo node in Area Proxy.



Best Regards,

Huaimo



From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, July 7, 2020 12:52 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org mailto:lsr@ietf.org>>; 
lsr-cha...@ietf.org 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] Request WG adoption of TTZ



Huaimo –



In regards to merging/splitting areas, IS-IS base protocol provides a way to do 
this hitlessly (this was discussed some years ago when IS-IS TTZ draft was 
first introduced).

So if the major difference/advantage between area-proxy and ttz is the ability 
to use zones to handle area merging/splitting this does not add much value in 
IS-IS.



Please consider this in your responses.



Thanx.



Les





From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Tuesday, July 07, 2020 9:00 AM
To: Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org; 
lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Chris,



Thank you very much for your questions.

My answers/explanations are inline below with prefix [HC].



Best Regards,

Huaimo



From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; 
lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?



[HC]: There are some differences even though they looks similar.

At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.

Area Proxy abstracts an existing area to a single pseudo node.

TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.

An area is different

Re: [Lsr] Request WG adoption of TTZ

[Acee Lindem (acee)]

Speaking as WG member:

I agree with Chris – when the IS-IS TTZ draft adopted the approach of having 
the area/zone leader originate a single LSP abstracting the zone/area last Oct, 
the main differentiation between the two approaches is the zone/area 
terminology. The other substantive difference is the fact that the Area Proxy 
draft includes a much more comprehensive specification of the protocol 
mechanisms required for area/zone abstraction. I have no doubt that the Area 
Proxy details could also be amended from area proxy to TTZ, but that is exactly 
Chris’s point with which I agree – there essentially isn’t a difference.

Thanks,
Acee
From: Lsr  on behalf of Huaimo Chen 

Date: Tuesday, July 7, 2020 at 12:01 PM
To: Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Chris,

Thank you very much for your questions.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo

From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?

[HC]: There are some differences even though they looks similar.
At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.
Area Proxy abstracts an existing area to a single pseudo node.
TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.
An area is different from a zone in general.

Secondly, the ways in which they are applied to an area for scalability are 
different.
When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.
These differences will produce different user experiences.
For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.
For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.

Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.

BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.
In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.


There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?

[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for 
the new solution are defined in the document.

Thanks,
Chris.
[chair hat]


> On Jun 18, 2020, at 11:38 PM, Huaimo Chen  wrote:
>
> Hi Chris and Acee, and everyone,
>
>
>
> I would like to request working group adoption of "Topology-Transparent 
> Zone"
>
> (TTZ for short) https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ .
>
>
>
> This draft comprises the following solutions for helping to improve 
> scalability:
>
> 1) abstracting a zone to a single pseudo node in IS-IS,
>
> 2) abstracting a zone to a single pseudo node in OSPF,
>
> 3) abstracting a zone to zone edges' full mess in IS-IS, and
>
> 4) transferring smoothly between a zone and a single pseudo node.
>
> A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or
>
> non-backbone area).
>
>
>
> When a network area becomes (too) big, we can reduce its size in the sense
>
> of its LSDB size through abstracting a zone to a single pseudo node or
>
> abstracting a few zones to a few pseudo nodes.
>
>
>
> While a zone is being abstracted (or transferred) to a single pseudo node,
>
> the network is stable. There is no or minimum service interruption.
>
>
>
> After abstracting a few zones to a few pseudo nodes, if we want to 
> reconstruct
>
> them, we can 

Re: [Lsr] Request WG adoption of TTZ

[Les Ginsberg (ginsberg)]

Huaimo -

I think what you are highlighting is that w TTZ an operator could apply the 
solution to a subset of an area (which you call a zone) - or to a set of areas 
(which you also call a zone). This presumes that it is expected that a customer 
would want to operate in a mode where the interconnections do not follow area 
boundaries. It isn't clear to me that this is a compelling requirement. If 
there are operators who feel otherwise I would appreciate them speaking up and 
educating us on the requirements.

Absent that, it seems if you want to differentiate TTZ from Area-Proxy you 
should be focusing on things other than the flexibility of zones over areas..

   Les


From: Huaimo Chen 
Sent: Tuesday, July 07, 2020 11:13 AM
To: Les Ginsberg (ginsberg) ; Christian Hopps 

Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Les,

Thank you very much for your comments.

There are still some differences between Area Proxy and TTZ regarding to 
IS-IS with smooth area splitting and merging.

At first, the operations/configurations are different.
Using Area Proxy, two steps are needed. One step is to split an IS-IS area 
to multiple areas through some configurations. The other step is to abstract an 
existing IS-IS area to a single pseudo node through another set of 
configurations.
Using TTZ, only one step is needed, which is to abstract a zone to a single 
pseudo node.
From operations' point of view, TTZ seems simpler.

Secondly, TTZ provides smooth transferring between a zone and its single 
pseudo node. That is that a zone can be smoothly transferred to a single pseudo 
node, and the pseudo node can be smoothly rolled back to the zone.
Smooth IS-IS area splitting and merging can not be used for abstracting an 
existing IS-IS area to a single pseudo node in Area Proxy.

Best Regards,
Huaimo

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, July 7, 2020 12:52 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org mailto:lsr@ietf.org>>; 
lsr-cha...@ietf.org 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] Request WG adoption of TTZ


Huaimo -



In regards to merging/splitting areas, IS-IS base protocol provides a way to do 
this hitlessly (this was discussed some years ago when IS-IS TTZ draft was 
first introduced).

So if the major difference/advantage between area-proxy and ttz is the ability 
to use zones to handle area merging/splitting this does not add much value in 
IS-IS.



Please consider this in your responses.



Thanx.



Les





From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Tuesday, July 07, 2020 9:00 AM
To: Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org; 
lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Chris,



Thank you very much for your questions.

My answers/explanations are inline below with prefix [HC].



Best Regards,

Huaimo



From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; 
lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?



[HC]: There are some differences even though they looks similar.

At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.

Area Proxy abstracts an existing area to a single pseudo node.

TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.

An area is different from a zone in general.



Secondly, the ways in which they are applied to an area for scalability are 
different.

When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.

These differences will produce different user experiences.

For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.

For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.



Moreover, TTZ provides smooth transfer

Re: [Lsr] Request WG adoption of TTZ

[tony . li]

>> Moreover, TTZ provides smooth transferring between a zone and its single 
>> pseudo node. That is that a zone can be smoothly transferred to a single 
>> pseudo node, and the pseudo node can be smoothly rolled back to the zone.
> 
> This strikes me as the important difference from area proxy. It certainly 
> adds complexity to things, I wonder if it's worth it?


FWIW, we looked at this quite seriously a while ago. Turning abstraction on and 
off is simply not a daily occurrence. Doing it properly requires careful 
thought and planning. 
Where are the boundaries? What prefixes will be advertised and with what 
metrics? How will the affect traffic flow?

The corner cases that happen when you are in this transition are large. We have 
to deal with the issue of the metrics that are abstracted away.  We chose to go 
down the path
of intra-area vs. inter-area metrics, exactly as OSPF does. But if you do this, 
then you have an issue: the metrics are different when abstraction is enabled 
or disabled and 
different nodes will compute different paths depending on which LSPs have 
propagated to them. This seemed like a wonderful opportunity for forwarding 
loops. This
is especially problematic when abstraction is enabled, as there is now an 
entire area’s worth of LSPs that need to age out before you can be assured of 
consistency.
Yes, you can try to purge them, but purges aren’t the most reliable thing in 
the world.  

Net net, we felt that the complexity exceeded the benefit. Yes, there is 
benefit there, but from the pragmatic viewpoint of making it work in 
production, the risks and costs seemed very high. 
We expect that operators would want to make the change in a maintenance window 
anyway, and as long as you’re having a maintenance window, you might as well do 
things the
simpler way.

Regards,
Tony

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

Re: [Lsr] Request WG adoption of TTZ

[Christian Hopps]

> On Jul 7, 2020, at 12:00 PM, Huaimo Chen  wrote:
> 
> Hi Chris,
> 
> Thank you very much for your questions.
> My answers/explanations are inline below with prefix [HC].
> 
> Best Regards,
> Huaimo
> From: Christian Hopps
> Sent: Tuesday, July 7, 2020 8:08 AM
> To: Huaimo Chen
> Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> Hi Huaimo,
> 
> Can you speak to the differences of this with Area Proxy? They are similar 
> solutions, right?
> 
> [HC]: There are some differences even though they looks similar.
> At first, the target to be abstracted in Area Proxy is different from that in 
> TTZ.
> Area Proxy abstracts an existing area to a single pseudo node.
> TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of 
> an area.
> An area is different from a zone in general.

[As wg member]

If the operator needed a subset of an area abstracted they could split the area 
and then use area proxy on the subset though, right? Restricting things to 
exactly the area boundary as area proxy does seems like an elegant KISS 
approach; it has the advantage of harnessing all the existing tools and 
institutional knowledge on how IS-IS areas work. This in turn simplifies 
management and debugability I think. While TTZ adds some extra flexibility 
(cuts out the area split step) I don't know that the added complexity makes 
sense since splitting an area is basically the same operation as configuring a 
zone would be.

> Secondly, the ways in which they are applied to an area for scalability are 
> different.
> When an area becomes bigger and bigger, we may have scalability issues. Using 
> TTZ, we can abstract one or a few zones in the area to one or few pseudo 
> nodes smoothly without any interface down. Using Area Proxy, we need split 
> the existing area into multiple areas, and then abstract one or a few areas 
> to one or few pseudo nodes.
> These differences will produce different user experiences.
> For splitting an existing area into multiple areas, users may need put more 
> efforts since it causes service interruptions in general. While splitting an 
> area such as an OSPF area into multiple areas, the area numbers configured on 
> some interfaces will be changed and each of these interfaces will be down 
> with its old area number and then up with its new area number. These 
> interface downs and ups will cause service interruptions in general.
> For defining zones in an area, users may need less efforts since abstracting 
> a zone to a single pseudo node is smooth without any interface down.
> 
> Moreover, TTZ provides smooth transferring between a zone and its single 
> pseudo node. That is that a zone can be smoothly transferred to a single 
> pseudo node, and the pseudo node can be smoothly rolled back to the zone.

This strikes me as the important difference from area proxy. It certainly adds 
complexity to things, I wonder if it's worth it?

Thanks,
Chris.
[As WG member]

> 
> BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to 
> a single pseudo node.
> In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo 
> node, and a zone in an IS-IS area to a single pseudo node.
> 
> 
> There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so 
> i found it confusing to have this document also talking about TTZ for OSPF; 
> is it redefining it, updating it, just referring to it?
> 
> [HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
> abstracting a zone to the zone edges full mess. This document proposes a new 
> solution for abstracting a zone to a single pseudo node. The new solution 
> re-uses some of RFC 8099, to which are referred. The new extensions to OSPF 
> for the new solution are defined in the document.
> 
> Thanks,
> Chris.
> [chair hat]
> 
> 
> > On Jun 18, 2020, at 11:38 PM, Huaimo Chen  wrote:
> >
> > Hi Chris and Acee, and everyone,
> >
> >
> >
> > I would like to request working group adoption of "Topology-Transparent 
> > Zone"
> >
> > (TTZ for short) https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ .
> >
> >
> >
> > This draft comprises the following solutions for helping to improve 
> > scalability:
> >
> > 1) abstracting a zone to a single pseudo node in IS-IS,
> >
> > 2) abstracting a zone to a single pseudo node in OSPF,
> >
> > 3) abstracting a zone to zone edges' full mess in IS-IS, and
> >
> > 4) transferring smoothly between a zone and a single pseudo node.
> >
> > A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or
> >
> > non-backbone area).
> >
> >
> >
> > When a network area becomes (too) big, we can reduce its size in the 
> > sense
> >
> > of its LSDB size through abstracting a zone to a single pseudo node or
> >
> > abstracting a few zones to a few pseudo nodes.
> >
> >
> >
> > While a zone is being abstracted (or transferred) to a

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Les,

Thank you very much for your comments.

There are still some differences between Area Proxy and TTZ regarding to 
IS-IS with smooth area splitting and merging.

At first, the operations/configurations are different.
Using Area Proxy, two steps are needed. One step is to split an IS-IS area 
to multiple areas through some configurations. The other step is to abstract an 
existing IS-IS area to a single pseudo node through another set of 
configurations.
Using TTZ, only one step is needed, which is to abstract a zone to a single 
pseudo node.
From operations' point of view, TTZ seems simpler.

Secondly, TTZ provides smooth transferring between a zone and its single 
pseudo node. That is that a zone can be smoothly transferred to a single pseudo 
node, and the pseudo node can be smoothly rolled back to the zone.
Smooth IS-IS area splitting and merging can not be used for abstracting an 
existing IS-IS area to a single pseudo node in Area Proxy.

Best Regards,
Huaimo

From: Les Ginsberg (ginsberg) 
Sent: Tuesday, July 7, 2020 12:52 PM
To: Huaimo Chen ; Christian Hopps 

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


Huaimo –



In regards to merging/splitting areas, IS-IS base protocol provides a way to do 
this hitlessly (this was discussed some years ago when IS-IS TTZ draft was 
first introduced).

So if the major difference/advantage between area-proxy and ttz is the ability 
to use zones to handle area merging/splitting this does not add much value in 
IS-IS.



Please consider this in your responses.



Thanx.



Les





From: Lsr  On Behalf Of Huaimo Chen
Sent: Tuesday, July 07, 2020 9:00 AM
To: Christian Hopps 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Chris,



Thank you very much for your questions.

My answers/explanations are inline below with prefix [HC].



Best Regards,

Huaimo



From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; 
lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?



[HC]: There are some differences even though they looks similar.

At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.

Area Proxy abstracts an existing area to a single pseudo node.

TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.

An area is different from a zone in general.



Secondly, the ways in which they are applied to an area for scalability are 
different.

When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.

These differences will produce different user experiences.

For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.

For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.



Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.



BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.

In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.



There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?



[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for 
the new solution are defined in the document.

Thanks,
Chris.
[chair hat]


> On Jun 18, 2020, at 11:38 PM, Huaimo Chen 
> mailto:huaimo.c...@futurewei.com>> wrote:
>
> Hi Chris and Acee, and everyone,
>
>
>
> 

Re: [Lsr] [spring] clarification of END Point behavior in draft-ietf-spring-srv6-network-programming

[Pablo Camarillo (pcamaril)]

Hi Parag,

Yes, it can be the last SID. When SL=0 you ignore the SRH and process the next 
header in the header chain. Upper-layer header processing is defined in 4.1.1.
If you would like to remove the SRH with the End behavior you can use PSP, USP 
or USD flavors to do so.

Regards,
Pablo.

From: spring  On Behalf Of Parag Kaneriya
Sent: lunes, 6 de julio de 2020 11:17
To: lsr@ietf.org; SPRING WG 
Subject: Re: [spring] [Lsr] clarification of END Point behavior in 
draft-ietf-spring-srv6-network-programming

Hello,

I am going through recent draft 
https://tools.ietf.org/pdf/draft-ietf-spring-srv6-network-programming-16.pdf

Changes are follow ,

4.1. End: Endpoint

S01. When an SRH is processed {
S02. If (Segments Left == 0) {
S03. Proceed to process the next header in the packet, whose type is identified 
by the Next Header field in the routing header.
S04. }
S05. If (IPv6 Hop Limit <= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address, Code 0 (Hop 
limit exceeded in transit), Interrupt packet processing and discard
 the packet.
S07. }


With these change, I have below few question


  1.  Can END SID can be last SID of the SID list ?   earlier draft (not sure 
which version), it was explicitly mentioned that last SID can't be END sid ( 
Most basic flavors ).
  2.  IF yes then When/Who will remove the SRH header when last sid is END SID 
in the sid list.

Regards
Parag


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Les Ginsberg (ginsberg)]

Huaimo -

In regards to merging/splitting areas, IS-IS base protocol provides a way to do 
this hitlessly (this was discussed some years ago when IS-IS TTZ draft was 
first introduced).
So if the major difference/advantage between area-proxy and ttz is the ability 
to use zones to handle area merging/splitting this does not add much value in 
IS-IS.

Please consider this in your responses.

Thanx.

Les


From: Lsr  On Behalf Of Huaimo Chen
Sent: Tuesday, July 07, 2020 9:00 AM
To: Christian Hopps 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Chris,

Thank you very much for your questions.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo

From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; 
lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?

[HC]: There are some differences even though they looks similar.
At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.
Area Proxy abstracts an existing area to a single pseudo node.
TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.
An area is different from a zone in general.

Secondly, the ways in which they are applied to an area for scalability are 
different.
When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.
These differences will produce different user experiences.
For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.
For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.

Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.

BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.
In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.


There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?

[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for 
the new solution are defined in the document.

Thanks,
Chris.
[chair hat]


> On Jun 18, 2020, at 11:38 PM, Huaimo Chen 
> mailto:huaimo.c...@futurewei.com>> wrote:
>
> Hi Chris and Acee, and everyone,
>
>
>
> I would like to request working group adoption of "Topology-Transparent 
> Zone"
>
> (TTZ for short) https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ .
>
>
>
> This draft comprises the following solutions for helping to improve 
> scalability:
>
> 1) abstracting a zone to a single pseudo node in IS-IS,
>
> 2) abstracting a zone to a single pseudo node in OSPF,
>
> 3) abstracting a zone to zone edges' full mess in IS-IS, and
>
> 4) transferring smoothly between a zone and a single pseudo node.
>
> A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or
>
> non-backbone area).
>
>
>
> When a network area becomes (too) big, we can reduce its size in the sense
>
> of its LSDB size through abstracting a zone to a single pseudo node or
>
> abstracting a few zones to a few pseudo nodes.
>
>
>
> While a zone is being abstracted (or transferred) to a single pseudo node,
>
> the network is stable. There is no or minimum service interruption.
>
>
>
> After abstracting a few zones to a few pseudo nodes, if we want to 
> reconstruct
>
> them, we can transfer (or roll) any of the pseudo nodes back to its zone 
> smoothly
>
> with no or minimum service interruption.
>
>
>
> We had a prototype implementation

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Chris,

Thank you very much for your questions.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo

From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?

[HC]: There are some differences even though they looks similar.
At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.
Area Proxy abstracts an existing area to a single pseudo node.
TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.
An area is different from a zone in general.

Secondly, the ways in which they are applied to an area for scalability are 
different.
When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.
These differences will produce different user experiences.
For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.
For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.

Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.

BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.
In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.


There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?

[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for 
the new solution are defined in the document.

Thanks,
Chris.
[chair hat]


> On Jun 18, 2020, at 11:38 PM, Huaimo Chen  wrote:
>
> Hi Chris and Acee, and everyone,
>
>
>
> I would like to request working group adoption of "Topology-Transparent 
> Zone"
>
> (TTZ for short) https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ .
>
>
>
> This draft comprises the following solutions for helping to improve 
> scalability:
>
> 1) abstracting a zone to a single pseudo node in IS-IS,
>
> 2) abstracting a zone to a single pseudo node in OSPF,
>
> 3) abstracting a zone to zone edges' full mess in IS-IS, and
>
> 4) transferring smoothly between a zone and a single pseudo node.
>
> A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or
>
> non-backbone area).
>
>
>
> When a network area becomes (too) big, we can reduce its size in the sense
>
> of its LSDB size through abstracting a zone to a single pseudo node or
>
> abstracting a few zones to a few pseudo nodes.
>
>
>
> While a zone is being abstracted (or transferred) to a single pseudo node,
>
> the network is stable. There is no or minimum service interruption.
>
>
>
> After abstracting a few zones to a few pseudo nodes, if we want to 
> reconstruct
>
> them, we can transfer (or roll) any of the pseudo nodes back to its zone 
> smoothly
>
> with no or minimum service interruption.
>
>
>
> We had a prototype implementation of abstracting a zone to zone edges' 
> full
>
> mess in OSPF. The procedures and related protocol extensions for transferring
>
> smoothly from a zone to zone edges' full mess are implemented and tested.
>
> A zone (block of an OSPF area) is smoothly transferred to its edges’ full mess
>
> without any routing disruptions. The routes on every router are stable while
>
> the zone is being transferred to its edges' mess. It is very easy to operate
>
> the transferring.
>
>
>
> There are two other drafts for improving scalability: "Area Proxy for 
> IS-IS"
>
> (Area Proxy for short) and "IS-IS Flood Reflection" (Flood Reflection for 
> short).
>
>
>
> "Area Proxy"

[Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

[tony . li]

Hi all,

We’ve updated our draft to revise the TLV encodings along the lines of the 
discussions we’ve been having.

1) The Area Proxy Router Capability is removed.
2) The Inside Node TLV is removed. Instead, the Area Proxy TLV is used instead.
3) The Area Segment SID is advertised inside of a SID/Label Binding TLV. While 
we discussed using 
a flag within this TLV to denote that this was an Area Segment SID, after 
looking at it, it seemed simpler
and more consistent to use a sub-TLV.

Please review and comment.

Thanks,
Sarah, Vivek, Gyan, and Tony


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt
> Date: July 7, 2020 at 8:14:58 AM PDT
> To: "Gyan Mishra" , "Vivek Ilangovan" 
> , "Sarah Chen" , "Tony Li" 
> , "Gyan S. Mishra" , "Yunxia 
> Chen" 
> 
> 
> A new version of I-D, draft-ietf-lsr-isis-area-proxy-01.txt
> has been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-isis-area-proxy
> Revision: 01
> Title:Area Proxy for IS-IS
> Document date:2020-07-07
> Group:lsr
> Pages:19
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-lsr-isis-area-proxy-01.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-01
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-01
> 
> Abstract:
>   Link state routing protocols have hierarchical abstraction already
>   built into them.  However, when lower levels are used for transit,
>   they must expose their internal topologies to each other, leading to
>   scale issues.
> 
>   To avoid this, this document discusses extensions to the IS-IS
>   routing protocol that would allow level 1 areas to provide transit,
>   yet only inject an abstraction of the level 1 topology into level 2.
>   Each level 1 area is represented as a single level 2 node, thereby
>   enabling greater scale.
> 
> 
> 
> 
> 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] I-D Action: draft-ietf-lsr-isis-area-proxy-01.txt

[internet-drafts]

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   : Area Proxy for IS-IS
Authors : Tony Li
  Sarah Chen
  Vivek Ilangovan
  Gyan S. Mishra
Filename: draft-ietf-lsr-isis-area-proxy-01.txt
Pages   : 19
Date: 2020-07-07

Abstract:
   Link state routing protocols have hierarchical abstraction already
   built into them.  However, when lower levels are used for transit,
   they must expose their internal topologies to each other, leading to
   scale issues.

   To avoid this, this document discusses extensions to the IS-IS
   routing protocol that would allow level 1 areas to provide transit,
   yet only inject an abstraction of the level 1 topology into level 2.
   Each level 1 area is represented as a single level 2 node, thereby
   enabling greater scale.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-01
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-01


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

Re: [Lsr] Request WG adoption of TTZ

[Christian Hopps]

Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?

There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?

Thanks,
Chris.
[chair hat]


> On Jun 18, 2020, at 11:38 PM, Huaimo Chen  wrote:
> 
> Hi Chris and Acee, and everyone,
> 
> 
> 
> I would like to request working group adoption of "Topology-Transparent 
> Zone"
> 
> (TTZ for short) https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ ..
> 
> 
> 
> This draft comprises the following solutions for helping to improve 
> scalability:
> 
> 1) abstracting a zone to a single pseudo node in IS-IS,
> 
> 2) abstracting a zone to a single pseudo node in OSPF,
> 
> 3) abstracting a zone to zone edges' full mess in IS-IS, and
> 
> 4) transferring smoothly between a zone and a single pseudo node.
> 
> A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or
> 
> non-backbone area).
> 
> 
> 
> When a network area becomes (too) big, we can reduce its size in the sense
> 
> of its LSDB size through abstracting a zone to a single pseudo node or
> 
> abstracting a few zones to a few pseudo nodes.
> 
> 
> 
> While a zone is being abstracted (or transferred) to a single pseudo node,
> 
> the network is stable. There is no or minimum service interruption.
> 
> 
> 
> After abstracting a few zones to a few pseudo nodes, if we want to 
> reconstruct
> 
> them, we can transfer (or roll) any of the pseudo nodes back to its zone 
> smoothly
> 
> with no or minimum service interruption.
> 
> 
> 
> We had a prototype implementation of abstracting a zone to zone edges' 
> full
> 
> mess in OSPF. The procedures and related protocol extensions for transferring
> 
> smoothly from a zone to zone edges' full mess are implemented and tested.
> 
> A zone (block of an OSPF area) is smoothly transferred to its edges’ full mess
> 
> without any routing disruptions. The routes on every router are stable while
> 
> the zone is being transferred to its edges' mess. It is very easy to operate
> 
> the transferring.
> 
> 
> 
> There are two other drafts for improving scalability: "Area Proxy for 
> IS-IS"
> 
> (Area Proxy for short) and "IS-IS Flood Reflection" (Flood Reflection for 
> short).
> 
> 
> 
> "Area Proxy" https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03
> 
> abstracts an existing IS-IS L1 area to a single pseudo node.
> 
> 
> 
> "Flood Reflection" 
> https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01
> 
> abstracts an existing IS-IS L1 area to its edges' connections via one or more
> 
> flood reflectors.
> 
> 
> 
> We believe that TTZ has some special advantages even though
> 
> Area Proxy and Flood Reflection are very worthy. We would like
> 
> to ask for working group adoption of TTZ.
> 
> 
> Best Regards,
> 
> Huaimo
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr



signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr