Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Greg, > Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, 10 > nanoseconds or 100 nanoseconds. > Ok. The specific precision isn’t particularly relevant to me. The real questions are whether microseconds are the right base or not, and whether we should shift to

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Aijun, > My suggestion is still not introduce such non-cumulative metric to cumulative > based SPF calculation process. Again, what we’re proposing is cumulative. Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Ketan, > In general, I support the adoption of this document. There is, however, one > specific point which is not clear to me (8) below that I would appreciate > some clarity on before adoption. As the chairs have noted, adoption is binary and not contingent upon rough consensus on the

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

y 24, 2021 at 8:33 AM Tony Li <mailto:tony...@tony.li>> wrote: > > >> On May 24, 2021, at 8:27 AM, Anoop Ghanwani > <mailto:an...@alumni.duke.edu>> wrote: >> >> I think it might be a good idea if the draft mentioned what delay(s) >> &qu

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

> On May 24, 2021, at 8:27 AM, Anoop Ghanwani wrote: > > I think it might be a good idea if the draft mentioned what delay(s) "SHOULD" > be used. Why? It seems like this is local to a domain. The network administrator is free to do as he sees fit and include whatever parameters make sense

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Greg, That’s a very fair question and not one that has been discussed. Do we have that kind of accuracy from any of our measurement tools? Is that even on the horizon? I haven’t seen that… If it is time for nanosecond level measurement, then is it time to shift to floating point to give

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Aijun, >>> [WAJ] The operator must plan carefully for the metric assignment >>> accordingly to their specific topology to let the traffic pass the >>> necessary high bandwidth path as done in the following example. >> >> >> That’s only if they have no concerns about the hop count. > [WAJ]

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Aijun, > [WAJ] The operator must plan carefully for the metric assignment accordingly > to their specific topology to let the traffic pass the necessary high > bandwidth path as done in the following example. That’s only if they have no concerns about the hop count. Previous experience

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Aijun, >>> With the introduce of additional constraint information, the problem >>> described in “Introduction” part(Section 1) can be solved. >> >> >> Please say more. Claims without rationale are not reasoning. > [WAJ] The introduction part talks mainly how to divert the elephant

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Aijun, > I support the adoption of the “FAD constraint sub-TLV” part(Section 3), but > not support the introduce of “Bandwidth Metric Advertisement” part (Section > 4) and other related parts. As I understand it, we don’t get a line item veto, so I don’t know how the chairs will take

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Peng Shaofu, > On May 19, 2021, at 6:55 PM, peng.sha...@zte.com.cn wrote: > > Let's go back to the bandwidth-metric related to bandwidth capability. My > worry is that bandwidth-metric (whether it is automatically calculated or > manually configured) is not cumulative in nature, which is

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Support as co-author. I am not aware of any IPR on this draft. Tony > On May 12, 2021, at 2:09 PM, Acee Lindem (acee) wrote: > > Esteemed Members of the LSR WG, > > This begins a 2 week WG adoption call for the following draft: > >

Re: [Lsr] Guidance for IANA flags field registry creation.

Les, > I did (an admittedly casual) review of such fields in all TLVs defined during > the existence of the IS-IS/LSR WGs - which covers over 20 years. I did not > find a single occurrence where the flags field ever got extended. draft-ietf-isis-te-app defines the Application Specific Link

Re: [Lsr] When is an IANA Registry Required

Les, > IMO, there is no need for registries for the first category. The WG has been > alive for over 20 years, defined many new TLVs with flags fields, and I am > not aware of any confusion – so if it ain’t broke don’t fix it. With all due respect Les, you appear to operate with an eidetic

Re: [Lsr] When is an IANA Registry Required

Les, > [Les:] The question here is whether there is a qualitative difference between > two classes of bit fields. That is indeed the key question. IMHO, there is not. I don’t much care if a field is updated by a bis document or a related document. Regardless of the cause, as soon as there

Re: [Lsr] When is an IANA Registry Required

> I don't know that you and I are getting anywhere. I know Robert also > cares about this topic, I hope others do too. I care. It seems to me that we have registries where we have different documents allocating values from the same space. This makes sense: we need to coordinate things.

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Hi Gyan, > Gyan> In previous threads BFD multi hop has been mentioned to track IGP > liveliness but that gets way overly complicated especially with large domains > and not viable. This is not tracking IGP liveness, this is to track BGP endpoint liveness. Here in 2021, we seem to have

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Hi Aijun, > Stuffing things in the IGP seems like a poor way of determining that there’s > a BGP failure. Wouldn’t BFD be a more appropriate way of determining the > loss of connectivity? Or aggressive BGP keepalive timers? > [WAJ] For BFD, you need to configure between each pair of them to

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Hi Aijun, > [WAJ] We just want to avoid such silent discard behavior, especially for the > scenario that there is BGP session run on such failure prefix. Stuffing things in the IGP seems like a poor way of determining that there’s a BGP failure. Wouldn’t BFD be a more appropriate way of

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Hi Aijun, > > There are two scenarios as introduced by Gyan: one is the node > failure(Scenario 1), and another is the link failure(Scenario 2). > > For scenario 1, also when all ABRs can’t reach the specified address, it is > not efficient to advertise all of other detail prefixes when only

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Gyan, If I understand the purpose of this draft, the point is to punch a hole in a summary so that traffic is redirected via an alternate, working path. Rather than punch a hole, why not rely on existing technology? Have the valid path advertise the more specific. This will attract the

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

Hi Shraddha, > 8) Section 4.2. You write that an implementation "considers cumulative > bandwidth of the parallel links while arriving at the metric for the link”. > This seems a bit vague. I think you’re trying to say that in interface group > mode the bandwidth of an adjacency is the sum

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

> > Out of curiosity as this is not a secret - What are your default min delay > normalization timers (if user does not overwrite with their own). Likewise > how Junos or Arista normalizes it today ? > > Thx, > R. > > On Wed, Mar 3, 2021 at 7:41 PM Peter Psenak <m

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

Peter, >> There are several link types in use that exhibit variable delay: satellite >> links (e.g., Starlink), microwave links, and ancient link layers that >> deliver reliability through retransmission. >> Any of these (and probably a lot more) can create a noticeable and >> measurable

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

Peter, >> Link delay was dynamic before this draft. As William mentioned, TWAMP can >> already be used to provide a dynamic measurement of link delay. That, >> coupled with the link delay metric already gave us dynamic path computation >> requirements and the possibilities of oscillation

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

Hi William, > 1) I’ll start with the title: there is MUCH more here than bandwidth > constraints. Perhaps this should be generalized somehow? Sorry, I don’t have > a constructive suggestion. > [William] Agree. We are introducing few ‘definitions’ for a bandwidth based > Flex-Algo, along with

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

Robert, > Constructing arbitrary topologies with bw constrain is useful work. For > example I want to create a topology without links of the capacity less then 1 > Gbps. All cool. Of course if I have a case where two nodes have 10 L3 1Gbps > links nicely doing ECMP I will not include those

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

Hi William, Gyan, Robert, Tony, et. al., Please permit me to wax a bit philosophic here. William is exactly correct that the goal is not to make FlexAlgo deal with reservations like RSVP does. Without some kind of setup protocol or global computation, that’s simply not possible. Moreover

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

t regards, > Yali > > -Original Message----- > From: wangyali > Sent: Thursday, February 25, 2021 1:24 PM > To: Tony Li > Cc: lsr@ietf.org; Huzhibo ; Aijun Wang > ; Tianran Zhou > Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt > >

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

Hi William & co-authors, Thank you for your contribution. It’s definitely interesting. As bandwidth management is one area where FlexAlgo lags legacy traffic engineering, this is definitely one small step in the right direction. But I have many comments… 1) I’ll start with the title: there

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi Yali, Thank you for your reply. More comments... > Given this, what is it that you’re trying to accomplish? You’ve called this > a ‘multi-flooding instance’, but it’s very unclear about what that means. > You say that multiple MFIs exist within a single IS-IS instance. >>> Yali: The

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Hi, Thank you for contributing your draft. I’m writing because I’m having trouble understanding the motivation for this work. First off, I do NOT want to argue about carrying unnecessary information in IS-IS. IMHO, it is unmitigated evil and an attempt to destroy the viability of the

Re: [Lsr] A review of draft-ietf-lsr-isis-ttz

Hi Adrian, > On Feb 13, 2021, at 12:34 PM, Adrian Farrel wrote: > > I have some pretty strong opinions on the idea of a single node > abstraction. The main challenge comes when there is a partial failure in > the zone such that the zone is partitioned (or the path between two > zone neighbors

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

> Can't we associate multiple Flex-Algorithms with one >> loopback address, which means we want to reach the loopback address through >> different paths? Pragmatically, this is not a big deal. Most implementations allow many loopback interfaces, so this just costs a single /32 or /128.

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

I support adopting this draft. Traffic engineering without MPLS? Yes, please. Tony > On Dec 1, 2020, at 1:12 PM, Acee Lindem (acee) > wrote: > > This IP Flex Algorithm draft generated quite a bit of discussion on use cases > and deployment prior to IETF 109 and there was generally

Re: [Lsr] Discussion on draft-wang-lsr-hbh-process-00

> Q1: are you using this information to determine the routing to the network? > On one hand, such advertisement does not effect on the normal SPF computation > and may be useful for traffic engineering. For example, for IOAM service, if > the HbH Processing Action of Node/Link is assigned to

Re: [Lsr] Prefix Unreachable Announcement Use Cases

>> And how would that help connectivity restoration ? >> [WAJ] This action will trigger the path protection procedures, which will >> divert the traffic to other backup path. This seems to be making some major assumptions about how path protection features operate. Those assumptions need to

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Ron, This is nice. It makes it clear that constraint based path computation need not have MPLS overhead for those that don’t want it. One thing that you don’t talk about is how this gets used, tho that may be blindingly obvious: you’ll need all nodes placing their prefixes in the RIB/FIB,

Re: [Lsr] I-D Action: draft-dontula-lsr-yang-dynamic-flooding-03.txt

draft-dontula-lsr-yang-dynamic-flooding-03.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > >Title : YANG Data Model for Dynamic Flooding >Authors : Srinath Dontula >

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi Bruno, > At this point, area proxy spec is clear with regards to nominal behavior. So > indeed we are discussing error handling / transitions. (and thank you for > considering those cases, much appreciated). > > From memory, my understanding is the area proxy nominal behaviour requires:

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi Bruno, > “A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an > Outside Router. » > Agreed (so far) > > “A Level 2 LSP with a source system identifier that is found in the Level 1 > LSDB MUST NOT be flooded to an Outside Router.” > I’m not sure to agree. > If that

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi Bruno, Thank you for your comments. > 1) > OLD: The >advertisement in the Proxy LSP informs the remainder of the network >that packets directed to the SID will be forwarded by one of the >Inside Edge Nodes and the Area SID will be consumed. > > NEW: > The >advertisement in

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

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

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

; Date: September 2, 2020 at 7:35:25 AM PDT > To: "Tony Li" , "Gyan S. Mishra" > , "Gyan Mishra" , > "Vivek Ilangovan" , "Sarah Chen" > > > A new version of I-D, draft-ietf-lsr-isis-area-proxy-04.txt > has been successfully s

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

Hi Huaimo, > It seems that splitting L1 area A1 into two L1 areas A11 and A12 cannot > be automated without people's planning. Some people need to spend their time > in deciding where is the boundary between the two areas and selecting a > router in the backbone domain for Attach bit for

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

Hi Huaimo, > Assume that a big L1 area (say Area A1) is connected to backbone domain. > Let us compare TTZ and Areas for scalability. > > Using TTZ, we need two steps below: > 1) configure a piece of Area A1, named P1, as a zone; and > 2) transfer P1 to a virtual node using

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

Hi Xuesong, > Apologies first if I have missed any history of this discussion. But I’m not > sure that we have to evaluate whether a method is “optimal” before WG > adoption. Why not adopt some alternative solutions and leave the choice to > industry/market? First off, this is engineering,

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

Hi Huaimo, > > The question I and others have asked is “what can we do with zones that > > cannot be done with areas?”. > [HC]: IS-IS TTZ or say Zone is one of a few drafts which > experiment/explore new ways for scalability. These new ways may be simpler > and have some other features.

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Les, > The statement “the … Prefix SID does NOT have the semantics that we want and > causes deleterious side-effects” is FALSE. Ahem. I disagree. No need to be rude about it. > There is an alternative here: > > Given that there isn’t any defined use case for the Area Prefix/SID, you

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Les, > [Les:] Thanx for clarifying this. A careful reading of the draft supports > what you say, but as this point could be easily overlooked it might be worth > emphasizing this in the draft. Noted and enhanced. > We do NOT require that the Area Leader candidates have identical >

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi Les, > [Les:] Any one of the IERs can be elected Area Leader, therefore all of them > have to be configured with the Area Prefix and associated SID. The Area Leader may not be an IER. In fact, in an important use case for us, the area is a leaf-spine topology. The Area Leader is one of

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Les, > As per the draft: > > Area Proxy TLV is advertised by IERs in their L2 LSP. > Area Proxy TLV is NOT advertised in the Proxy LSP. > So how do the OERs become aware of the > > “prefix and SID that represents the entirety of the Inside Area to the > Outside Area” > > ??? > > I

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi Les, > You have chosen to assign a prefix as the “Area Destination”. Are you sure you have the right document? The word “Destination” does not appear anywhere within https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03

[Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

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

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

I have reviewed the change in -10 and it seems fine to me. Objection withdrawn. I support publication. Tony > On Aug 17, 2020, at 4:47 PM, tony...@tony.li wrote: > > > >> This begins a 2 week WG Last Call, ending after September 1st, 2020, for >> draft-ietf-lsr-flex-algo >> >>

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Les, There is no TLV called the Min Unidirectional Link Delay. If the document had said “The min delay of the Min/Max Unidirectional Link Delay” then there would be no confusion. Instead, it is the sloppy writing of ignoring the full name of the TLV that has created ambiguity. Now, Peter

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Robert, Thank you, exactly. We just need a clarification of the document. I don’t understand why this is such a big deal. Tony > On Aug 18, 2020, at 9:22 AM, Robert Raszuk wrote: > > Les, > > I think this is not very obvious as Tony is pointing out. > > See RFC 8570 says: > >

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Hi Peter, > section 5.1 of the draft-ietf-lsr-flex-algo says: > > Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app]. > > We explicitly say "Min Unidirectional Link Delay", so this cannot be mixed > with other delay values (max, average). The problem is that that does not

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

> This begins a 2 week WG Last Call, ending after September 1st, 2020, for > draft-ietf-lsr-flex-algo > > https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/ Hi, I’d like to raise an objection. Recently, I requested (and I thought that Peter agreed to) a clarification of the Min

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

Hi Peter, The flex-algo draft mentions "Min Unidirectional Link Delay as defined in [RFC7810 ]". When reading RFC7810, I found two Sub-TLVs: 4.1. Unidirectional Link Delay Sub-TLV 4.2. Min/Max Unidirectional Link Delay Sub-TLV

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

Hi Peter, >> The flex-algo draft mentions "Min Unidirectional Link Delay as defined in >> [RFC7810 > >]". When reading RFC7810, I found two >> Sub-TLVs: >> 4.1. Unidirectional Link Delay Sub-TLV 4.2. Min/Max

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

Peter, >> . The existing description in section 5.1 indicate that legacy encoding >> (RFC7810 and RFC5305) is used for link attributes. That is not correct based >> upon section 11. To avoid ambiguity can an explicit reference be added for >> [I-D.ietf-isis-te-app]? > > > well, section

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi Les, > 1)Invent a new type of SID which is associated with an area. > In this case some variation of encodings defined in V2 of the draft are > appropriate. But these aren’t backward compatible, which operators clearly want. > 2)Use a reachable address to get to the area. That address

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Les, > Not sure why this needs to be explained. Because we are not communicating well. We are each making unstated assumptions that do not mesh. When we do not communicate, it’s time to double check the basics. > Whether you are doing label forwarding or IP forwarding, the path of the >

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Les, > There then remains the question as to whether the “Area Prefix” is anycast > or unicast i.e., is it common to all IERs or is it unique to whomever gets > elected Area Leader? > > Does it matter? We have no clear semantics for this prefix. A difference that > makes no difference is

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Les, > This would make the Area Prefix mandatory for Area Proxy, which is not > desired. We would prefer it to remain optional and thus part of the Area SID > sub-TLV. > > [Les2:] You can advertise the Area Prefix in an optional sub-TLV – just as > you did with the Area SID. That is what I

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Les, > a)Advertise the “Area Prefix” in the Area Proxy TLV – much as we do a > router-id today in the Router-ID TLV. This would make the Area Prefix mandatory for Area Proxy, which is not desired. We would prefer it to remain optional and thus part of the Area SID sub-TLV. > b)The

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi Bruno, > > [Bruno] Agreed so far. > Do we agree that draft-ietf-lsr-isis-area-proxy uses the SID/Label sub-TLV? > We both agree that this sub-TLV has no mention of the global flag nor the > routing algoto be used. So far, we do NOT have agreement on that. Your argument yesterday

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

Hi Robert, > How about we first define an "Area Prefix" (IP address being a property of an > area) then assign SID to it ? That’s effectively what Bruno is proposing. It adds some additional configuration and management overhead. Do you think it’s worthwhile? > How odd it may sound I

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

Hi Acee, > [Acee] I know you guys have all thought about this a lot more than myself. > However, I’d envisioned this new Area SID as taking one to the closest entry > to the abstracted area. The next SID in the stack would either take you to a > destination inside the area or would use the

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

the goal is to > improve interop with existing/legacy L2 nodes so this may be valuable in the > draft. This point could be pushed to a deployment consideration section if > you don’t want any impact on the protocol extension. > > Thanks, > --Bruno > > (*) Assuming th

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

Hi Bruno, Thank you for your comments. > On Jul 30, 2020, at 9:22 AM, bruno.decra...@orange.com wrote: > > Hi Tony, > > Thanks for the updated draft. > > “ The Area SID Sub-TLV allows the Area Leader to advertise a SID that >represents the entirety of the Inside Area to the Outside

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

> Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt > Date: July 25, 2020 at 6:46:05 PM PDT > To: "Vivek Ilangovan" , "Sarah Chen" > , "Gyan S. Mishra&quo

Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo, > > “reducing the service interruption, making operations to be simple, and > so on” > does not require introduction of zones. We can already do so using areas – > including merging/splitting of an area. > > [HC]: Smooth merging/splitting of an area seems not reduce the

Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo, > 1). It seems that Area Proxy can not be amended to IS-IS TTZ. IS-IS TTZ > abstracts a zone to a single node. This abstraction is supported by the > extensions to IS-IS, and some of these extensions are not defined in Area > Proxy. For example, the extensions for the edge nodes

Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo, > 1). It seems that Area Proxy can not be amended to IS-IS TTZ. I feel that this is somewhat imprecise. From my perspective, our attempts to collaborate have been hampered by governmental regulations that are wholly out of our control. The suggestions that I’ve made for

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

Hi Les, > Again, the subTLVs of the area proxy TLV are for the coordination of the > Inside Area. The Area Proxy TLV appears in the Inside Node’s normal LSP. > > The Proxy LSP is for informing the Outside Area. > > [Les:] Understood – but I do not see why this requires you to advertise the

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

Hi Les, > The new definitions in the latest version in the draft are very close to what > we discussed in the earlier thread – so this looks pretty good to me. Excellent, thanks. > I still have some concerns regarding the Area Segment SID. > You propose to advertise this in two places: >

Re: [Lsr] Request WG adoption of TTZ

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

Re: [Lsr] Request WG adoption of TTZ

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

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.

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

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

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

Hi all, The authors are on-board with this round of suggestions from Les. Could I get a review by one more of our Designated Experts before we update the draft? Thanks, Tony > On Jun 29, 2020, at 3:07 PM, Les Ginsberg (ginsberg) > wrote: > > Tony – > > Inline. &

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

Hi Les, > On Jun 29, 2020, at 2:13 PM, Les Ginsberg (ginsberg) > wrote: > > Tony – > > OLD: > 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV > > 2)Inside Node TLV - Top level TLV > > 3)Area Proxy TLV - Top Level TLV with optional sub-TLVs: >Sub-TLV Area Proxy

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

Hi, The authors have conferred and we would like to propose the following changes: - The semantics of the Inside Node TLV will be folded into the Area Proxy TLV. - The Area Proxy TLV will have its scope expanded to include pseudonodes. - No change to the Area Segment SID TLV encoding.

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

Hi Hannes, Thanks for your comments. We will propose an alternate encoding. Tony > On Jun 25, 2020, at 10:47 AM, Hannes Gredler wrote: > > Hi Tony, > > I do share Les’ concerns on burning top-level 8-bit code point space at this > point. > > At this point it is not me to judge wether

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

Chris, Thank you for your comments. We will figure out how we would like to proceed. Thanks, Tony > On Jun 24, 2020, at 5:17 PM, Christian Hopps wrote: > > > >> On Jun 21, 2020, at 12:50 PM, tony...@tony.li wrote: >> >> >> Les, >> >>> We don’t have to resolve this now. >>> One of my

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

Les, > We don’t have to resolve this now. > One of my motivations for sending this was related to Early Allocation of > code points. Since you have already asked once, I am assuming that if WG > adoption is achieved it will be swiftly followed by an early allocation > request – and as one of

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

Hi Les, > I am not yet overly enthused about approaches which promote non-hierarchical > network architectures. But it seems clear that there is interest in deploying > non-hierarchical solutions and both drafts present solutions > which merit further evaluation. I think that there’s some

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

Hi Les, > Putting the Inside Node TLV aside for the moment, it would seem to me to be > advantageous (in a modest way) to have all information relating to Area Proxy > contained in one advertisement. Using Router Capabilities TLV would > accomplish that. I agree that the information should

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

Hi Les, Thank you for your comments. Please see my comments inline. > draft-li-lsr-isis-area-proxy-06 currently proposes the use of one new > sub-TLV of Router Capabilities TLV and three new top level TLVs It should probably be noted that the Area Segment SID is somewhat orthogonal to

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

Tony, > If we rely on controller fixing LPM as well under failures then really, who > needs IGPs anymore anyway except for bunch of loopbacks and SPF for the > controller to do all the FIB work and hence discussions like high hierarchies > or anisotropic routing are largely superfluous me

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

> On Jun 15, 2020, at 10:56 AM, Tony Przygienda wrote: > > PNNI had transit areas in hierarchy working but the trick was connection > setup cranck-back. Such a thing would work for RSVP or any of the stateful > connection setups but alas, this is not fashionable right now. Unfortunately, >

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

Hi Robert, > > It’s very clear that this is inadequate. > > Doesn't this really depend how you architect multiple levels ? Sure you have > some physical topology - but it seems to me that the trick is in properly > laying out levels on top of them and between them. The very pragmatic

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

Hi Henk, > It's not so clear to me, sorry. > Does anyone have an example (link or jpg) of a (sensible) topology > that would not work with multiple levels of hierarchy, but works > nicely/better with area-proxies (or FRs) ? Just curious. Certainly. Draw a 3x3 grid with nodes at each

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

> On Jun 15, 2020, at 3:45 AM, Henk Smit wrote: > > BTW, personally I think the proper solution to scale IS-IS to larger > networks is 8 levels of hierarchy. Too bad that idea gets so little > push from vendors and operators. Hi Henk, It’s very clear that this is inadequate. The structure

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

> Authors, please respond to the list indicating whether you are aware of any > IPR that applies to this draft. I am not a lawyer nor an author, but the area proxy IPR filing (https://datatracker.ietf.org/ipr/4016/ ) may also apply to this draft.

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

> On Jun 10, 2020, at 12:27 PM, Christian Hopps wrote: > > This begins a 2 week WG adoption call for the following draft: > > https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/ > > The draft would be adopted on the Experimental track. > > Please indicate your support or

Re: [Lsr] Thoughts on the area proxy and flood reflector drafts.

Tony, > On Jun 10, 2020, at 9:40 AM, Tony Przygienda wrote: > > You do seem to be carrying as WG member a hot torch for area-proxy for some > reason, that's fine with me, frankly, I had extensive discussions with > customers when DriveNet was being proposed to them (which AFAIS is basically

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

Hi, > I have a question regarding the draft. At the end of section 3, it says if > there is any change in the base topology, the flooding topology MUST be > re-computed. So in case of a link failure in the base topo, it’s possible > that the link is not part of the flooding topology (e.g.

<    1   2   3   4   5   >