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

2021-11-19 Thread Aijun Wang
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

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

2021-11-19 Thread internet-drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : Area Proxy for IS-IS Authors : Tony Li Sarah Chen Vive

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

2021-11-19 Thread Robert Raszuk
Yes that was it. On the part of scalability please observe that operators may configure summaries of their choice. See even if you scope summaries to be /24 only for IPv4 you still suppress lot's of /32s flooding. After all not one mandates that one area must be covered by a single summary. Nice

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

2021-11-19 Thread Les Ginsberg (ginsberg)
Robert – I believe you are referring to https://datatracker.ietf.org/doc/html/draft-swallow-isis-detailed-reach-01 . This doesn’t scale well for shorter summaries – even for IPv4. And for IPv6 I think this is simply not usable. The draft details a potential deployment scheme which depends upon

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

2021-11-19 Thread Robert Raszuk
Hi Les, Ok if you say that this is going to be rate limit for pulses rather then say drop it does sound promising. I think there are two parts to this. One is the definition of reachability vs liveness. For some of us it is the same. Clearly dead node can not be reachable :) The other part is ho

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

2021-11-19 Thread Les Ginsberg (ginsberg)
Robert – For me dealing with “mass failure” is important – but is easily doable. It is basic to IGP flooding that we limit the rate at which new versions of LSPs are generated. Analogous (but not identical) controls can be applied to pulse advertisements – and should be. We will address that in

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

2021-11-19 Thread Robert Raszuk
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 the

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

2021-11-19 Thread Peter Psenak
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. IG

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

2021-11-19 Thread Tony Li
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

2021-11-19 Thread Peter Psenak
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 pro

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

2021-11-19 Thread Tony Li
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

2021-11-19 Thread Tony Li
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

[Lsr] I-D Action: draft-ietf-lsr-ospfv3-srv6-extensions-03.txt

2021-11-19 Thread internet-drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : OSPFv3 Extensions for SRv6 Authors : Zhenbin Li Zhibo Hu

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

2021-11-19 Thread Robert Raszuk
> 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

2021-11-19 Thread Peter Psenak
Tony, On 19/11/2021 04:16, Aijun Wang wrote: Hi, Tony: -Original Message- From: tony1ath...@gmail.com On Behalf Of Tony Li Sent: Friday, November 19, 2021 9:08 AM To: Aijun Wang Cc: Tony Przygienda ; Les Ginsberg (ginsberg) ; Gyan Mishra ; lsr@ietf.org; Christian Hopps ; Acee Lindem