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

[Richard Li]

Hi Robert,

- It was not meant to be a silver-bullet by saying “5G”. It happened that I 
have been discussing with folks on the design of the mobile backhaul/core/MEC.  
Most of the designers and planners of the mobile backhaul/core/MEC do not work 
on routing technologies themselves, instead they choose and pick up some 
existing solutions provided by the IETF, and if they are not comfortable with 
the existing solutions, they use central controller/orchestrator and/or other 
management systems in a quasi-static config way.

Indeed, the WP you quoted does not indicate a need for zones. That said, you 
cannot deny that MEC is a set of inter-connected nodes, especially when being 
connected to the aggregation ring. Now the question is whether or not you allow 
such nodes to participate in routing. If you do, TTZ is a good candidate to 
reduce the internal topology and to turn MEC into a virtualized one; if you 
don’t, however, there is no space to discuss it.

Anyway, TTZ is aimed to be “experimental”.


Best regards,

Richard



From: Robert Raszuk 
Sent: Wednesday, August 19, 2020 12:25 AM
To: Richard Li 
Cc: Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt

Hi Richard,

I understand that these days you say "5G" and you are done for any use case. :)

So I read this paper: 
https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp28_mec_in_5G_FINAL.pdf<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.etsi.org%2Fimages%2Ffiles%2FETSIWhitePapers%2Fetsi_wp28_mec_in_5G_FINAL.pdf=02%7C01%7Crichard.li%40futurewei.com%7C1a28b96b430246e2eaa208d844f2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637334187402121649=l7uwLpOhqEkY20ZsQgCv4N0Ce9JgVMG%2FskWQ1RdkjJ4%3D=0>

There is nothing there which would indicate a need for zone or even area 
separation to effectively deploy MEC. To me MEC data path can be constructed 
with a form of encapsulation in an arbitrary fashion. In fact I could say the 
more underlay walls you implement the harder it becomes to construct arbitrary 
MEC mesh.

At least for LSR WG if I were to justify any work here like TTZ I would explain 
why Multi access edge computing requires IGP/underlay type of separation and 
moreover why such separation can not be constructed with areas or levels.

Thx,
R.

On Wed, Aug 19, 2020 at 5:18 AM Richard Li 
mailto:richard...@futurewei.com>> wrote:
This is a use case:

The user plane of 5G is distributed, and MEC is deployed as part of the user 
plane to provide some functions at Access Aggregation Ring or Regional 
Aggregation Ring or at the border between Regional Aggregation Ring and the 
National Core. Using TTZ, MEC or part of it can be virtualized and 
topologically simplified. Note that the outside really doesn’t care about the 
internals of MEC.


Thanks,

Richard



From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Robert Raszuk
Sent: Tuesday, August 18, 2020 2:25 PM
To: Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt

Dear WG,

The draft in question does not describe even a single practical use case.

While it describes the mechanics on how to construct the new model of the 
abstraction it fails to prove we need it.

Not everything which can be invented should be standardized or implemented 
therefore until the document extensively describes the real use cases with 
justification why use of areas may not be sufficient for such use cases I don't 
think LSR WG should adopt it.

Regards,
Robert.

On Tue, Aug 18, 2020 at 4:17 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:

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

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

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

Thanks,
Acee and Chris

___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr=02%7C01%7Crichard.li%40futurewei.com%7C1a28b96b430246e2eaa208d844f2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637334187402131636=0wIVp2ymiUSfvbsNWjswxRilK03oyF9wOVdQbX9i0rI%3D=0>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Richard Li]

This is a use case:

The user plane of 5G is distributed, and MEC is deployed as part of the user 
plane to provide some functions at Access Aggregation Ring or Regional 
Aggregation Ring or at the border between Regional Aggregation Ring and the 
National Core. Using TTZ, MEC or part of it can be virtualized and 
topologically simplified. Note that the outside really doesn’t care about the 
internals of MEC.


Thanks,

Richard



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

Dear WG,

The draft in question does not describe even a single practical use case.

While it describes the mechanics on how to construct the new model of the 
abstraction it fails to prove we need it.

Not everything which can be invented should be standardized or implemented 
therefore until the document extensively describes the real use cases with 
justification why use of areas may not be sufficient for such use cases I don't 
think LSR WG should adopt it.

Regards,
Robert.

On Tue, Aug 18, 2020 at 4:17 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:

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

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

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

Thanks,
Acee and Chris

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

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

[Richard Li]

I support it.

Yes, indeed, this draft is sufficiently different from 
draft-ietf-lsr-isis-area-proxy-03 and should be advanced independently.

Best regards,

Richard



From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Acee 
Lindem (acee) 
mailto:acee=40cisco.@dmarc.ietf.org>>
Sent: Tuesday, August 18, 2020 10:16 AM
To: lsr@ietf.org mailto:lsr@ietf.org>>
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt




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



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



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



Thanks,

Acee and Chris


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

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

[Richard Li]

Neither am I.

Best regards,

-Richard

From: Kiran Makhijani 
Sent: Tuesday, August 18, 2020 1:51 PM
To: Acee Lindem (acee) ; draft-chen-isis-...@ietf.org
Cc: lsr@ietf.org
Subject: RE: LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz.txt

Hi,
I am not aware of any undeclared IPR for this draft.
-Kiran

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Tuesday, August 18, 2020 7:24 AM
To: draft-chen-isis-...@ietf.org
Cc: lsr@ietf.org
Subject: LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz.txt

Authors,

The IETF IPRs declarations submitted for draft-chen-isis-ttz are specified here:

https://datatracker.ietf.org/ipr/4029/


Are you aware of any other IPR that applies to draft-chen-isis-ttz?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

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

Re: [Lsr] Request WG adoption of TTZ

[Richard Li]

I support the adoption of the IS-IS TTZ draft.

Using TTZ it is straightforward and easy to turn a zone into a single 
virtualized node. TTZ can provably achieve  topology complexity reduction and 
scalability enhancement. The operation is simple, and the customer experience 
is enhanced. Its benefit weighs more than its cost. The LSR should let the work 
on TTZ move forward.

Stay safe and healthy, everyone!

Thanks,

Richard



> On Thu, 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

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