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

Aijun, [WAJ] For SRv6 policy based tunnel, the previous node may not be the > neighbor node. It may locate in other area. > Only in the case of binding SIDs on the penultimate segment endpoint such signalling would perhaps help. In all other cases the information MUST be propagated to the

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

zhibo > Sent: Thursday, November 25, 2021 3:04 PM > To: Shraddha Hegde ; Aijun Wang > ; 'Tony Li' > Cc: 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' > ; 'Christian Hopps' ; 'lsr' > ; 'Acee Lindem (acee)' ; 'Tony Przygienda' > > Subject: RE: [Lsr] 【Responses for Comme

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

pps' ; 'lsr' < > lsr@ietf.org>; 'Acee Lindem (acee)' ; 'Tony Przygienda' < > tonysi...@gmail.com> > *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 > LSR Meeting Minutes > > > > Huzhibo, > > > > Local protection is always executed o

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

: 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' ; 'Christian Hopps' ; 'lsr' ; 'Acee Lindem (acee)' ; 'Tony Przygienda' Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes Huzhibo, Local protection is always executed on the node where failure occurs (for link

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

'Gyan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian Hopps' mailto:cho...@chopps.org>>; 'lsr' mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' mailto:a...@cisco.com>>; 'Tony Przygienda' mailto:tonysi...@gmail.com>> Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】R

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

licy liveness problem. >>> >>> >>> >>> Rgds >>> >>> Shraddha >>> >>> >>> >>> >>> >>> Juniper Business Use Only >>> >>> *From:* Aijun Wang >>> *Sent:* Wednesd

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

gt; address advertised? We will not consider to configure BFD on every >> intermediate points. >> >> >> >> >> >> Best Regards >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> *From:* lsr-boun...@

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

> hayabusa...@gmail.com>; 'Christian Hopps' ; 'lsr' < > lsr@ietf.org>; 'Acee Lindem (acee)' ; 'Tony Przygienda' < > tonysi...@gmail.com> > *Subject:* RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 > LSR Meeting Minutes > > > > *[External Email.

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

Hi Aijun, > #3 > > > [WAJ] It is the IGP advertises the inaccurate information, why let BGP > clear up? Won’t you estimate the IDR experts will resist? > > There is nothing inaccurate in the IGP advertisement. IGP does > precisely what the operator configured it to do. > > [WAJ] It lack some more

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

yan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian Hopps' mailto:cho...@chopps.org>>; 'lsr' mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' mailto:a...@cisco.com>>; 'Tony Przygienda' mailto:tonysi...@gmail.com>> Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IE

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

...@ietf.org] On Behalf Of Shraddha Hegde Sent: Wednesday, November 24, 2021 1:20 PM To: Tony Li ; Aijun Wang Cc: Les Ginsberg (ginsberg) ; Gyan Mishra ; Christian Hopps ; lsr ; Acee Lindem (acee) ; Tony Przygienda Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

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

, November 24, 2021 11:14 AM To: Shraddha Hegde ; 'Tony Li' Cc: 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' ; 'Christian Hopps' ; 'lsr' ; 'Acee Lindem (acee)' ; 'Tony Przygienda' Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes [External Email. Be cautious

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

Hi, Robert: Aijun Wang China Telecom > On Nov 25, 2021, at 07:35, Robert Raszuk wrote: > >  > Hi Aijun, > > Just few points to your note. > > #1 > > > when ABR does the summary work > > In a lot of your emails you keep stating that ABR or IGPs do summarization. > Well that is not true.

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

Hi Aijun, Just few points to your note. #1 > when ABR does the summary work In a lot of your emails you keep stating that ABR or IGPs do summarization. Well that is not true. It is operators which configure the summarization. It is important to recognize this difference. It is also operators

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

Hi, Tony: Aijun Wang China Telecom > On Nov 25, 2021, at 03:59, Tony Li wrote: > >  > > 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

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

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

>> >> >> This is a valid alternate solution to solve the problem at hand IMO. >> >> I would be interested to see if people have use cases where egress >> protection can’t be applied. >> >> >> >> Rgds >> >> Shraddh

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

t;; Christian Hopps ; lsr < > lsr@ietf.org>; Acee Lindem (acee) ; Tony Przygienda < > tonysi...@gmail.com> > *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 > LSR Meeting Minutes > > > > WG, > > > > MPLS egress protection framework RFC

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

*On Behalf Of *Tony Li > > *Sent:* Tuesday, November 23, 2021 10:22 PM > > *To:* Aijun Wang > > *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra > > ; Christian Hopps ; lsr > > ; Acee Lindem (acee) ; Tony Przygienda > > > > *Subject:* Re: [Lsr

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

: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes *[External Email. Be cautious of content]* 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

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

Hi, Tony: From: lsr-boun...@ietf.org On Behalf Of Tony Li Sent: Wednesday, November 24, 2021 12:52 AM To: Aijun Wang Cc: Les Ginsberg (ginsberg) ; Gyan Mishra ; Christian Hopps ; lsr ; Acee Lindem (acee) ; Tony Przygienda Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF

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

Of Shraddha Hegde Sent: Wednesday, November 24, 2021 1:20 PM To: Tony Li ; Aijun Wang Cc: Les Ginsberg (ginsberg) ; Gyan Mishra ; Christian Hopps ; lsr ; Acee Lindem (acee) ; Tony Przygienda Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes WG, MPLS egress

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

, November 23, 2021 10:22 PM To: Aijun Wang Cc: Les Ginsberg (ginsberg) ; Gyan Mishra ; Christian Hopps ; lsr ; Acee Lindem (acee) ; Tony Przygienda Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes [External Email. Be cautious of content] Hi Aijun, I

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

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

> 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

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

Aijun Wang writes: Hi, Chris: 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? I was replying to you saying you wanted to use IGP neighbor

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

> Such results can be deducted from active LSA updates. That is great ! With just a little caveat ... those active LSA updates arriving on ABRs must be triggered by some network event. And that is precisely what we are talking about here. Kind regards, R. On Tue, Nov 23, 2021 at 4:14 PM Aijun

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

Hi, Robert: Aijun Wang China Telecom > On Nov 23, 2021, at 21:22, Robert Raszuk wrote: > >  > >> [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

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

Hi, Chris: 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? Aijun Wang China Telecom > On Nov 23, 2021, at 20:44, Christian Hopps wrote: >

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 can quickly

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

Hi, Robert: Aijun Wang China Telecom > On Nov 23, 2021, at 20:41, Robert Raszuk wrote: > >  > Aijun, > > You are mixing flooding speed with area convergence and with failure > detection. Those are completely orthogonal elements. [WAJ] What I want to express is the overall time from the

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

Aijun Wang writes: Hi, Robert: Aijun Wang China Telecom On Nov 23, 2021, at 20:00, Robert Raszuk wrote: Dear Aijun, [WAJ] Once there is a link/node failure, upon receiving the updated LSA, the ABR That node failure will need to be detected fast.

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

Aijun, You are mixing flooding speed with area convergence and with failure detection. Those are completely orthogonal elements. You questioned use of BFD - all I am stating that there is no easy way to detect failure of the neighbour when LOS trigger is not an option. Thx, R. On Tue, Nov 23,

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

Hi, Robert: Aijun Wang China Telecom > On Nov 23, 2021, at 20:00, Robert Raszuk wrote: > >  > Dear Aijun, > >> [WAJ] Once there is a link/node failure, upon receiving the updated LSA, the >> ABR > > That node failure will need to be detected fast. > > The entire discussion here is

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

Dear Aijun, > [WAJ] Once there is a link/node failure, upon receiving the updated LSA, > the ABR > That node failure will need to be detected fast. The entire discussion here is to do it reasonably fast or as fast as possible. That is why such detection must happen quickly via LOS or BFD

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

such information is not >>>> only BGP, but may be tunnel endpoints. >>>> >>>> Yes, I agree, the light speed is the same. >>>> >>>> >>>> >>>> >>>> >>>> Best Regards >>>>

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

t;> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> *From:* lsr-boun...@ietf.org *On Behalf Of *Robert >> Raszuk >> *Sent:* Tuesday, November 23, 2021 4:40 PM >> *To:* Aijun Wang >> *Cc:* Les Ginsberg (ginsberg) ; G

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

t;> Sent: Tuesday, November 23, 2021 4:40 PM >> To: Aijun Wang >> Cc: Les Ginsberg (ginsberg) ; Gyan Mishra >> ; Christian Hopps ; Tony Li >> ; lsr ; Acee Lindem (acee) ; >> Tony Przygienda >> Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE

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

> As side discussion, I'm getting lost how a SRv6 PE-PE is somehow a drastically different, It is not. You can deliver all of your services using MPLS (as service demux only) over UDP and IPv4 summarized endpoints for a long long time. Contrail was/is doing just that :) Best, R. On Tue, Nov

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

On Tue, Nov 23, 2021 at 9:30 AM Peter Psenak wrote: > Hi Chris, > > On 22/11/2021 22:29, Christian Hopps wrote: > > > > Gyan Mishra writes: > > > >> +1 > >> > >> As I mentioned the requirements for E2E LSP with seamless MPLS or > >> SR-MPLS requires domain wide flooding of host routes. > >> >

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

etf.org *On Behalf Of *Robert > Raszuk > *Sent:* Tuesday, November 23, 2021 4:40 PM > *To:* Aijun Wang > *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra < > hayabusa...@gmail.com>; Christian Hopps ; Tony Li < > tony...@tony.li>; lsr ; Acee Lindem (acee) ; > Tony Przy

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

] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes Aijun, > or lose the fast convergences Putting aside all the drawbacks already discussed, what makes you think that flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 areas would be any faster then send

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

Aijun, *> or lose the fast convergences* Putting aside all the drawbacks already discussed, what makes you think that flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 areas would be any faster then sending BGP UPDATE message(s) across 2-3 RRs ? Assume you need to detect the

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

Hi Chris, On 22/11/2021 22:29, Christian Hopps wrote: Gyan Mishra writes: +1 As I mentioned the requirements for E2E LSP with seamless MPLS or SR-MPLS requires domain wide flooding of host routes. For large operators with a thousands of routes per area you can image if you total that all

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

Hi, Tony: From: lsr-boun...@ietf.org On Behalf Of Tony Li Sent: Tuesday, November 23, 2021 12:52 AM To: Les Ginsberg (ginsberg) Cc: Gyan Mishra ; Christian Hopps ; Aijun Wang ; lsr ; Acee Lindem (acee) ; Tony Przygienda Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112

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

On Mon, Nov 22, 2021 at 4:35 PM Christian Hopps wrote: > > Gyan Mishra writes: > > > +1 > > > > As I mentioned the requirements for E2E LSP with seamless MPLS or > > SR-MPLS requires domain wide flooding of host routes. > > > > For large operators with a thousands of routes per area you can

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

Gyan Mishra writes: +1  As I mentioned the requirements for E2E LSP with seamless MPLS or SR-MPLS requires domain wide flooding of host routes. For large operators with a thousands of routes per area you can image if you total that all up can equate to hundreds of thousands of host routes. 

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

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

No. Summarization and LPM routing inherent to IP based routing and is native to SRv6 and that discussion is completely orthogonal to the requirement for SRv6 IGP extension for IPv6 data plane. One of the major benefits of SRv6 over MPLS is that it does not rely on MPLS exact match and E2E LSP

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

Robert, On 22/11/2021 16:14, Robert Raszuk wrote: All, If you want to know real world scenarios lot's of networks uses separate IGP domains not areas or levels. And yes I do know that 1000s of host routes are present everywhere. MPLS networks build in early 2000s are still running as is.

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

All, If you want to know real world scenarios lot's of networks uses separate IGP domains not areas or levels. And yes I do know that 1000s of host routes are present everywhere. MPLS networks build in early 2000s are still running as is. That means that your unreachable propagation of host

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

+1 As I mentioned the requirements for E2E LSP with seamless MPLS or SR-MPLS requires domain wide flooding of host routes. For large operators with a thousands of routes per area you can image if you total that all up can equate to hundreds of thousands of host routes. That is what we live with

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

Robert, On 22/11/2021 15:26, Robert Raszuk wrote: Peter - the spec does not present full story. Hardly no RFC presents full A--Z on how to run a network or even a given feature. It provides mechanism which can still permit for building LDP LSPs without host routes. So anyone claiming it

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

Peter - the spec does not present full story. Hardly no RFC presents full A--Z on how to run a network or even a given feature. It provides mechanism which can still permit for building LDP LSPs without host routes. So anyone claiming it is impossible by architecture of MPLS is simply incorrect.

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

On 22/11/2021 15:00, Robert Raszuk wrote: it's not a choice, that is an MPLS architectural requirement and it happens in every single SP network that offers services on top of MPLS. If that is considered architecturally incorrect, then the whole MPLS would be. But regardless of

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

Are you saying this draft is useless ? https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ Thx, R. On Mon, Nov 22, 2021 at 2:54 PM Gyan Mishra wrote: > > Correction related to SRv6 as if uses the native IPv6 data plane it does > out of the box support summarization. > > A

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

Correction related to SRv6 as if uses the native IPv6 data plane it does out of the box support summarization. A gap still exists for MPLS and SR-MPLS. Kind Regards Gyan On Mon, Nov 22, 2021 at 7:18 AM Aijun Wang wrote: > > > Aijun Wang > China Telecom > > On Nov 22, 2021, at 18:44, Tony

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

Aijun Wang China Telecom > On Nov 22, 2021, at 18:44, Tony Przygienda wrote: > >  > Just to prop a voice of support to Tony Li's arguments which I have nothing > further to add really. He basically elucidated ;-) with flourishes what I > wrote in my short, terse email I think. > > As he

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

Just to prop a voice of support to Tony Li's arguments which I have nothing further to add really. He basically elucidated ;-) with flourishes what I wrote in my short, terse email I think. As he says "you either make easy choices and get an operationally unstable environment at scale/large

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

Of *Tony Li *Sent:* Sunday, November 21, 2021 10:56 PM *To:* Les Ginsberg (ginsberg) *Cc:* Aijun Wang ; Gyan Mishra ; Christian Hopps ; lsr ; Acee Lindem (acee) ; Tony Przygienda *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes Les, The problem

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

: Aijun Wang ; Gyan Mishra ; Christian Hopps ; lsr ; Acee Lindem (acee) ; Tony Przygienda Subject: 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

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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Tony - 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 have stated

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.

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

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 shou

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

Robert Very good point! As for summarization and SR framework my thoughts are that inter-as or inter-area for both SR-MPLS and SRv6 you could have SR-TE BSID bind candidate path to forwarding plane at each area border hop or AS hop steering source routing E2E engineered path but you would still

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

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

Gyan, You are missing IGP extensions required for Segment Routing (both SR-MPLS and SRv6). If you summarize router information at the area boundary nothing get's propagate outside of area and no one can build SR paths to your area nodes. Game's over. And if you do not summarize you already have

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

On Sun, Nov 21, 2021 at 6:50 AM Robert Raszuk wrote: > > > So we desperately need a viable IGP summarization > > And could you elaborate on how summarization is going to work with > Segment Routing ? Not that I am pushing anyone to go there, but looking > through the window this seems to be the

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

Hi Aditya, > Meanwhile, if you have the ABR as the inline RR changing the BGP NH to > itself and hiding the egress PE, even in that case ingress PE doesn’t need > to worry about the egress PE as long as BGP service route is available with > ABR as NH and let ABR figure out the available egress

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

> So we desperately need a viable IGP summarization And could you elaborate on how summarization is going to work with Segment Routing ? Not that I am pushing anyone to go there, but looking through the window this seems to be the current trend. We rely on leaking as additional information is

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

Hi, Chris: We have considered let BGP send the unreachable information in some situations(Robert is also trying to propose this?) But the key difference is that the host knows the reachability of sever via default route, not via BGP, then leak such information within is not helpful to the

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

> On Nov 21, 2021, at 3:09 AM, Aijun Wang wrote: > > Hi, Tony: > > Aijun Wang > China Telecom > >> On Nov 21, 2021, at 15:17, Tony Li wrote: >> >>  >> Hi Aijun, >> >>> The ABR should do the summary work based on the liveness, right? >> >> >> No. ABRs advertised statically configured

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

Hi, Tony: Aijun Wang China Telecom > On Nov 21, 2021, at 15:17, Tony Li wrote: > >  > 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

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

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

Hi, Aditya: Aijun Wang China Telecom > On Nov 21, 2021, at 12:56, Aditya Kaul wrote: > >  > IMHO BGP(overlay service) should ideally be responsible for dishing out your > cuisine at the particular restaurant, so if your dish isn’t available you > shouldn’t head there in the first place.

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

IMHO BGP(overlay service) should ideally be responsible for dishing out your cuisine at the particular restaurant, so if your dish isn’t available you shouldn’t head there in the first place. Meanwhile, if you have the ABR as the inline RR changing the BGP NH to itself and hiding the egress PE,

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

Hi, Robert: If the ABR know the restaurant are closing now, it can certainly let the driver change to the backup restaurant immediately and avoid the driver waste the miles. Wouldn’t this mechanism give the driver better experiences? Anyway, the unreachable information is rare, controllable.

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

Tony I agree with Peter that the job of the IGP is to provide reachability of all prefixes within the routing domain independent of mask. So the optimization we are looking for is simply trying to make summarization LPM match instead of exact match possible with MPLS within an AS flooding of all

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

Most all operators have not deployed RFC 5283 LDP inter area extension due to the fact that it shifts the seamless MPLS flooding requirement and scalability problem from the RIB/FIB to the LFIB. So we desperately need a viable IGP summarization solution mitigate domain wide flooding of host

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

Robert RFC 5283 provides LDP extension for inter area for LPM summary FEC however in this specification the component prefixes are probated via LDP which is how the LDP inter-area extension is able to support summarization. The problem here is you make IGP scalable with this LDP inter-area

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

> The ABR should do the summary work based on the liveness, right? Really ??? It seems we are as the WG in a form of a disconnect on that one .. rather fundamental to what IGPs are or are supposed to be. One way to look at them is an analogy to road signs which first tell you the direction to

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

Hi, Tony: The ABR should do the summary work based on the liveness, right? If most of addresses within the summary are unreachable/dead as it knows, should it advertise the detail reachable/liveness instead of the misleading summary address? From this POV, we think the ABR or IGP should

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

Aijun, > [WAJ] I agree with you on this point. But how about your comments for such > considerations in > https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-7. > We have considered how to reaction to the mass outrage at the beginning. > That section

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

Hi, Tony: Aijun Wang China Telecom > On Nov 19, 2021, at 23:51, Tony Li wrote: > >  > 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

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

nt:* Friday, November 19, 2021 1:30 PM > *To:* Les Ginsberg (ginsberg) > *Cc:* Peter Psenak ; Tony Li < > tony...@tony.li>; Gyan Mishra ; Christian Hopps < > cho...@chopps.org>; Aijun Wang ; lsr < > lsr@ietf.org>; Acee Lindem (acee) ; Tony Przygienda < > to

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

From: Robert Raszuk Sent: Friday, November 19, 2021 1:30 PM To: Les Ginsberg (ginsberg) Cc: Peter Psenak ; Tony Li ; Gyan Mishra ; Christian Hopps ; Aijun Wang ; lsr ; Acee Lindem (acee) ; Tony Przygienda Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting

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

sberg) < > ginsb...@cisco.com>; Gyan Mishra ; Christian Hopps > ; Aijun Wang ; lsr < > lsr@ietf.org>; Acee Lindem (acee) ; Tony Przygienda < > tonysi...@gmail.com> > *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 > LSR Meeting Minutes

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

, November 19, 2021 12:25 PM To: Peter Psenak Cc: Tony Li ; Les Ginsberg (ginsberg) ; Gyan Mishra ; Christian Hopps ; Aijun Wang ; lsr ; Acee Lindem (acee) ; Tony Przygienda Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes Peter, yes, but it's not specific

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

Peter, > yes, but it's not specific to flat areas. Even in multi-area deployments > the host routing is mandated by MPLS. In the early days of MPLS yes that was the case. But that "mandate" was fixed by Ina, Bruno and Jean-Louis in 2008 :) https://datatracker.ietf.org/doc/html/rfc5283 In

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

Hi Tony, On 19/11/2021 17:55, Tony Li wrote: 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.

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

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

Hi Tony, On 19/11/2021 17:02, Tony Li wrote: 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

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

> I don’t think their is an easy way to solve this in BGP. Can you briefly elaborate why ? What is difficult using BGP native recursion ? Thx, R. On Fri, Nov 19, 2021 at 1:14 AM Gyan Mishra wrote: > > Hi Tony > > The issue exists related to domain wide flooding to support seamless MPLS > E2E

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

Lindem (acee) Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes Hi Aijun, At the risk of Tony confusion… [WAJ] Will not confuse due to the different speaking and wording style. Agreeing with T. Li here (i.e. BFD next-hops) and let me add that AFAIS

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

for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes Hi Aijun, At the risk of Tony confusion… [WAJ] Will not confuse due to the different speaking and wording style. >> Agreeing with T. Li here (i.e. BFD next-hops) and let me add that AFAIS the >> confusion here is that a prese

  1   2   >