Hi Tony,
>- If there is a benefit to zones, it’s not clear to us. You need to do a
>better job articulating that.
[HC]: Using zone/TTZ for scalability seems simpler than using Areas. It uses
less planning efforts and less configurations (refer to
https://mailarchive.ietf.org/arch/msg/lsr/H8muA
Hi Robert,
The "transition" means transfer/abstract a zone to a single virtual node
smoothly and roll the virtual node back to the zone smoothly.
TTZ draft contains a solution for the "transition", which reduces the
traffic interruption when a zone is abstracted to a node and vice versa.
Hi Robert,
> * IGP scalability can be easily solved with the additional levels of current
> abstraction instead of introducing new types of abstraction into it. Ref:
> draft-ietf-lsr-isis-extended-hierarchy
[HC]: There are three LSR drafts that experiment/explore the new ways for
scalability. T
Hi Robert,
>It seems that in TTZ instead of careful planning of your abstractions the plan
>is to randomly create zones and see what happens - is this right reading of
>your explanation ?
[HC]: TTZ provides users flexibility to define a zone and abstract the zone to
a single node for scalabili
Peter,
In order to make the document clearer on this point, I would like the text
below to be added
to section 11 to make it explicit that setting the L-bit is valid for flex-algo
for ISIS.
=
Section 11.
“The ASLA TLV in ISIS supports the L-Bit as described in section 4.2 of
[draf
> - The transition mechanisms
Hmmm maybe I missed some explanations by authors, but to me concept of
zones is positioned as an addition to the concept of areas or levels - not
a replacement of those.
So when you say "transition" means that something existing no longer would
be in place after succ
Hi Xueson,
> My intension was not to talk about math/engineering/marketing or compare the
> size of marketing department. Them are not relevant to this thread.
You are the one who suggested we leave it up to the market…
> I want to make clear about IETF process. In my understanding the docum
Hi all,
This version reflects the discussion to date and the early allocation of code
points.
Regards,
Sarah, Vivek, Gyan, & Tony
> Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-04.txt
> Date: September 2, 2
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
Vive
Since careful planning and design is required to split a L1 Area into L1a
L1b using TTZ as this is a major effort to plan out. It maybe easier as
part of the planning effort to just create two separate L1 areas that have
different L1/L2 attachment points for the attach bit to be propagated. Use
e
Hi Shraddha,
please see inline:
On 02/09/2020 06:45, Shraddha Hegde wrote:
Peter,
It is worthwhile to note the history of the flex-algo draft and the
te-app draft and how many backward incompatible changes have been
introduced in the course of the flex-algo draft.
The original drafts of fle
> acknowledged problem (IGP scalability)
Great so we see the problem description. This is progress !
Allow me to observe two points:
* IGP scalability can be easily solved with the additional levels of
current abstraction instead of introducing new types of abstraction into
it. Ref: draft-ietf-
> people need to spend their time in deciding where is the boundary between
the two areas
Oh then I perhaps completely missed the value and power of TTZ.
It seems that in TTZ instead of careful planning of your abstractions the
plan is to randomly create zones and see what happens - is this right
Hi Tony,
My intension was not to talk about math/engineering/marketing or compare the
size of marketing department. Them are not relevant to this thread.
I want to make clear about IETF process. In my understanding the document does
not need to be perfect at this stage, as long as it is in the r
14 matches
Mail list logo