Re: [Lsr] Generic metric: application-specific vs application-independent

Robert, > IMO it is a control plane role to at least detect such inconsistency. I understand the desire and I sympathize, but the architecture is not set up for that. The management plane has the information, the control plane does not. Detecting inconsistencies would also require that the

Re: [Lsr] Generic metric: application-specific vs application-independent

Hi Robert, > If architecture enforces you to flood metric to topology mappings then you > don't have the issue of disconnect of control and mgmt plane. Sorry, that’s a bill of goods. Let’s look at the reality, with ASLA. Here’s the example that Les proposed: > [LES:] Node R1 uses metric-

Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Linda, Algorithm types 128-255 are intended to be used with the constraints that are advertised inside of a FlexAlgo definition. I think what you’re proposing is not captured there, so you would need to have a defined algorithm from 2–127. Tony > On Sep 9, 2021, at 9:51 AM, Linda Dunbar

Re: [Lsr] draft-ietf-lsr-flex-algo

> On Sep 15, 2021, at 11:17 AM, Peter Psenak wrote: > >> So, if someone wants to define new constraints (e.g., Linda's >> server/application metrics), they would need to define the semantics and >> encodings similar to what is being done for bandwidth metrics in >> https://datatracker.ietf.o

Re: [Lsr] questions about draft-ietf-lsr-flex-algo-bw-con-01

Hi Linda, > Is it correct that the intent of the draft is to prevent some “elephant > flows” from being placed over certain links? I would phrase it somewhat differently. One of the goals of the draft is to allow network operators to define a minimum bandwidth threshold for a FlexAlgo topo

Re: [Lsr] draft-ietf-lsr-flex-algo

Dear Gentlebeings, > I was more expressing an option about cross vendor support of various metrics > and constraints as part of a given flexible algorithm. I think putting a hard > line that perhaps very useful set of constraints and metrics - documented as > IETF informational doc - even if

Re: [Lsr] draft-ietf-lsr-flex-algo

Robert, > IMHO the magnitude of those will exponentially increase with flex-algo if it > really takes off. Will it be manageable in some networks - perhaps. Well, you’re welcome to your opinion. :-) The basic set of constraints seem very straightforward and, as always, operators are likely

Re: [Lsr] draft-ietf-lsr-flex-algo

Robert, > What harm would it make if someone writes a draft, defines a useful flex algo > on which (the usefulness the LSR WG agrees) say using max propagation delay > across hops as as a metric and allocates IANA type 135 for it ? I’m inferring that you are suggesting that we take a code po

Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi, I’ve said it many times before, in many different venues: “BGP is not a dump truck!”. Is the fact that I didn’t mention the IGPs taken as some indication that they are fair game? No, the IGPs aren’t a dump truck either. We have a clear, unambiguous way of signaling individual system ou

Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

wn that is part of the summary to force immediately > control plane convergence to avoid black hole of traffic during the failure. > > Kind Regards > > Gyan > On Wed, Oct 13, 2021 at 8:48 PM Tony Li <mailto:tony...@tony.li>> wrote: > > > Hi, > >

Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

hts from you on that. But I don’t think arguing that the routing > protocol has no business being involved in this is on the mark. > >Les > > From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of > Tony Li > Sent: Wednesday, October 13, 2021 8:53 PM >

Re: [Lsr] Looking for feedback of using Flex Algo to advertise the 5G edge computing associated metrics

Hi Linda, Thank you for your contribution. I have several comments: 1) I think you could abstract this out from 5G and have a much stronger contribution. If I understand correctly, your goal is to route to optimal instances of anycast load balancers. There’s nothing radio specific about that.

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Les, That’s easy. The summary covers all addresses of all of the nodes (hosts and routers) in the area. It also may cover addresses within the summary that are not currently assigned. This is intentional since by advertising a summary, we gain scalability. The summary provides aggregated reac

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Les, > Why would we then punch holes in the summary for member routers? Just > because we can? > [LES:] No. We are doing it to improve convergence AND retain scalability. You are not improving convergence. You are propagating liveness. The fact that this relates to convergence in the overla

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Robert, > Why would we need to deploy a full mesh of BFD or introduce a new proxy > liveness service if BGP can do all what is needed here with just a few lines > of additional cfg on existing and deployed operating systems ? If you want to address this problem with BGP keep alive timers, th

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Les, > You are not retaining scalability. You are damaging it. You are proposing > flooding a prefix per router that fails. If there is a mass failure, that > would result in flooding a large number of prefixes. The last thing you want > when there is a mass failure is additional load, exacerba

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi Aijun, At the risk of Tony confusion… >> Agreeing with T. Li here (i.e. BFD next-hops) and let me add that AFAIS the >> confusion here is that a presence of a /32 route is used as SSAP liveliness >> AFAIS and that's simply not what IGPs are here for if you consider their >> main job to be

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi Gyan, > On Nov 18, 2021, at 4:13 PM, Gyan Mishra wrote: > > The issue exists related to domain wide flooding to support seamless MPLS E2E > LSP which you end up with all host routes from all areas flooded domain wide > from Core and Agg layers. So a solution to this domain wide flooding i

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi Aijun, > There is no ‘problem’ with the IGP. You seem to want liveness from the IGP. > That’s not a property that it was meant to provide. > [WAJ] The IGP advertises the summary reachability. The overlay service(BGP or > tunnel) established based on this information. But when the endpoint

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi Peter, >>> [WAJ] The problem is arose from the summary action of IGP, why let other >>> protocols solve it? >> There is no ‘problem’ with the IGP. You seem to want liveness from the IGP. >> That’s not a property that it was meant to provide. > > today IGPs provide reachability for the host

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi Peter, > yes, but it's not specific to flat areas. Even in multi-area deployments the > host routing is mandated by MPLS. In these multi-area deployments the host > routes are sent everywhere, updates are triggered regardless of the failure > type. IGPs are effectively providing liveness se

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi Aijun, >> Again, you’re confusing reachability with liveness. A summary address does >> NOT imply liveness. If you have a prefix 1/8, that does not mean that >> 1.1.1.1 is up and will accept a TCP connection or reply to a ping. > > [WAJ] Reachability is not equal to liveness, but the dead

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi Aijun, > The ABR should do the summary work based on the liveness, right? No. ABRs advertised statically configured prefixes for the area. Anything else would cause flap. And it’s purely reachability, not liveness. There can be zero live nodes within an area and the ABR should still advert

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi Aijun, >> No. ABRs advertised statically configured prefixes for the area. Anything >> else would cause flap. And it’s purely reachability, not liveness. There can >> be zero live nodes within an area and the ABR should still advertise its >> summary. > > [WAJ] What the usage of the summar

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi Aijun, > [WAJ] I have explained to Chris the differences between the usage of IGP > unreachable and BGP unreachable at > https://mailarchive.ietf.org/arch/msg/lsr/HBUDX5lcbcrKuPK1R7MbNC-mcGA/ > > BGP、Tunnel etc. overla

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Les, > The problem is that restricting the prefix length does nothing to limit the > number of advertisements that get flooded. In a high-scale situation, when > there is a mass failure, it would lead to a flooding spike. That’s exactly > not the time to stress the system. > > [LES:] As I

Re: [Lsr] WG Adoption Call for "IS-IS Fast Flooding" - draft-decraeneginsberg-lsr-isis-fast-flooding-00

As co-author, I support adopting this draft as a WG document. I favor the experimental track for this. We do not yet agree as to what the content will be. I reserve the right to change my opinion should circumstances change. T > On Nov 22, 2021, at 6:06 AM, Acee Lindem (acee) > wrote: > >

Re: [Lsr] IPR Poll for "IS-IS Fast Flooding" - draft-decraeneginsberg-lsr-isis-fast-flooding-00

Hi Acee, As co-author, I am aware of one IPR filing on this draft: https://datatracker.ietf.org/ipr/5205/ . I am unaware of any other IPR. I find the terms on the above filing objectionable and ask that we design out that portion of the technology. Ton

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Les, > It is not clear to me why having the IGP advertise information that it > already knows is considered an “architectural violation”. It is even less > clear to me since it would not be considered a violation if an operator > didn’t configure a summary and the IGP advertised all the indiv

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

> On Nov 23, 2021, at 6:56 AM, Aijun Wang wrote: > > For BFD configuration, I think central control has less help for the work. > Let’s consider the SRv6 tunnel, would you configure on every intermediate > node to detect the liveness of destination via BFD? Normally, BFD would be configured

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

> [WAJ] What I want to express is the overall time from the failures occur to > the ABR notice it via only IGP procedures. Shouldn’t it be within millisecond > within one area? > > No. Not at all. > > OSPF hello def timer is 10 sec in some implementations I just checked. > > So unless you

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi Aijun, > I object to adding negative liveness to the LSDB because of the scale and > because it adds scale during failures. > [WAJ] If we have no such mechanism, operator should either advertise the host > routes across areas(which has scale problem), or lose the fast convergences > for som

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi Aijun, > If the scale is equal, then I would prefer to see flooding positive > information rather than negative information. Operationally this is key: if > there is a failure and positive information doesn’t propagate, then it’s a > bug that will be found in due course and the operator ca

Re: [Lsr] BGP vs PUA/PULSE

Les, Thank you for clearly articulating your understanding. One more time, with feeling: > [LES:] I am not convinced either side can claim "consensus" in this > discussion. That is a work in progress. 😊 We concur on this point. :) > However, when you say IGPs are (exclusively?) for topo

Re: [Lsr] BGP vs PUA/PULSE

Les, > Summarization is used in the network. > But customer identifies a modest number of key nodes where it wants to detect > loss of reachability ASAP. Unfortunately, customer is unable to assign > addresses which are outside of the summary to these nodes. > Customer assigns admin tags to th

Re: [Lsr] BGP vs PUA/PULSE

Les, > I am not convinced we are going to converge. I concur. I propose that we agree to disagree. > Note that my goal/expectation is not that one of us convinces the other as to > what is “best”. It is simply to get a clearer understanding regarding our > points of disagreement. But I am

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

Hi Les, > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/ > > > Both of them discuss in their respective introductions the motivation – which > is to address scaling issues in deployment scenarios where the ex

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

Les, > And in response to Tony Li’s statement: “…the IETF is at its best when it is > documenting de facto standards” > > 1) I fully believe that our customers understand their requirements(sic) > better than we (vendors) do. But that does not mean that they understand what > is the best so

Re: [Lsr] Using L1 for Transit Traffic in IS-IS

Les, > Here, I am not convinced that there is broad WG consensus that this is a > problem that the IGPs should solve. (If I am wrong on that I presume the WG > members will let me know.) I can’t believe what I’m hearing. The problem that we’re solving is IGP scalability. Your saying that IG

Re: [Lsr] Using L1 for Transit Traffic in IS-IS

Les, > You can’t justify any and all changes by saying “It improves scalability”. Very true. Only the ones that do. Which in this case is accurate. > Right now my opinion is that the nature of the changes are so inconsistent > with the design of the protocol that the badness outweighs the

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

Hi Aijun, > No, I think the WG participations would like to enjoy the interested and > correct direction topics. > One technical considerations is the following: if IGP evolved into this > direction, then the following connections loop diagram is also possible: > L2-L1-L2-L1-L2-L1-…..-L2(back

Re: [Lsr] Using L1 for Transit Traffic in IS-IS

Tony, > The new LSP seems to imply a forklift of the whole network which area proxy > does not require, in fact flood reflection has been carefully constructed to > touch minimum possible amount of nodes in the network and additionally allow > a node-by-node migration. To be accurate, area

Re: [Lsr] BGP vs PUA/PULSE

> On Jan 3, 2022, at 11:23 AM, Christian Hopps wrote: > > And I'm saying if a prefix is important enough to merit a bunch of new > protocol extensions and state, then it's important enough to simply be left > out of the summarization in the first place. > > And then people get what they want

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

> On Jan 10, 2022, at 9:05 AM, Aijun Wang wrote: > > [WAJ] Selecting the most appropriate/optimized application server should base > on the topology information which is routing protocol related. Just because some mechanism wants to use toplogy information does NOT imply that it should be p

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

I object to the adoption of this draft. I don’t think that it’s fundamentally a correct approach. One of the important things that we’ve learned over the years is that we need to build general designs and not simply add new elements and mechanisms for each use case that we think of. I unders

Re: [Lsr] BGP vs PUA/PULSE

Les, > We have received requests from real customers who both need to summarize AND > would like better response time to loss of reachability to individual nodes. > If they could operate at the necessary scale without summarizing they would > have already – so telling customers to simply make

Re: [Lsr] BGP vs PUA/PULSE

Les, > And if customers could do what he suggested then they would not have an issue. > > But there are deployments where what he suggested is not possible – largely I > think because the set of “prefixes of interest” is in itself large. Well, the alleged customers have not come forward to

Re: [Lsr] BGP vs PUA/PULSE

> On Jan 10, 2022, at 4:44 PM, Les Ginsberg (ginsberg) > wrote: > > As BFD sessions are bidirectional we are talking about a Combination of (n,2) > – so in the case of 500 nodes the actual number of BFD sessions network-wide > is 124750. Which sounds terrifying until you realize that it’s

Re: [Lsr] BGP vs PUA/PULSE

Les, > I could be more specific regarding my opinion about various alternatives that > have been mentioned (BFD, OAM, BGP, pub-sub) – but it doesn’t make sense to > me to comment on proposals which have not actually been defined. The proposals have been put forth in adequate detail for a prel

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Aijun, > For the AS boundary use case, do you have other better solution? Is there some way that this could be modeled as a normal link instead of a stub link? In any case, I am not responsible for coming up with a better solution. The onus is on you to convince us that this is a Good Th

Re: [Lsr] BGP vs PUA/PULSE

Les, > [LES:] I believe some of the alternate proposals are tractable – which is not > to say that I prefer them. > But I don’t want to ask questions like “How do you do this…?” in the absence > of a writeup. I am assuming that if we had a writeup the authors would have > done their best to d

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi Aijun, > Just because some mechanism wants to use toplogy information does NOT imply > that it should be part of the routing protocol. > > In this case, load balancing should be an independent mechanism. If it wants > to peek into the LSDB, that would be perfectly acceptable, IMHO. > [WAJ

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Aijun, > We are trying to reuse the existing mechanism to solve such problem, but as > mentioned in > https://mailarchive.ietf.org/arch/msg/lsr/kTWLct7VgEfOxexdwzwcFS3Ctqc/: This link doesn’t work. > "[WAJ] Reuse the Link TLV that defined in inter-AS-TE-v2/v3 to contain such > informati

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Aijun, > > It would seem to me that if you re-used existing TLVs, you could be adding > subTLVs to carry any additional information. This would probably be a lot > cleaner. > [WAJ] Then we should update RFC5316, RFC5292, RFC3630 etc. It may also > influence the existing deployment. > The

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

> On Jan 12, 2022, at 3:10 PM, Christian Hopps wrote: > > m having a little trouble fully understanding what you're saying here. > > However, I think what is being done is the user configures one router (e.g., > configures "isis passive" on "interfaec Foo0"), and the fact of that > configura

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Aijun, >> Yes, I’m suggesting that you consider a way of using existing TLVs and >> adding subTLVs to them in order to convey the information. >> >> A big point of using TLV encoding in the first place is to provide >> extensibility. It would be a design error not to use it, when appropriat

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

> On Jan 12, 2022, at 3:54 PM, Robert Raszuk wrote: > > What puzzles me in this proposal is why are you insisting on making a stub > link not-so-stubby instead of treating it as a passive interface (as others > already suggested) ? Robert, A pure passive interface results in the node adve

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

> On Jan 12, 2022, at 4:01 PM, Robert Raszuk wrote: > > Very honestly I must have missed that the objective here is to include those > links in the TE constrained computation. You mean MPLS RSVP-TE ? > > Is that so in 2022 ? Robert, It is entirely possible that I have misunderstood the u

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Chris, > This isn't the same as TE information which can be/is based dynamic values on > the router. Are you sure? First, much of the TE information that we have distributed is static (administrative group, SRLG, etc.). The dynamic part has been bandwidth reservation. That still seems appl

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Robert, > On Jan 12, 2022, at 5:06 PM, Robert Raszuk wrote: > > Well if that would be controller based TE computation it seems that these > days BGP-LS (ugh!) would be used instead of IGP flooding to pass that info > around. > > Hence that makes (at least :) two of us pretty puzzled on the

[Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

FYI. This is a better alternative that PUA/Pulse. Tony > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-li-lsr-liveness-00.txt > Date: January 18, 2022 at 5:04:22 PM PST > To: , "Tony Li" > > &g

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Aijun, > If we use pub/sub mechanism, why don’t we accomplish it via the management > system, or controller? > No IGP extension needed then. As I recall, you are the one who posed the original problem. If a centralized solution works for you, then that’s certainly fine by me. > Also no

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Robert, > Do you envision any form of aggregation to happen in the messaging between > ABRs (for both registrations and notifications) ? Well, as always, I try to generalize mechanisms and solutions. So while I don’t see an immediate need or benefit to it, I did write the protocol so tha

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

> On Jan 19, 2022, at 11:38 AM, Tony Przygienda wrote: > > As only observation, if we do this service as suggested I would like to see > not only port & protocol but also the according address of the endpoint > (since it's really that is the SSAP here. > Operationally it's very often desira

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Robert, > Let me perhaps illustrate in two examples what I had in mind. I actually do > see immediate benefit to include it day one both in the spec and in the > protocol: > > *A* ABR locally (from it's own area) received registration requests for 100 > /32s next hops. It knows from re

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Aijun, > You are proposing to use the Out of Band channel to solve the IGP problem. > There are already existing such channel, why we bother IGP to establish new > one? You’re missing the point completely. I’m proposing an entirely new subsystem. That’s architecturally necessary. One of

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Robert, > Ok, this was the intent already. The current text says: > >If an ABR receives a Registration Message for a prefix that is being >injected by a non-attached area, then it should determine the set of >ABRs that are advertising that prefix or less specifics and register >

[Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-01.txt

New version that addresses the comments so far. Tony > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-li-lsr-liveness-01.txt > Date: January 20, 2022 at 9:10:24 AM PST > To: , "Tony Li" > > &g

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Robert, > While perhaps pretty obvious, it would be good to also highlight what > implementation should do in the event of covering prefix changes in the LSDB > if those are to happen after registrations have already gone out. Maybe as > simple as de-register and re-register for the new cov

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Aijun, > [WAJ] Then I think it is not the subject that the LSR should discuss. There > are many modules on the routers. They may all relevant to the IGP modules. > You are trying to accomplish the work that has been done via the management > system, for example https://datatracker.ietf.org

[Lsr] Fwd: New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt > Date: January 21, 2022 at 4:55:01 PM PST > To: , "Chris Bowers" , "Les > Ginsberg" , "Parag Kaneriya" , > "Shraddha Hegde" , , "Tony Li" > , "Tony Przygienda" &g

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Greg, Thank you for your suggestions. > It seems that referencing the multi-hop BFD [RFC5883] in the Introduction > section as the existing mechanism detecting the node liveness can make the > document more thorough. While I have no objection to being thorough, being that thorough would re

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Gyan, > So basically the event notification process done in PUAM / Pulse inband, here > we are using an out-of-band transport protocol QUIC / TCP for the Publisher > RDB registration DB service on the ABRs which advertises the node liveliness > service into the L1 and L2 areas for subscribe

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Greg, > I got to think about the benefits of using reliable transport for > notifications. If I understand the use case correctly, the proposed mechanism > allows for a faster convergence but is supplemental to slower BGP > convergence. If that is the case, it seems that if a subscriber to

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Greg, > thank you for your responses to my notes. I should have been more clear in > explaining the rationale for adding the UDP transport option to the list. > Reliability comes at a cost. If the system already has a mechanism that > guarantees convergence a faster, lightweight though not

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

any of the transport options listed in the document but adding > optional unreliable transport. > > Regards, > Greg > > On Mon, Jan 24, 2022 at 9:16 AM Tony Li <mailto:tony...@tony.li>> wrote: > Hi Greg, > > > > thank you for your responses to my notes.

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Hi Les, Thank you for commenting. > I am not enthused about this solution. Full mesh isn’t appealing at scale. > But I recognize this as an alternative which some might find useful in some > deployments. Is it clear that the full mesh is only at the ABR level? > I also understand why and

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Les, > My precedent is the use Router Capability for advertising FlexAlgo > definitions. This is a service being provided by the area and it seems > equally relevant. Would you prefer a top level TLV? > > [LES:] Flex Algo is a routing calculation being performed by the IGPs who > also adve

Re: [Lsr] BGP vs PUA/PULSE

Hi Aijun, > 1) Consider in the BGP scenario: every PE may receive the routes from other > PEs, right? So, using the PUB/SUB model, every PE should subscribe the status > of the other PEs, right? My understanding is that a PE typically only has tunnels to some other select number of PEs. Yes

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Peter, > we just moved the problem from IGPs to some "other" application. That was the entire point. Hopefully, you see that as a good thing. Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Robert, > If a given PE needs to get all notifications from all other PEs it is > sufficient that it sends to local ABRs a single registration in a form of > 0.0.0.0/0 and be done. If you look a bit more carefully, you will find that registering for 0/0 doesn’t work withou

Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

Hi all, I suggest that we all agree to disagree. Since we cannot make progress, we simply drop all proposals, adopt none of them, and give up. Tony > On Jan 25, 2022, at 6:16 PM, Aijun Wang wrote: > > Hi, All: > > As Peter’s example and Acee’s suggestions, let’s focus on the following >

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Peter, >> > The pulse solution does not suffer from the scale issues. >> It shifts that "suffering" to flood the entire domain with information which >> is not needed on P routers and selectively useful on the remote PEs. > > yes, but how much data? Minimal. It's not an issue, no matter how man

[Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-02.txt

@ietf.org > Subject: New Version Notification for draft-li-lsr-liveness-02.txt > Date: February 3, 2022 at 9:14:47 AM PST > To: , "Tony Li" > > > A new version of I-D, draft-li-lsr-liveness-02.txt > has been successfully submitted by Tony Li, and posted to the > IETF

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Hi Gunter, > Is draft-pkaneria-lsr-multi-tlv intending to look TLVs that are explicitly > restricted to only a single entry? Usually, if a TLV has been defined to only have a single entry, it’s for a good reason. We are not intending to override an author’s explicit and sensible restriction

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Hi Peter, >> I believe that your assumption is that the FAD for a single algorithm can >> never grow bigger as a 256 octets. > > yes, that is indeed a limitation. Perhaps we should address it somehow? Coders have to deal with overflow conditions on day one, whether people are hitting them ye

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Robert, > If FlexAlgo is adopted, then we should expect that it will get stressed and > that further conditions will be added to a FAD. The problem will only become > worse the more success that FlexAlgo has. It sounds to me like you want > FlexAlgo to fail, which seems strange. > > Well I ha

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Peter, > I believe there is a subtle difference between what each of you is saying: > > a) Tony says that there may be many constraints used for a particular > flex-algo, so that we may not be able to fit them in a single FAD Sub-TLV. I > agree, we better address that. I will update the flex-

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Hi Peter, > I would prefer to address the "else clause" in a following way: > > a) any FAD sub-TLV MUST only appear once in a the FAD definition for a given > algorithm from a given source > > b) in case the FAD sub-TLV appear multiple times, the values in the sub-TLV > in the first occurre

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

> On Mar 4, 2022, at 8:50 AM, Peter Psenak wrote: > > not at all. > > I just don't want to get into business of merging info from several FAD's > sub-TLVs of the same type unless there is a compelling reason to do so? So > far I have not seen any. Asking for 100s of excluded SRLGs in the FAD

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Peter, > Once we get into FAD Sub-TLV overflow business, we would have to define, for > each FAD sub-TLV, whether multiple of them can exist and how to resolve > conflicts if only one is allowed. For all existing ones, I can only think of > SRLG to be the candidate for multiple. > > I'm fine

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Peter, > the combination is the (a) problem and that will be fixed. We are talking > problem (b) only now. Ah, my apologies, I was unclear on the applicability of your statements. > I'm not trying under-specify how to deal with overflow - we need to specify > it, no disagreement there. I

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

Hi Aijun, > Thanks for your clarification of the NLP mechanism during the meeting. > 1. Regarding to the PUB/SUB model within IETF, there are already some of > them: > 1) https://datatracker.ietf.org/doc/html/rfc8641 > (Subscription to YAN

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

Hi Aijun, > Let’s focus on the comparison of NLP and PUAM(Prefix Unreachable Announcement > Mechanism): > For NLP, the receiver should register the interested prefixes first. Once the > node fails, all the receivers(normally the nodes within one area) that > register such interested prefixes w

[Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt

gin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-li-dynamic-flooding-04.txt > Date: March 27, 2018 at 9:01:30 AM PDT > To: "Tony Li" > > > A new version of I-D, draft-li-dynamic-flooding-04.txt > has be

Re: [Lsr] FW: New Version Notification for draft-ginsberg-isis-rfc7810bis-00.txt

I don’t see the big deal in having the WG name in the draft title, even for category 1 documents. It’s only the name of the draft and the fact that it is protocol specific doesn’t really need to be called out at that level. People who read the document will certainly figure it out. Tony On Wed

Re: [Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt

Hi Peter, Thank you for your comments. > while I appreciate the flexibility associated with the centralized > computation of the flooding topology, it has some drawbacks as well: > > 1. "flooding topology" must be flooded. This makes the flooding dependent on > the flooded data itself. Abso

Re: [Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt

Acee, > I think a distributed flooding algorithm is more robust and will converge > faster when there more than one concurrent failure in the flooding topology. No doubt. However, we do not normally attempt to protect against multiple concurrent failures. Regardless of how the flooding topolo

[Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-05.txt

t; > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-li-dynamic-flooding-05.txt > Date: June 28, 2018 at 8:42:07 AM PDT > To: "Peter Psenak" , "Tony Li" > > > A new version of I-D, draft-li-dynamic-flooding-05.txt > has been su

[Lsr] Fwd: New Version Notification for draft-li-area-abstraction-00.txt

New Version Notification for draft-li-area-abstraction-00.txt > Date: June 29, 2018 at 3:28:05 PM PDT > To: "Tony Li" > > > A new version of I-D, draft-li-area-abstraction-00.txt > has been successfully submitted by Tony Li and posted to the > IETF repository. &

<    1   2   3   4   5   6   >