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

From: "Aijun Wang" <[email-masked]>
Date: Wed, 17 Nov 2021 11:36:46 +0800

Hi, 

The followings are the responses for the comments on PUAM draft( <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08)

Les:      The comment I want to make, I think the discussion on the

          list highlighted the fact that there's an open question,

          independent of whether we use the prefix unreachable

          draft or the Event Notification draft, as to whether this

          problem should be solved by the IGP or whether it should be

          solved by BGP, or in some other way. And I think the logical

          way to proceed on this is to get the consensus of the working

          group as to whether an IGP solution is desired first, then

          after we reach consensus on that, then we can start talking

          about which approach is the better approach. Which one

          should be adopted?

【WAJ】The problem is occurred due to the summary action by the ABR router in IGP, it should be solved by IGP itself.

As discussed earlier on the list, the possible use case is not limited to BGP fast convergence.

Based on the above considerations, it is not appropriated solved via BGP. 

Chris H:  Chair hat on. You've been asking for adoption for a while.

          The event notification draft is new. I agree with Les that

          in a perfect world that would be the case, but asking for

          adoption is one way to answer the question. It may be not

          the perfect way to answer that question, but it is one way.

          I agree without my chair hat on, I'm not sure we need this,

          but it's not for me to say by fiat. Acee did put something

          out on the list to try to engage people again. And I don't

          think a lot got said.

【WAJ】we have several round discussions for this topic but there is always no conclusion at the end. 

       Can the expert that reluctant to accept the new idea to give some specific questions/problems for the current solution?

      Or else it is not helpful for the solve of the existing problem.

       Initiate the adoption call maybe the best way to let the experts express their opinions? 

       We would like to hear the specific and detail comments for the current solutions, not just general comments.

Acee:     I didn't see much support other than from the authors. I

          saw one non-author support on the event notification. 

【WAJ】Does anyone not agree what we analyze/summarize at the presentation material for the two solutions? (https://datatracker.ietf.org/meeting/112/materials/slides-112-lsr-05-puam-stublink-00.pdf, the 5th slide)

Chris:    Everyone has a right to ask for an adoption. Everyone has a

          right to say we shouldn't adopt this and there are the

          reasons. We've let people to express opinions, without

          seeing a lot of negative opinions it's hard not to just grant

          the adoption call.

【WAJ】I agree.

Tony P:   I think this is all making a trash can out of the IGP. One

          possible solution is to ban or encouraged maybe everyone with

          these kind of suggestions to go towards the service instance

          stuff or whatever we call it, which I think is a good idea.

          Just run a power line up and much lower priority. Don't trash

          the main protocol that holds the whole thing together.

【WAJ】Do you consider the deployment complexity for independent service instance to transfer such thing? And also the interaction on the device among the main IGP instance and the service instances? It’s the fault of the main protocol, and should be solved by the main protocol.

Chris:    Great comment for the adoption call. As a WG member, I agree.

From: [email-masked] <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, November 17, 2021 2:56 AM
To: [email-masked]
Subject: [Lsr] IETF 112 LSR Meeting Minutes

The IETF 112 LSR Meeting Minutes have been uploaded. Thanks to Yingzhen Qu for taking them!!!

https://datatracker.ietf.org/meeting/112/materials/minutes-112-lsr-00

The IETF 112 LSR Meeting MeetEcho recording is available here:

https://play.conf.meetecho.com/Playout/?session=IETF112-LSR-20211111-1200

Thanks,

Acee

---

From: Christian Hopps <[email-masked]>
Date: Wed, 17 Nov 2021 09:59:14 -0500

> On Nov 16, 2021, at 10:36 PM, Aijun Wang <[email-masked]> wrote:
> 
> Hi, 
>  
> The followings are the responses for the comments on PUAM draft(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08)
>  

This makes it seem like I'm saying that I agree with your response. I'd strike that "As a WG member, I agree".

Thanks,
Chris.

---

From: Yingzhen Qu <[email-masked]>
Date: Wed, 17 Nov 2021 08:11:22 -0800

Hi Chris,

Put the content together, my understanding is that “As a WG member, I agree with Tony P’s comments about using transport instance.” Please correct me if I misunderstood you, and I’ll update the minute.

Thanks,
Yingzhen

> On Nov 17, 2021, at 6:59 AM, Christian Hopps <[email-masked]> wrote:
> 
> 
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Aijun Wang <[email-masked]>
Date: Thu, 18 Nov 2021 07:09:59 +0800

Hi, Christian:

Would you like to describe how to solve the problem via using the transport instance? The detail interaction process within the node and the deployment  overhead analysis?
If there is no such information, it is doubt whether your judgment is correct or not, it is also unconvincing. Welcome also Tony gives the explanation before making the assertions, as we done for PUAM solution.

Aijun Wang
China Telecom

> On Nov 17, 2021, at 22:59, Christian Hopps <[email-masked]> wrote:
> 
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 17 Nov 2021 19:31:46 -0500

With MT separate control plane common data plane or Multi Instance separate
control plane and separate data plane.

In both transport instance styles peeling the event notification into a
separate instance or topology how do this discrete transport instance or
topology interact with the main instance or topology.

The answer is it can’t.

As Aijun as well as Peter have discussed the problem this is an inherent
issue with use of summarization and these are two solutions to solbe this
real world issue to make summarization viable for operators.

Gyan
Verizon Inc

On Wed, Nov 17, 2021 at 6:10 PM Aijun Wang <[email-masked]>
wrote:

> Hi, Christian:
>
> Would you like to describe how to solve the problem via using the
> transport instance? The detail interaction process within the node and the
> deployment  overhead analysis?
> If there is no such information, it is doubt whether your judgment is
> correct or not, it is also unconvincing. Welcome also Tony gives the
> explanation before making the assertions, as we done for PUAM solution.
>
>
> Aijun Wang
> China Telecom
>
> >> The followings are the responses for the comments on PUAM draft(
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08
> )
> >>
> >> 【WAJ】The problem is occurred due to the summary action by the ABR
> router in IGP, it should be solved by IGP itself.
> >>       Can the expert that reluctant to accept the new idea to give some
> specific questions/problems for the current solution?
> >>       We would like to hear the specific and detail comments for the
> current solutions, not just general comments.
> >>
> >> 【WAJ】Does anyone not agree what we analyze/summarize at the
> presentation material for the two solutions? (
> https://datatracker.ietf.org/meeting/112/materials/slides-112-lsr-05-puam-stublink-00.pdf,
> the 5th slide)
> >>
> >> 【WAJ】Do you consider the deployment complexity for independent service
> instance to transfer such thing? And also the interaction on the device
> among the main IGP instance and the service instances? It’s the fault of
> the main protocol, and should be solved by the main protocol.
> >>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 18 Nov 2021 01:08:37 +0000

I think the discussion about using a separate instance is a distraction and we shouldn’t be debating that right now.

The legitimate question is whether folks see it as appropriate to have an IGP based solution for the problem. How to do it using the IGP is only a meaningful question if we are considering using the IGP at all.

In that context…it is clear that it is a legitimate use of the IGP to advertise summary addresses.
It is also a legitimate use of the IGPs to advertise all the individual prefixes covered by a summary if the network operator chooses not to summarize.
It therefore seems to me to quite legitimate for the IGP to advertise both a summary and changes to the reachability of individual destinations covered by the summary. This is still a type of prefix reachability advertisement.

It would help me if the folks who think this is NOT a legitimate use of an IGP could explain why in the context of the above.

Thanx.

   Les

From: Lsr <[email-masked]> On Behalf Of Gyan Mishra
Sent: Wednesday, November 17, 2021 4:32 PM
To: Aijun Wang <[email-masked]>
Cc: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; Christian Hopps <[email-masked]>; Tony Przygienda <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

With MT separate control plane common data plane or Multi Instance separate control plane and separate data plane.

In both transport instance styles peeling the event notification into a separate instance or topology how do this discrete transport instance or topology interact with the main instance or topology.

The answer is it can’t.

As Aijun as well as Peter have discussed the problem this is an inherent issue with use of summarization and these are two solutions to solbe this real world issue to make summarization viable for operators.

Gyan
Verizon Inc

On Wed, Nov 17, 2021 at 6:10 PM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Christian:

Aijun Wang
China Telecom

> On Nov 17, 2021, at 22:59, Christian Hopps <[email-masked]<mailto:[email-masked]>> wrote:
>
> 
>
>> On Nov 16, 2021, at 10:36 PM, Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Hi,
>>
>> From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Acee Lindem (acee)
>> To: [email-masked]<mailto:[email-masked]>

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr
--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Tony Li <[email-masked]>
Date: Wed, 17 Nov 2021 17:24:06 -0800

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 reachability throughout the network.

Reachability and path selection is the responsibility of the IGP, not liveness.

Should we not advertise a summary because a single address in the summary is not assigned?  No, it is up to correspondents to determine if the address is populated.

Should we punch holes in our summary for unassigned addresses?  No, that would kill scalability.

Should we punch holes in our summary for host failures?  That would kill scalability too and drag the IGP out of its role. 

Why would we then punch holes in the summary for member routers?  Just because we can?  Should we corrupt the architecture just because we can?  There are other, architecturally appropriate solutions available.  How about we just use them?

Regards,
Tony

> On Nov 17, 2021, at 5:08 PM, Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:
> 
> From: Lsr <[email-masked] <mailto:[email-masked]>> On Behalf Of Gyan Mishra
> To: Aijun Wang <[email-masked] <mailto:[email-masked]>>
> Cc: Les Ginsberg (ginsberg) <ginsberg=[email-masked] <mailto:ginsberg=[email-masked]>>; [email-masked] <mailto:[email-masked]>; Christian Hopps <[email-masked] <mailto:[email-masked]>>; Tony Przygienda <[email-masked] <mailto:[email-masked]>>; Acee Lindem (acee) <acee=[email-masked] <mailto:acee=[email-masked]>>
> On Wed, Nov 17, 2021 at 6:10 PM Aijun Wang <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, Christian:
> 
> > On Nov 17, 2021, at 22:59, Christian Hopps <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > 
> > 
> >> On Nov 16, 2021, at 10:36 PM, Aijun Wang <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >> Hi, 
> >> 
> >> The followings are the responses for the comments on PUAM draft(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08 <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08>)
> >> 
> >> 【WAJ】Does anyone not agree what we analyze/summarize at the presentation material for the two solutions? (https://datatracker.ietf.org/meeting/112/materials/slides-112-lsr-05-puam-stublink-00.pdf <https://datatracker.ietf.org/meeting/112/materials/slides-112-lsr-05-puam-stublink-00.pdf>, the 5th slide)
> >> 
> >> From: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> On Behalf Of Acee Lindem (acee)
> >> To: [email-masked] <mailto:[email-masked]>
> >> https://datatracker.ietf.org/meeting/112/materials/minutes-112-lsr-00 <https://datatracker.ietf.org/meeting/112/materials/minutes-112-lsr-00>
> >> 
> >> https://play.conf.meetecho.com/Playout/?session=IETF112-LSR-20211111-1200 <https://play.conf.meetecho.com/Playout/?session=IETF112-LSR-20211111-1200>
> >> 
> >> Thanks,
> >> Acee
> > 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>
> -- 
> Email [email-masked] <mailto:[email-masked]>
> M 301 502-1347
> 
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 18 Nov 2021 02:22:50 +0000

The failure signaling pertains to a summary advertised in a normal routing instance and. If this problem is to be solved by the IGP, it definitely should be in the same instance as the summary itself. Hence, I second the motion to take the OSPF transport instance off the table for this application.

Thanks,
Acee
P.S. You probably noticed that I’ve deferred comment on whether or not this should be solved in the IGP.

From: "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]>
Date: Wednesday, November 17, 2021 at 8:09 PM
To: Gyan Mishra <[email-masked]>, Aijun Wang <[email-masked]>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <[email-masked]>, Christian Hopps <[email-masked]>, Tony Przygienda <[email-masked]>, Acee Lindem <[email-masked]>
Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Thanx.

   Les

The answer is it can’t.

Gyan
Verizon Inc

Aijun Wang
China Telecom

Gyan Mishra

M 301 502-1347

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 18 Nov 2021 02:26:22 +0000

Hi Les,

    I agree with you. It is legitimate for the IGP to advertise both a summary and changes to the reachability of individual destinations covered by the summary.

Best Regards,
Huaimo
________________________________
From: Lsr <[email-masked]> on behalf of Les Ginsberg (ginsberg) <ginsberg=[email-masked]>
Sent: Wednesday, November 17, 2021 8:08 PM
To: Gyan Mishra <[email-masked]>; Aijun Wang <[email-masked]>
Cc: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked] <[email-masked]>; Christian Hopps <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; Tony Przygienda <[email-masked]>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Thanx.

   Les

The answer is it can’t.

Gyan

Verizon Inc

Hi, Christian:

Aijun Wang
China Telecom

>> The followings are the responses for the comments on PUAM draft(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-wang-lsr-prefix-unreachable-annoucement-08&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C9281fc33749d46a3332b08d9aa300170%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637727945452872253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LtHeixN0GulAYCKXv6EBlurg1rpCFcpUz9InK1JO4to%3D&reserved=0>)
>>
>> 【WAJ】Does anyone not agree what we analyze/summarize at the presentation material for the two solutions? (https://datatracker.ietf.org/meeting/112/materials/slides-112-lsr-05-puam-stublink-00.pdf<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F112%2Fmaterials%2Fslides-112-lsr-05-puam-stublink-00.pdf&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C9281fc33749d46a3332b08d9aa300170%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637727945452882216%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8zDJ1%2BFq5EOWlWd33ZNZMRReE%2Bk3rtR7PllINVzgCEw%3D&reserved=0>, the 5th slide)
>>
>> https://datatracker.ietf.org/meeting/112/materials/minutes-112-lsr-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F112%2Fmaterials%2Fminutes-112-lsr-00&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C9281fc33749d46a3332b08d9aa300170%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637727945452892170%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=H5I7V2wFlzhUteBQfEaUUHmiTlLVmOrFHT9LrUylT3A%3D&reserved=0>
>>
>> https://play.conf.meetecho.com/Playout/?session=IETF112-LSR-20211111-1200<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.conf.meetecho.com%2FPlayout%2F%3Fsession%3DIETF112-LSR-20211111-1200&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C9281fc33749d46a3332b08d9aa300170%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637727945452892170%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5B4qe097rCg7UKD%2F0WRGMwk2rnLBkFvqROignp9VKRA%3D&reserved=0>
>>
>> Thanks,
>> Acee
>

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C9281fc33749d46a3332b08d9aa300170%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637727945452902138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Z2a1rLY3x64w4dwRkF0faGRcFCg1W%2FsesWX2XruK9QE%3D&reserved=0>

--

[Image removed by sender.]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C9281fc33749d46a3332b08d9aa300170%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637727945452912086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=llPJ0rvjg5vlrF0%2F%2FqcWPK2nXjHO5S9YrRXfkf4Mz0w%3D&reserved=0>

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 17 Nov 2021 21:35:13 -0500

+1

I completely agree.

The failure is with the IGP being able to track the component prefixes that
are part of a summary advertisement in large domains with hundreds of
thousands of host routes chatter that without summarization could result in
a meltdown.

BGPs job is to carry the external prefixes and the underlay connected and
egress PE LSP loopback FEC binding bgp next hop attribute is the job of the
IGP to build the RIB/FIB and MPLS LFIB which is all based on the underlay
IGP prefixes for hop by hop forwarding.

Kind Regards

Gyan

On Wed, Nov 17, 2021 at 9:23 PM Acee Lindem (acee) <[email-masked]> wrote:

> The failure signaling pertains to a summary advertised in a normal routing
> instance and. If this problem is to be solved by the IGP, it definitely
> should be in the same instance as the summary itself. Hence, I second the
> motion to take the OSPF transport instance off the table for this
> application.
>
>
>
> Thanks,
> Acee
>
> *From: *"Les Ginsberg (ginsberg)" <ginsberg=[email-masked]>
> *Date: *Wednesday, November 17, 2021 at 8:09 PM
> *To: *Gyan Mishra <[email-masked]>, Aijun Wang <
> [email-masked]>
> *Cc: *"Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <
> [email-masked]>, Christian Hopps <[email-masked]>, Tony Przygienda <
> [email-masked]>, Acee Lindem <[email-masked]>
> *Subject: *RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
> LSR Meeting Minutes
>
>
>
> I think the discussion about using a separate instance is a distraction
> and we shouldn’t be debating that right now.
>
>
>
> The legitimate question is whether folks see it as appropriate to have an
> IGP based solution for the problem. How to do it using the IGP is only a
> meaningful question if we are considering using the IGP at all.
>
>
>
> It is also a legitimate use of the IGPs to advertise all the individual
> prefixes covered by a summary if the network operator chooses not to
> summarize.
>
> It therefore seems to me to quite legitimate for the IGP to advertise both
> a summary and changes to the reachability of individual destinations
> covered by the summary. This is still a type of prefix reachability
> advertisement.
>
>
>
> It would help me if the folks who think this is NOT a legitimate use of an
> IGP could explain why in the context of the above.
>
>
>
> Thanx.
>
>
>
>    Les
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of *Gyan Mishra
> *Sent:* Wednesday, November 17, 2021 4:32 PM
> *To:* Aijun Wang <[email-masked]>
> *Cc:* Les Ginsberg (ginsberg) <ginsberg=[email-masked]>;
> [email-masked]; Christian Hopps <[email-masked]>; Tony Przygienda <
> [email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
> *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
> LSR Meeting Minutes
>
>
>
>
>
> With MT separate control plane common data plane or Multi Instance
> separate control plane and separate data plane.
>
>
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 18 Nov 2021 02:46:49 +0000

Tony –

Inline.

From: Tony Li <[email-masked]> On Behalf Of Tony Li
Sent: Wednesday, November 17, 2021 5:24 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Aijun Wang <[email-masked]>; [email-masked]; Christian Hopps <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Tony Przygienda <[email-masked]>
Subject: 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.

 Should we corrupt the architecture just because we can?  There are other, architecturally appropriate solutions available.  How about we just use them?

[LES:] What are you proposing?

   Les

Regards,
Tony

On Nov 17, 2021, at 5:08 PM, Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>> wrote:

Thanx.

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Gyan Mishra
Sent: Wednesday, November 17, 2021 4:32 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>>; [email-masked]<mailto:[email-masked]>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

The answer is it can’t.

Gyan
Verizon Inc

Aijun Wang
China Telecom

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 17 Nov 2021 23:07:36 -0500

RFC 5302 section 1.3 nicely describes the ISIS scalability issues with
domain wide flooding of prefixes and recommendations for summarization.

https://datatracker.ietf.org/doc/html/rfc5302#section-1.2

RFC 5283 inter-area extension is described in detail problem statement in
section 5 of the PUA draft and impact with convergence and not being able
to track component prefixes and a how the PUA and event notification drafts
solve real world problems that exist for operators.

https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08/section-5

Kind Regards

Gyan
Verizon

On Wed, Nov 17, 2021 at 9:46 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Tony –
>
>
>
> Inline.
>
>
>
> *From:* Tony Li <[email-masked]> *On Behalf Of *Tony Li
> *Sent:* Wednesday, November 17, 2021 5:24 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* Gyan Mishra <[email-masked]>; Aijun Wang <
> [email-masked]>; [email-masked]; Christian Hopps <
> [email-masked]>; Acee Lindem (acee) <[email-masked]>; Tony Przygienda <
> [email-masked]>
> 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 reachability
> throughout the network.
>
>
>
> Should we not advertise a summary because a single address in the summary
> is not assigned?  No, it is up to correspondents to determine if the
> address is populated.
>
>
>
> Should we punch holes in our summary for host failures?  That would kill
> scalability too and drag the IGP out of its role.
>
>
>
> *[LES:] No. We are doing it to improve convergence AND retain scalability.*
>
>
>
>  Should we corrupt the architecture just because we can?  There are other,
> architecturally appropriate solutions available.  How about we just use
> them?
>
>
>
> *[LES:] What are you proposing?*
>
>
>
> *   Les*
>
>
>
> Regards,
>
> Tony
>
>
>
>
>
>
>
> On Nov 17, 2021, at 5:08 PM, Les Ginsberg (ginsberg) <
> ginsberg=[email-masked]> wrote:
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Christian Hopps <[email-masked]>
Date: Thu, 18 Nov 2021 05:12:33 -0500

> On Nov 17, 2021, at 6:09 PM, Aijun Wang <[email-masked]> wrote:
> 
> Hi, Christian:
> 

As A WG member:

When I said in the meeting "As a WG member, I agree" I was specifically referring to the gist of his statement which was that this wasn't worth putting into the main protocol. I'm unconvinced (again as a WG member) that there's a problem worth trying to solve here -- at least one that rises above the "should we add something to the the protocol" level.

That said, the main point that I believe I was making here was that his comment was a good one to make during the adoption call (or preferably before we got to this point), so that discussion around it could happen on the list.

Thanks,
Chris.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Nov 2021 11:33:39 +0100

Les, All,

One thing to keep in mind in this entire discussion is the reality of
compute nodes becoming L3 routing nodes in many new architectures. The
protocol which is used between TORs and such compute nodes is almost always
BGP. That means that no matter what we do in the IGP we will not avoid
using BGP for propagating both service reachability and next hop
reachability of such service.

In all discussions so far I have not seen an indication that the proposed
solution covers the above case. If I have compute's next hops covered by
the summary and that compute goes down would I signal it in the IGP
across areas/levels ?

On the other hand TORs do not go down that much. So if we are to proceed
with IGP based signalling of lost reachability I highly encourage to
consider real problems and keep in mind scalability aspects in the event
someone would like to punch holes in the summaries also based on specific
compute nodes going down. Yes often BFD compute to TOR runs BFD so can be a
trigger.

We as networking people often put a wall between network and compute ...
well in reality there is no wall there any more**. So what we build must
consider service end to end not only traditional routers to be really
effective.

Thx,
R.

PS.  ** I came to know a few week's back that some well known financial
company is joining network and compute teams into one.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 18 Nov 2021 12:29:48 +0100

Robert,

On 18/11/2021 11:33, Robert Raszuk wrote:
> protocol which is used between TORs and such compute nodes is almost 
> always BGP. That means that no matter what we do in the IGP we will not 
> avoid using BGP for propagating both service reachability and next hop 
> In all discussions so far I have not seen an indication that the 
> proposed solution covers the above case. If I have compute's next hops 
> covered by the summary and that compute goes down would I signal it in 
> the IGP across areas/levels ?

If the IGP is aware of the reachability of the compute's next hop and it 
summarizes such reachability between areas/domains, it can for sure 
notify about such  compute's next hop becoming unreachable.

> someone would like to punch holes in the summaries also based on 
> specific compute nodes going down. Yes often BFD compute to TOR runs BFD 
> so can be a trigger.

first, we are not necessarily punching holes. At least with the event 
notification it does not leave any state, so "punching a hole in 
summary" is not the correct description of it. Second, remote PE going 
down may not be a very frequent event, but it is a possible event and 
there are existing solution that covers it. We are trying to extend the 
coverage for the case where network is using the summarization.

thanks,
Peter

> On Thu, Nov 18, 2021 at 3:47 AM Les Ginsberg (ginsberg) 
> <ginsberg=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Tony –____
> 
>     __ __
> 
>     Inline.____
> 
>     __ __
> 
>     *From:* Tony Li <[email-masked]
>     <mailto:[email-masked]>> *On Behalf Of *Tony Li
>     *To:* Les Ginsberg (ginsberg) <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Gyan Mishra <[email-masked]
>     <mailto:[email-masked]>>; Aijun Wang
>     <[email-masked] <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>; Christian Hopps
>     <[email-masked] <mailto:[email-masked]>>; Acee Lindem (acee)
>     <[email-masked] <mailto:[email-masked]>>; Tony Przygienda
>     <[email-masked] <mailto:[email-masked]>>
>     *Subject:* 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 reachability throughout the network.____
> 
>     __ __
> 
>     Reachability and path selection is the responsibility of the IGP,
>     not liveness.____
> 
>     __ __
> 
>     Should we not advertise a summary because a single address in the
>     summary is not assigned?  No, it is up to correspondents to
>     determine if the address is populated.____
> 
>     __ __
> 
>     Should we punch holes in our summary for unassigned addresses?  No,
>     that would kill scalability.____
> 
>     __ __
> 
>     Should we punch holes in our summary for host failures?  That would
>     kill scalability too and drag the IGP out of its role. ____
> 
>     __ __
> 
>     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.____/*
> 
>     */__ __/*
> 
>       Should we corrupt the architecture just because we can?  There are
>     other, architecturally appropriate solutions available.  How about
>     we just use them?____
> 
>     __ __
> 
>     */[LES:] What are you proposing?____/*
> 
>     */__ __/*
> 
>     */   Les____/*
> 
>     __ __
> 
>     Regards,____
> 
>     Tony____
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>         On Nov 17, 2021, at 5:08 PM, Les Ginsberg (ginsberg)
>         <ginsberg=[email-masked]
>         <mailto:ginsberg=[email-masked]>> wrote:____
> 
>         __ __
> 
>         I think the discussion about using a separate instance is a
>         distraction and we shouldn’t be debating that right now.____
> 
>         ____
> 
>         The legitimate question is whether folks see it as appropriate
>         to have an IGP based solution for the problem. How to do it
>         using the IGP is only a meaningful question if we are
>         considering using the IGP at all.____
> 
>         ____
> 
>         In that context…it is clear that it is a legitimate use of the
>         IGP to advertise summary addresses.____
> 
>         It is also a legitimate use of the IGPs to advertise all the
>         individual prefixes covered by a summary if the network operator
>         chooses not to summarize.____
> 
>         It therefore seems to me to quite legitimate for the IGP to
>         advertise both a summary and changes to the reachability of
>         individual destinations covered by the summary. This is still a
>         type of prefix reachability advertisement.____
> 
>         ____
> 
>         It would help me if the folks who think this is NOT a legitimate
>         use of an IGP could explain why in the context of the above.____
> 
>         ____
> 
>         Thanx.____
> 
>         ____
> 
>             Les____
> 
>         ____
> 
>         *From:*Lsr <[email-masked]
>         <mailto:[email-masked]>>*On Behalf Of*Gyan Mishra
>         *Sent:*Wednesday, November 17, 2021 4:32 PM
>         *To:*Aijun Wang <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc:*Les Ginsberg (ginsberg)
>         <ginsberg=[email-masked]
>         <mailto:ginsberg=[email-masked]>>;[email-masked]
>         <mailto:[email-masked]>; Christian Hopps <[email-masked]
>         <mailto:[email-masked]>>; Tony Przygienda
>         <[email-masked] <mailto:[email-masked]>>; Acee Lindem
>         (acee) <acee=[email-masked]
>         <mailto:acee=[email-masked]>>
>         *Subject:*Re: [Lsr]【Responses for Comments on PUAM Draft】RE:
>         IETF 112 LSR Meeting Minutes____
> 
>         ____
> 
>         ____
> 
>         With MT separate control plane common data plane or Multi
>         Instance separate control plane and separate data plane.____
> 
>         ____
> 
>         In both transport instance styles peeling the event notification
>         into a separate instance or topology how do this discrete
>         transport instance or topology interact with the main instance
>         or topology.____
> 
>         ____
> 
>         The answer is it can’t.____
> 
>         ____
> 
>         As Aijun as well as Peter have discussed the problem this is an
>         inherent issue with use of summarization and these are two
>         solutions to solbe this real world issue to make summarization
>         viable for operators.____
> 
>         ____
> 
>         Gyan____
> 
>         Verizon Inc____
> 
>         ____
> 
>         On Wed, Nov 17, 2021 at 6:10 PM Aijun Wang
>         <[email-masked] <mailto:[email-masked]>>
>         wrote:____
> 
>             Hi, Christian:
> 
>             Would you like to describe how to solve the problem via
>             using the transport instance? The detail interaction process
>             within the node and the deployment  overhead analysis?
>             If there is no such information, it is doubt whether your
>             judgment is correct or not, it is also unconvincing. Welcome
>             also Tony gives the explanation before making the
>             assertions, as we done for PUAM solution.
> 
> 
>             Aijun Wang
>             China Telecom
> 
>              > On Nov 17, 2021, at 22:59, Christian Hopps
>             <[email-masked] <mailto:[email-masked]>> wrote:
>              >
>              >
>              >
>              >> On Nov 16, 2021, at 10:36 PM, Aijun Wang
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>              >>
>              >> Hi,
>              >>
>              >> The followings are the responses for the comments on
>             PUAM
>             draft(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08)
>              >>
>              >>【WAJ】The problem is occurred due to the summary action
>             by the ABR router in IGP, it should be solved by IGP itself.
>              >>【WAJ】we have several round discussions for this topic
>             but there is always no conclusion at the end.
>              >>       Can the expert that reluctant to accept the new
>             idea to give some specific questions/problems for the
>             current solution?
>              >>       We would like to hear the specific and detail
>             comments for the current solutions, not just general comments.
>              >>
>              >>【WAJ】Does anyone not agree what we analyze/summarize at
>             the presentation material for the two solutions?
>             (https://datatracker.ietf.org/meeting/112/materials/slides-112-lsr-05-puam-stublink-00.pdf,
>             the 5th slide)
>              >>
>              >>【WAJ】Do you consider the deployment complexity for
>             independent service instance to transfer such thing? And
>             also the interaction on the device among the main IGP
>             instance and the service instances? It’s the fault of the
>             main protocol, and should be solved by the main protocol.
>              >>
>              > This makes it seem like I'm saying that I agree with your
>             response. I'd strike that "As a WG member, I agree".
>              >
>              > Thanks,
>              > Chris.
>              >
>              >
>              >>
>              >>
>              >>
>              >> From:[email-masked]
>             <mailto:[email-masked]><[email-masked]
>             <mailto:[email-masked]>> On Behalf Of Acee Lindem (acee)
>              >> To:[email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/listinfo/lsr____
> 
>         --____
> 
>          <http://www.verizon.com/>____
> 
>         *Gyan Mishra*____
> 
>         /Network Solutions Architect /____
> 
>         /[email-masked]
>         <mailto:[email-masked]>/____
> 
>         /M 301 502-1347/____
> 
>         ____
> 
>         https://www.ietf.org/mailman/listinfo/lsr____
> 
>     __ __
>

---

From: Aijun Wang <[email-masked]>
Date: Thu, 18 Nov 2021 20:25:46 +0800

Hi, Robert:

I want to add one comments based on Peter’s comments.

Aijun Wang
China Telecom

> On Nov 18, 2021, at 19:30, Peter Psenak <ppsenak=[email-masked]> wrote:
> 
> Robert,
> 
>> One thing to keep in mind in this entire discussion is the reality of compute nodes becoming L3 routing nodes in many new architectures. The protocol which is used between TORs and such compute nodes is almost always BGP. That means that no matter what we do in the IGP we will not avoid using BGP for propagating both service reachability and next hop reachability of such service.

[WAJ] In the scenarios that you mentioned, BGP nexthop reachability is derived from the directed interface, there is no summary action done by the router. Is that true?

>> In all discussions so far I have not seen an indication that the proposed solution covers the above case. If I have compute's next hops covered by the summary and that compute goes down would I signal it in the IGP across areas/levels ?
> 
> If the IGP is aware of the reachability of the compute's next hop and it summarizes such reachability between areas/domains, it can for sure notify about such  compute's next hop becoming unreachable.
> 
>> On the other hand TORs do not go down that much. So if we are to proceed with IGP based signalling of lost reachability I highly encourage to consider real problems and keep in mind scalability aspects in the event someone would like to punch holes in the summaries also based on specific compute nodes going down. Yes often BFD compute to TOR runs BFD so can be a trigger.
> 
> first, we are not necessarily punching holes. At least with the event notification it does not leave any state, so "punching a hole in summary" is not the correct description of it. Second, remote PE going down may not be a very frequent event, but it is a possible event and there are existing solution that covers it. We are trying to extend the coverage for the case where network is using the summarization.
> 
> 
> thanks,
> Peter
> 
>> We as networking people often put a wall between network and compute ... well in reality there is no wall there any more**. So what we build must consider service end to end not only traditional routers to be really effective.
>> Thx,
>> R.
>> PS.  ** I came to know a few week's back that some well known financial company is joining network and compute teams into one.
>> On Thu, Nov 18, 2021 at 3:47 AM Les Ginsberg (ginsberg) <ginsberg=[email-masked] <mailto:[email-masked]>> wrote:
>>    Tony –____
>>    __ __
>>    Inline.____
>>    __ __
>>    Why would we then punch holes in the summary for member routers?     Just because we can? ____

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Nov 2021 13:42:39 +0100

>
> [WAJ] In the scenarios that you mentioned, BGP nexthop reachability is
> derived from the directed interface, there is no summary action done by the
> router. Is that true?
>

Not necessarily - TORs do not always do eBGP to compute and set next hop
self. There can be IBGP session there and therefor next hop is not changed
all the way to the remote compute. But the point was that today BGP is
involved already in reachability and service distribution.

And while current IGP proposals can propagate this too the point is about
scalability when it comes to signalling of such massive failures in the
IGP. The amount of IGP traffic and processing in those moments may be
significant.

And yes I agree this is not really a "hole punching" ... that was just a
description shortcut I used.

Thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 18 Nov 2021 13:58:32 +0100

Robert,

On 18/11/2021 13:42, Robert Raszuk wrote:
>     [WAJ] In the scenarios that you mentioned, BGP nexthop reachability
>     is derived from the directed interface, there is no summary action
>     done by the router. Is that true?
> 
> 
> self. There can be IBGP session there and therefor next hop is not 
> changed all the way to the remote compute. But the point was that today 
> BGP is involved already in reachability and service distribution.
> 
> And while current IGP proposals can propagate this too the point is 
> about scalability when it comes to signalling of such massive failures 
> in the IGP. The amount of IGP traffic and processing in those moments 
> may be significant.

we can certainly address such case by not allowing thousands of pulses 
to be generated in case half of the universe falls apart. That seems 
obvious and easy to implement.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Nov 2021 14:26:28 +0100

In such cases I would rather consider implementing pulse to be less then
host route.

Suppressing them randomly may lead to even bigger disappointment of
unreachability propagation hence delaying connectivity restoration to a
backup path.

Many thx,
R.

---

From: Aijun Wang <[email-masked]>
Date: Thu, 18 Nov 2021 22:17:18 +0800

Hi, Robert:

If you use iBGP in your mentioned scenario, how to propagate the reachability of  BGP nexthop? I think it is impossible to use again BGP itself. Then depend only BGP can’t solve your problem.

If the underlying using IGP to propagate such reachability information, we have mechanism to control for which covered prefix to send the notification when they become unreachable. It is not randomly suppressed.

Aijun Wang
China Telecom

> On Nov 18, 2021, at 21:27, Robert Raszuk <[email-masked]> wrote:
> 
> 
> 
> In such cases I would rather consider implementing pulse to be less then host route. 
> 
> Suppressing them randomly may lead to even bigger disappointment of unreachability propagation hence delaying connectivity restoration to a backup path. 
> 
> Many thx,
> R.
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Nov 2021 15:19:23 +0100

Next hops are part of the IGP summary when advertising outside of the area.
Within area those are host routes usually or smaller subnets (/24s for
TOR-Compute LANs).

Thx,
R.

On Thu, Nov 18, 2021 at 3:17 PM Aijun Wang <[email-masked]>
wrote:

> Hi, Robert:
>
> If you use iBGP in your mentioned scenario, how to propagate the
> reachability of  BGP nexthop? I think it is impossible to use again BGP
> itself. Then depend only BGP can’t solve your problem.
>
> If the underlying using IGP to propagate such reachability information, we
> have mechanism to control for which covered prefix to send the notification
> when they become unreachable. It is not randomly suppressed.
>
>
> Aijun Wang
> China Telecom
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 18 Nov 2021 14:30:07 +0000

Hi Gyan,

Are you saying you actually have hundreds of thousands of host routes in area routing domains? I guess this is across many areas? What is the use case (hopefully, in 40 words or less)?

Thanks,
Acee

From: Gyan Mishra <[email-masked]>
Date: Wednesday, November 17, 2021 at 9:35 PM
To: Acee Lindem <[email-masked]>
Cc: Aijun Wang <[email-masked]>, Christian Hopps <[email-masked]>, "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, Tony Przygienda <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

+1

I completely agree.

The failure is with the IGP being able to track the component prefixes that are part of a summary advertisement in large domains with hundreds of thousands of host routes chatter that without summarization could result in a meltdown.

BGPs job is to carry the external prefixes and the underlay connected and egress PE LSP loopback FEC binding bgp next hop attribute is the job of the IGP to build the RIB/FIB and MPLS LFIB which is all based on the underlay IGP prefixes for hop by hop forwarding.

Kind Regards

Gyan

On Wed, Nov 17, 2021 at 9:23 PM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
The failure signaling pertains to a summary advertised in a normal routing instance and. If this problem is to be solved by the IGP, it definitely should be in the same instance as the summary itself. Hence, I second the motion to take the OSPF transport instance off the table for this application.

Thanks,
Acee

From: "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 17, 2021 at 8:09 PM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>, Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Christian Hopps <[email-masked]<mailto:[email-masked]>>, Tony Przygienda <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Thanx.

   Les

Cc: Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>>

The answer is it can’t.

Gyan
Verizon Inc

Aijun Wang
China Telecom

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

---

From: Aijun Wang <[email-masked]>
Date: Thu, 18 Nov 2021 22:32:24 +0800

Hi, Christian:

Aijun Wang
China Telecom

> On Nov 18, 2021, at 18:13, Christian Hopps <[email-masked]> wrote:
> 
> 
> 

[WAJ] Should it be “whoever makes a mistake, who corrects”?

> That said, the main point that I believe I was making here was that his comment was a good one to make during the adoption call (or preferably before we got to this point), so that discussion aroun…

[WAJ] Yeah, I think it has happened. There is no other better option to solve such problem now. If exists, please describe it.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Nov 2021 15:54:54 +0100

Btw even with eBGP between TOR and compute I have just checked and I see
cases of some deployments not setting next hop self on TORs hence original
next hop set by compute is used in service routes.

Link between TOR and compute is passive IGP link/subnet.

Thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 18 Nov 2021 15:57:21 +0100

On 18/11/2021 15:54, Robert Raszuk wrote:
> cases of some deployments not setting next hop self on TORs hence 
> original next hop set by compute is used in service routes.
> 

that's what I thought would be the case. And in such case the IGP 
solution would work for you.

Peter

> 
> Thx,
> R.
> 
> On Thu, Nov 18, 2021 at 3:17 PM Aijun Wang <[email-masked] 
>     reachability of  BGP nexthop? I think it is impossible to use again
>     BGP itself. Then depend only BGP can’t solve your problem.
> 
>     If the underlying using IGP to propagate such reachability
>     information, we have mechanism to control for which covered prefix
>     to send the notification when they become unreachable. It is not
>     randomly suppressed.
> 
> 
>     Aijun Wang
>     China Telecom
> 
>>     On Nov 18, 2021, at 21:27, Robert Raszuk <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>
>>     Suppressing them randomly may lead to even bigger disappointment
>>     of unreachability propagation hence delaying connectivity
>>     restoration to a backup path.
>>
>>     Many thx,
>>     R.
>>
>>     On Thu, Nov 18, 2021 at 1:58 PM Peter Psenak <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>         Robert,
>>

---

From: Tony Li <[email-masked]>
Date: Thu, 18 Nov 2021 08:06:34 -0800

Les,

> [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 overlay is irrelevant to the IGP.

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, exacerbating the situation.

> [LES:] What are you proposing?

You are signaling the (lack of) liveness of a remote node. I propose that we instead use existing signaling mechanisms to do this. Multi-hop BFD seems like an obvious choice.

If you greatly dislike that for some reason, I would suggest that we create a proxy liveness service, advertised by the ABR. This would allow correspondents to register for notifications. The ABR could signal these unicast when it determines that the specific targets are unreachable.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Nov 2021 17:12:23 +0100

Tony,

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 ?

In respect to using BFD here - let's start with basic question - who would
be the producer to install those host routes into RIB ? Note in the
discussed scenario there are not there today - only summary is there.

Thx,
R.

On Thu, Nov 18, 2021 at 5:06 PM Tony Li <[email-masked]> wrote:

> You are not improving convergence. You are propagating liveness.  The fact
> that this relates to convergence in the overlay is irrelevant to the IGP.
>
> 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, exacerbating the
> situation.
>
>
> You are signaling the (lack of) liveness of a remote node. I propose that
> we instead use existing signaling mechanisms to do this. Multi-hop BFD
> seems like an obvious choice.
>
> If you greatly dislike that for some reason, I would suggest that we
> create a proxy liveness service, advertised by the ABR. This would allow
> correspondents to register for notifications. The ABR could signal these
> unicast when it determines that the specific targets are unreachable.
>
> Tony
>
>

---

From: Tony Li <[email-masked]>
Date: Thu, 18 Nov 2021 08:16:43 -0800

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, that’s certainly an alternative as well.

Additional configuration is not a good metric on architectural complexity and fragility.  The worst ‘features’ can be enabled with a single line. :)

> In respect to using BFD here - let's start with basic question - who would be the producer to install those host routes into RIB ? Note in the discussed scenario there are not there today - only summary is there. 

Why do you assume that BFD would produce a route? I would instead suggest that the overlay BGP would register with BFD for notifications about a remote.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Nov 2021 17:23:29 +0100

> If you want to address this problem with BGP keep alive timers, that’s
certainly an alternative as well.

Nope that is not what I previously described in this thread.

BGP uses recursion. So you can propage next hops in BGP and recurse your
service route next hops over those with simple config knob to only consider
/32 or /128 routes as next hops.

Local detection of node going down can be done with BFD or LOS:  TOR to RR
or Compute to TOR or ... BGP propagation via few RRs will be in
milliseconds. Then you can also apply constrain equal to service route
constrains to limit the blast to only those targets which need that info.
Not sure how to do such limiting in proposed IGP solutions.

Thx,
R.

On Thu, Nov 18, 2021 at 5:16 PM Tony Li <[email-masked]> wrote:

> Additional configuration is not a good metric on architectural complexity
> and fragility.  The worst ‘features’ can be enabled with a single line. :)
>
>
> Why do you assume that BFD would produce a route? I would instead suggest
> that the overlay BGP would register with BFD for notifications about a
> remote.
>
> Tony
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 18 Nov 2021 16:30:07 +0000

Tony -

From: Lsr <[email-masked]> On Behalf Of Tony Li
Sent: Thursday, November 18, 2021 8:07 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Christian Hopps <[email-masked]>; Aijun Wang <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>; Tony Przygienda <[email-masked]>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Les,

[LES2:] It is reasonable to limit the rate of pulses sent. Peter has already indicated in an earlier reply that we will address that in a future version of the event-notification draft.  So, good point - and we are in agreement regarding mass failure.

You are signaling the (lack of) liveness of a remote node. I propose that we instead use existing signaling mechanisms to do this. Multi-hop BFD seems like an obvious choice.
[LES2:] Conceptually this works. But I don’t think it scales.

[LES:] This would be a significant effort to provide such a service.
Granted, implementation of “pulse” is also a significant effort - so I am not objecting to your idea simply based on that. I am just pointing out that what you propose does not currently exist - so if you are serious about this alternative you need to provide the details.

   Les

Tony

---

From: Tony Li <[email-masked]>
Date: Thu, 18 Nov 2021 08:38:32 -0800

Les,

> [LES2:] It is reasonable to limit the rate of pulses sent. Peter has already indicated in an earlier reply that we will address that in a future version of the event-notification draft.  So, good point – and we are in agreement regarding mass failure.

The fact that you have to limit the result is a pretty clear indication that this is not architecturally appropriate.

> [LES2:] Conceptually this works. But I don’t think it scales.

How so? Doesn’t this correspond 1:1 with overlay BGP sessions?

> Granted, implementation of “pulse” is also a significant effort – so I am not objecting to your idea simply based on that. I am just pointing out that what you propose does not currently exist – so if you are serious about this alternative you need to provide the details.

Fear of hard work does not make it the IGP’s problem. 

I am not the one with the issue. Those with the issue should propose the details. At most, the IGP should carry a capability for this service.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Nov 2021 17:40:19 +0100

Hi Tony,

> How so? Doesn’t this correspond 1:1 with overlay BGP sessions?

Not at all.

BGP is never full mesh across multiple areas. RR hops are used. BFD does
not have concept of RRs last time I looked at it :)

Kind regards,
R.

On Thu, Nov 18, 2021 at 5:38 PM Tony Li <[email-masked]> wrote:

> *[LES2:] It is reasonable to limit the rate of pulses sent. Peter has
> already indicated in an earlier reply that we will address that in a future
> version of the event-notification draft.  So, good point – and we are in
> agreement regarding mass failure.*
>
>
>
> The fact that you have to limit the result is a pretty clear indication
> that this is not architecturally appropriate.
>
>
> *[LES2:] Conceptually this works. But I don’t think it scales.*
>
>
>
> *[LES:] This would be a significant effort to provide such a service.*
> *Granted, implementation of “pulse” is also a significant effort – so I am
> not objecting to your idea simply based on that. I am just pointing out
> that what you propose does not currently exist – so if you are serious
> about this alternative you need to provide the details.*
>
>
>
> I am not the one with the issue. Those with the issue should propose the
> details. At most, the IGP should carry a capability for this service.
>
> Tony
>
>

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 18 Nov 2021 17:45:28 +0100

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 fastest possible convergence in network _reachability_ only
and not signalling of service failures. BGP is the overlay synchronizing
SSAPs & scales marvelously @ that. Having BGP next-hop (which is basically
equivalent to all services provided behind it) liveliness indicating the
health of services behind it is the scalable solution IMO, and not starting
to try to teach IGP fragile signalling or PUAM (which BTW AFAIS will
neither scale nor work on generic graphs due to lack of any consistent
algebra I could detect in the draft and it is definitely nothing "like
rift" as the preso seems to claim again) which will easily affect its main
job. For signalling I see how putting it into a service instance is a
somewhat palatable design choice and it's kind of like inventing "passive
BFD" over flooding in my eyes ;-) And BTW, in topologically sorted graphs
(CLOS being the ones of interest these days) with strict positive/negative
disaggregation algebra with minimal blast radius on failures we can scale
to (at least) 0.5M prefixes implementation wise IME and that should allow
us really, really big IP fabrics with leaves holding nothing but defaults
under normal conditions but it's still not a good idea to abuse that for
SSAP synchronization AFAIS (and observe that to scale RIFT does NOT notify
leaves of their vice-versa reachability, it simply prevents blackholing on
aggregates and will produce an ICMP unreachable if there are no routes left
to destination, if you run BFD on top of that as Tony suggests, this will
of course give you the desired effect, for RR you'll run into the TCP
session problem again but maybe you can BFD the RR session and then
propagate that as Robert seems to suggest, the third-party next-hop raises
its head again ;-).

Alternately resolving BGP over BGP as Robert suggests (if I read that
correctly) and use RR to scale out the SSAP nhop availability is possible I
think architecturally without garbage-canning IGPs as "network-wide fast
broadcast mechanism" ... I doubt it will do "couple millisecs" convergence
;-) but can be simpler hardware wise than trying to scale up BFD to large
number of very fast sessions.

-- tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Nov 2021 18:06:08 +0100

Hi les,

> agreement regarding mass failure.*

In respect to the anti-choke timer out of curiosity, what is your
definition of "mass failure" ?

100 pulses in a second ? 1000 in a second ? Least Common Denominator the
weakest IGP node in the domain could handle ?

Is this to be rate limit with queuing the rest to just smooth the peak in
time or drop the rest ?

Many thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 18 Nov 2021 18:10:45 +0100

Tony,

On 18/11/2021 17:38, Tony Li wrote:
> 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, 
>> exacerbating the situation.
>> */[LES2:] It is reasonable to limit the rate of pulses sent. Peter has 
>> already indicated in an earlier reply that we will address that in a 
>> future version of the event-notification draft.  So, good point – and 
>> we are in agreement regarding mass failure./*
> 
> 

using that logic, IGPs would not be suitable for half of the things they 
are used for. We have areas to limit the flood radius, we have 
summarization to limit the prefix scope, we have SPF backoff to limit 
the SPFs, etc. The presence of these does not indicate that we use IGPs 
inappropriately.

> 
> 
>> You are signaling the (lack of) liveness of a remote node. I propose 
>> that we instead use existing signaling mechanisms to do this. 
>> Multi-hop BFD seems like an obvious choice.
>> */[LES2:] Conceptually this works. But I don’t think it scales./*
> 
> 

PEs typically only peer with RRs, not between themselves.

>> create a proxy liveness service, advertised by the ABR. This would 
>> allow correspondents to register for notifications. The ABR could 
>> signal these unicast when it determines that the specific targets are 
>> unreachable.
>> */[LES:] This would be a significant effort to provide such a service./*
>> */Granted, implementation of “pulse” is also a significant effort – so 
>> I am not objecting to your idea simply based on that. I am just 
>> pointing out that what you propose does not currently exist – so if 
>> you are serious about this alternative you need to provide the details./*
> 
> 

nor should it prevent us to consider IGPs, especially when the 
alternative would likely lead to the definition of the new protocol 
(e.g. liveness service, advertised by the ABR).

thanks,
Peter

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 18 Nov 2021 15:16:34 -0500

Acee

We do have a lot of host routes in the hundreds of thousands across all
area but within an area at each level, core, aggregation,  we do also have
 close to hundreds of thousands of host routes as well that are flooded due
to the E2E seamless mpls hierarchy.

The flooding is much worse with seamless MPLS as all loopbacks for end to
end LSP have to be flooded domain wide.  But then you have the advantages
of seamless MPLS.

So for Verizon and any operator around the world using seamless MPLS could
take advantage of summarization and use of event notification or PUA for
convergence.  Also less memory and control plane overhead without the
flooding.

Also reduces the noise in the network from flapping churn as well.

Kind Regards

Gyan

On Thu, Nov 18, 2021 at 9:30 AM Acee Lindem (acee) <[email-masked]> wrote:

> Hi Gyan,
>
>
>
> Are you saying you actually have hundreds of thousands of host routes in
> area routing domains? I guess this is across many areas? What is the use
> case (hopefully, in 40 words or less)?
>
>
>
> Thanks,
> Acee
>
>
>
> *From: *Gyan Mishra <[email-masked]>
> *Date: *Wednesday, November 17, 2021 at 9:35 PM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *Aijun Wang <[email-masked]>, Christian Hopps <
> [email-masked]>, "Les Ginsberg (ginsberg)" <ginsberg=
> [email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>,
> Tony Przygienda <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
> LSR Meeting Minutes
>
>
>
>
>
> +1
>
>
>
> I completely agree.
>
>
>
> The failure is with the IGP being able to track the component prefixes
> that are part of a summary advertisement in large domains with hundreds of
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Aijun Wang <[email-masked]>
Date: Fri, 19 Nov 2021 07:22:04 +0800

Hi, Tony:

Aijun Wang
China Telecom

> On Nov 19, 2021, at 00:46, Tony Przygienda <[email-masked]> wrote:
> 
> 
> 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 fastest possible convergence in network _reachability_ only and not signalling of service failures.

[WAJ] The problem is arose from the summary action of IGP, why let other protocols solve it? 

> BGP is the overlay synchronizing SSAPs & scales marvelously @ that. Having BGP next-hop (which is basically equivalent to all services provided behind it) liveliness indicating the health of services behind it is the scalable solution IMO,

[WAJ] Have discussed the BFD solutions several rounds on the list. Just for remind: BFD has the configuration overhead; and if PEs peer via the RR, BFD for BGP can’t solve.

> and not starting to try to teach IGP fragile signalling or PUAM (which BTW AFAIS will neither scale nor work on generic graphs due to lack of any consistent algebra I could detect in the draft and it is definitely nothing "like rift" as the preso seems to claim again) which will easily affect its main job.
[WAJ] The PUAM solution meet any graph, not like the RIFT is suitable only some planned only topology. If you don’t agree, please give the example before making some unconvincing assertions.
The reason that I mentioned RIFT is that you are familiar with it, just want you to understand the PUAM. 
Will the aggregate router advertise the detail reachability information to its leaves when the other aggregate router at the same sites can’t be reachable in RIFT?
Even with the above similarities, we will try to avoid to mention RIFT later, because not all readers familiar with it. 

> For signalling I see how putting it into a service instance is a somewhat palatable design choice and it's kind of like inventing "passive BFD" over flooding in my eyes ;-)
[WAJ] Using service instance is rejected already. I think you have noticed Acee also mentioned this.

> And BTW, in topologically sorted graphs (CLOS being the ones of interest these days) with strict positive/negative disaggregation algebra with minimal blast radius on failures we can scale to (at least) 0.5M prefixes implementation wise IME and that should allow us really, really big IP fabrics with leaves holding nothing but defaults under normal conditions but it's still not a good idea to abuse that for SSAP synchronization AFAIS (and observe that to scale RIFT does NOT notify leaves of their vice-versa reachability, it simply prevents blackholing on aggregates and will produce an ICMP unreachable if there are no routes left to destination, if you run BFD on top of that as Tony suggests, this will of course give you the desired effect, for RR you'll run into the TCP session problem again but maybe you can BFD the RR session and then propagate that as Robert seems to suggest, the third-party next-hop raises its head again ;-). 
[WAJ] We are discussing the general solution, not the solution that specific only some limited topology.

> 
> Alternately resolving BGP over BGP as Robert suggests (if I read that correctly) and use RR to scale out the SSAP nhop availability is possible I think architecturally without garbage-canning IGPs as "network-wide fast broadcast mechanism" ... I doubt it will do "couple millisecs" convergence ;-) but can be simpler hardware wise than trying to scale up BFD to large number of very fast sessions. 

[WAJ] The operator doesn’t also want the network is filled with various queer designs or solutions.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 18 Nov 2021 19:13:37 -0500

Hi Tony

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
is area summarization,  however in order to make summarization viable for
convergence we need a method to track the component prefixes when a failure
occurs.

So we have the two IGP based solutions but as this is an IGP issue, the
issue needs to be solved by the IGP.  I don’t think their is an easy way to
solve this in BGP.

Kind Regards

Gyan
On Thu, Nov 18, 2021 at 6:22 PM Aijun Wang <[email-masked]>
wrote:

> 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 fastest possible convergence in network
> _reachability_ only and not signalling of service failures.
>
>
> BGP is the overlay synchronizing SSAPs & scales marvelously @ that. Having
> BGP next-hop (which is basically equivalent to all services provided behind
> it) liveliness indicating the health of services behind it is the scalable
> solution IMO,
>
>
> [WAJ] Have discussed the BFD solutions several rounds on the list. Just
> for remind: BFD has the configuration overhead; and if PEs peer via the RR,
> BFD for BGP can’t solve.
>
> and not starting to try to teach IGP fragile signalling or PUAM (which BTW
> AFAIS will neither scale nor work on generic graphs due to lack of any
> consistent algebra I could detect in the draft and it is definitely nothing
> "like rift" as the preso seems to claim again) which will easily affect its
> main job.
>
> [WAJ] The PUAM solution meet any graph, not like the RIFT is suitable only
> some planned only topology. If you don’t agree, please give the example
> before making some unconvincing assertions.
> Will the aggregate router advertise the detail reachability information to
> its leaves when the other aggregate router at the same sites can’t be
> reachable in RIFT?
> Even with the above similarities, we will try to avoid to mention RIFT
> later, because not all readers familiar with it.
>
> For signalling I see how putting it into a service instance is a somewhat
> palatable design choice and it's kind of like inventing "passive BFD" over
> flooding in my eyes ;-)
>
> And BTW, in topologically sorted graphs (CLOS being the ones of interest
> these days) with strict positive/negative disaggregation algebra with
> minimal blast radius on failures we can scale to (at least) 0.5M prefixes
> implementation wise IME and that should allow us really, really big IP
> fabrics with leaves holding nothing but defaults under normal conditions
> but it's still not a good idea to abuse that for SSAP synchronization AFAIS
> (and observe that to scale RIFT does NOT notify leaves of their vice-versa
> reachability, it simply prevents blackholing on aggregates and will produce
> an ICMP unreachable if there are no routes left to destination, if you run
> BFD on top of that as Tony suggests, this will of course give you the
> desired effect, for RR you'll run into the TCP session problem again but
> maybe you can BFD the RR session and then propagate that as Robert seems to
> suggest, the third-party next-hop raises its head again ;-).
>
>> You are not improving convergence. You are propagating liveness.  The
>> fact that this relates to convergence in the overlay is irrelevant to the
>> IGP.
>>
>> other, architecturally appropriate solutions available.  How about we just
>> use them?
>>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Tony Li <[email-masked]>
Date: Thu, 18 Nov 2021 17:08:08 -0800

Hi Aijun,

At the risk of Tony confusion…

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

We want scalability. That implies abstraction and that means that you can’t get a full link state database everywhere.

If you’re willing to forgo scalability, then do so.  Don’t use areas. Just have a flat routing domain.

Hole punching is going to put you in exactly the same place, sooner or later.  You’re sacrificing scalability and adding another mechanism to do so.  Why bother?

> [WAJ] The operator doesn’t also want the network is filled with various queer designs or solutions.

Then why are you proposing one? [BTW, I realize that you intended no offense, that’s probably NOT the best choice of words.]

There’s a reason that we’ve never gone down the path of hole punching before.  And yes, it’s been discussed before, decades ago.

Tony

---

From: Tony Li <[email-masked]>
Date: Thu, 18 Nov 2021 17:10:19 -0800

Hi Gyan,

> On Nov 18, 2021, at 4:13 PM, Gyan Mishra <[email-masked]> 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 is area summarization,  however in order to make summarization viable for convergence we need a method to track the component prefixes when a failure occurs.  
> 
> So we have the two IGP based solutions but as this is an IGP issue, the issue needs to be solved by the IGP.  I don’t think their is an easy way to solve this in BGP.

It seems to me that having a full set of host routes, either positive or negative, is a really bad idea.  How about we not do that?

T

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 19 Nov 2021 11:16:22 +0800

Hi, Tony:

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Tony Li
Sent: Friday, November 19, 2021 9:08 AM
To: Aijun Wang <[email-masked]>
Cc: Tony Przygienda <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <[email-masked]>; [email-masked]; Christian Hopps <[email-masked]>; Acee Lindem (acee) <[email-masked]>
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. 

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 of these overlay service is unreachable, the IGP still advertises the summary reachability. IGP should leak the actual information in such situation, doesn't insist that it can reach these failed address. 
And, as we have presented in the IETF meeting, the ABR Need Not advertise such information once there is prefix unreachable. The operator can configure the tracked/interested prefixes on the ABR.

We want scalability. That implies abstraction and that means that you can’t get a full link state database everywhere.
[WAJ] Yes. Current solution will not scarify the IGP scalability. As stated above, Not all link/prefix failures information will be delivered.

There’s a reason that we’ve never gone down the path of hole punching before.  And yes, it’s been discussed before, decades ago.
[WAJ] With the Tunnel Technologies such as SRv6 are accepted/deployed, such solutions will be needed more and more. I think it is different from the situation existing decades ago.

Tony

---

From: Peter Psenak <[email-masked]>
Date: Fri, 19 Nov 2021 09:49:42 +0100

Tony,

> 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 route of remote PEs. Both 
up and down events are propagated everywhere. If such host route becomes 
unreachable, it is being used by BGP PIC to trigger the reroute.

When summarization is in place, to help IGP to scale, the remote PEs' 
reachability is announced in a form of a summary and host routes are 
suppressed. Providing down notification for the host prefix covered by 
the summary is similar in nature to what happens without the 
summarization. And if that down notification can be done in smart way, 
we are still better off compared to what we do today without a 
summarization.

You can call it liveness or something else, but IGPs are already doing 
so without the summarization. Arguing that it's not a property that IGPs 
were meant to provide is misleading.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 19 Nov 2021 10:09:50 +0100

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

---

From: Tony Li <[email-masked]>
Date: Fri, 19 Nov 2021 07:51:06 -0800

Hi Aijun,

> And, as we have presented in the IETF meeting, the ABR Need Not advertise such information once there is prefix unreachable. The operator can configure the tracked/interested prefixes on the ABR.

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] Yes. Current solution will not scarify the IGP scalability. As stated above, Not all link/prefix failures information will be delivered.

You can’t guarantee that.  What we’ve seen is that when we provide features in protocols, they are (ab)used in the worst ways imaginable. And then the implementers are held responsible for the outcomes. In this case, it’s pretty clear that there could easily be a mass failure resulting in the bulk advertisement of a whole lot of negative information all at once.

One of the other things that we’ve learned is that step (and spike) responses are problematic. Frequently they are more of an issue than scale because the operator can’t see it coming. We end up with cascade failures (see the recent Facebook failure).

Our job is to not design in mechanisms that lead to these bad outcomes.

> [WAJ] With the Tunnel Technologies such as SRv6 are accepted/deployed, such solutions will be needed more and more. I think it is different from the situation existing decades ago.

Nothing has changed except the encoding. We’ve been tunneling for decades. We’ve been summarizing for decades. We’ve been rejecting hole punching for decades. We’ve even been tunneling using source routing and other high overhead mechanisms for decades. That ended up rejected too.

If you really want the service, please change the architecture to a registration mechanism as I outlined. This can and should be done outside of the IGP.  You’re asking for a proxy liveness service and that’s entirely doable.

Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 19 Nov 2021 08:02:42 -0800

Hi Peter,

> today IGPs provide reachability for the host route of remote PEs. Both up and down events are propagated everywhere. If such host route becomes unreachable, it is being used by BGP PIC to trigger the reroute.
> 
> When summarization is in place, to help IGP to scale, the remote PEs' reachability is announced in a form of a summary and host routes are suppressed. Providing down notification for the host prefix covered by the summary is similar in nature to what happens without the summarization. And if that down notification can be done in smart way, we are still better off compared to what we do today without a summarization.

And if it was done in a smart way, you could do so without ANY impact to scalability. I outlined the mechanism for you already.

> You can call it liveness or something else, but IGPs are already doing so without the summarization. Arguing that it's not a property that IGPs were meant to provide is misleading.

This is incorrect.  Liveness is a side-effect in a flat area. It is NOT something that the routing layer provides. Consider the case of a host that is not participating in the IGP.  You have reachability information for it and path computation, as the IGP is designed to provide, but you do not have liveness.

If you are not willing to have an architectural discussion, then there’s not much of a point in having a working group.

If you’re going to call every argument misleading, there’s also not much point in a working group. Les asked me for a clear explanation. I’ve done my best to provide that and apparently, I haven’t earned enough respect for it to be seriously considered. Ok, so be it. I was not looking for the Argument Clinic (https://www.dailymotion.com/video/x2hwqn9 <https://www.dailymotion.com/video/x2hwqn9>). Let’s agree to disagree.

Tony

---

From: Peter Psenak <[email-masked]>
Date: Fri, 19 Nov 2021 17:39:28 +0100

Hi Tony,

On 19/11/2021 17:02, Tony Li wrote:
>>> 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.
>>
>> up and down events are propagated everywhere. If such host route 
>> becomes unreachable, it is being used by BGP PIC to trigger the reroute.
>>
> And if it was done in a smart way, you could do so without ANY impact to 
> scalability. I outlined the mechanism for you already.
> 
> 
>> so without the summarization. Arguing that it's not a property that 
>> IGPs were meant to provide is misleading.
> 
> 
> This is incorrect.  Liveness is a side-effect in a flat area. It is NOT 
> something that the routing layer provides. Consider the case of a host 
> that is not participating in the IGP.  You have reachability information 
> for it and path computation, as the IGP is designed to provide, but you 
> do not have liveness.

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 service 
between PEs in any MPLS network.

> 
> If you are not willing to have an architectural discussion, then there’s 
> not much of a point in having a working group.

don't take me wrong, I'm not trying to avoid the architectural 
discussion, quite the opposite.

If IGPs can provide full liveness service between PEs today, why doing 
'optimized negative liveness service' would be architecturally wrong?

thanks,
Peter

> 
> If you’re going to call every argument misleading, there’s also not much 
> point in a working group. Les asked me for a clear explanation. I’ve 
> done my best to provide that and apparently, I haven’t earned enough 
> respect for it to be seriously considered. Ok, so be it. I was not 
> looking for the Argument Clinic 
> (https://www.dailymotion.com/video/x2hwqn9). Let’s agree to disagree.
> 
> Tony
>

---

From: Tony Li <[email-masked]>
Date: Fri, 19 Nov 2021 08:55:47 -0800

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 service between PEs in any MPLS network.

Please re-read what you just wrote. The fact that someone decided to leak host routes is NOT something that the IGP was designed to do. Leaking negative updates is also wrong. Two wrongs don’t make a right.

The fact that it is effectively providing liveness is wholly irrelevant. It’s still the wrong thing to do.

> If IGPs can provide full liveness service between PEs today, why doing 'optimized negative liveness service' would be architecturally wrong?

IGPs could also deliver web pages. Capability doesn’t imply that it’s architecturally appropriate. The IGP is supposed to provide reachability and path computation at local scale and with stability.  That’s it. One might well argue that we’re not doing that very well yet. Maybe we should stick to our knitting.

T

---

From: Peter Psenak <[email-masked]>
Date: Fri, 19 Nov 2021 18:03:38 +0100

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. IGPs are effectively providing 
>> liveness service between PEs in any MPLS network.
> 
> 
> Please re-read what you just wrote. The fact that someone decided to 
> leak host routes is NOT something that the IGP was designed to do. 
> Leaking negative updates is also wrong. Two wrongs don’t make a right.

host routes are just routes, like any other routes, for which IGP 
provide reachability. What's the length of the mask does not really 
matter. The fact that they are used for liveness by some application is 
also transparent to IGP.

> It’s still the wrong thing to do.

well, then I guess we just agree to disagree.

thanks,
Peter

> IGPs could also deliver web pages. Capability doesn’t imply that it’s 
> architecturally appropriate. The IGP is supposed to provide reachability 
> and path computation at local scale and with stability.  That’s it. One 
> might well argue that we’re not doing that very well yet. Maybe we 
> should stick to our knitting.
> 
> T
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 19 Nov 2021 21:25:08 +0100

Peter,

> 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 these multi-area deployments
> between PEs in any MPLS network.

That is true too - as folks just do not know how to configure BGP properly
(if BGP is used for services).

That leaves us the space what to do where there is no BGP carrying
services. Or BGP implementation is broken and can not do the right thing.

For the pulse proposal - no one answered the question posted what is a
definition of mass failure. But maybe that will be the secret sauce of a
vendor :) ?

The fact that we are all in agreement that some network events will not
work that well with the proposed solution seems to be a sufficient reason
for me to consider different solution(s).

Thx,
R.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 19 Nov 2021 20:45:09 +0000

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 the next version of the draft.

The substantive debate in my mind is that some people think it appropriate for IGP to advertise loss of reachability to destinations covered by an IGP originated summary advertisement and some folks do not.

Thanx.

   Les

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

Peter,

That is true too - as folks just do not know how to configure BGP properly (if BGP is used for services).

That leaves us the space what to do where there is no BGP carrying services. Or BGP implementation is broken and can not do the right thing.

For the pulse proposal - no one answered the question posted what is a definition of mass failure. But maybe that will be the secret sauce of a vendor :) ?

The fact that we are all in agreement that some network events will not work that well with the proposed solution seems to be a sufficient reason for me to consider different solution(s).

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 19 Nov 2021 22:29:45 +0100

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 however stability of the solution and deterministic
nature of it. Pulses are something really new and I guess getting
experience with it across zoo of vendors will be a significant effort.

Have you consider a different approach ? I recall we spoke about it long
time back. At least I recall talking with Stefano about it :) Just to
advertise bit vector with each summary where each bit covers a summary
member. 1 would indicate presence of /32 reachability in the area, 0 would
indicate lack of such atomic  prefix in an area.

No matter what happens you still advertise the same amount of information.
It is predictable and while one can argue that it will make IGP more chatty
clearly it will not be ON by default. And all machinery of pacing LSP/LSA
generation would apply automagically.

Further receiving node may act on this info in exactly the same way as it
would act on pulse.

Thx,
R.

On Fri, Nov 19, 2021 at 9:45 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Analogous (but not identical) controls can be applied to pulse
> advertisements – and should be. We will address that in the next version of
> the draft.
>
>
>
> The substantive debate in my mind is that some people think it appropriate
> for IGP to advertise loss of reachability to destinations covered by an IGP
> originated summary advertisement and some folks do not.
>
>
>
> Thanx.
>
>
>
>    Les
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Friday, November 19, 2021 12:25 PM
> *To:* Peter Psenak <ppsenak=[email-masked]>
> *Cc:* Tony Li <[email-masked]>; Les Ginsberg (ginsberg) <
> [email-masked]>; Gyan Mishra <[email-masked]>; Christian Hopps
> <[email-masked]>; Aijun Wang <[email-masked]>; lsr <
> [email-masked]>; Acee Lindem (acee) <[email-masked]>; Tony Przygienda <
> [email-masked]>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 19 Nov 2021 22:09:34 +0000

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 a very disciplined assignment of loopbacks by the network operator. You can comment on how reasonable an assumption that is better than I.
I also think the scale numbers discussed in the draft have increased significantly over the years – which further stresses the use of this approach.

   Les

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

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 however stability of the solution and deterministic nature of it. Pulses are something really new and I guess getting experience with it across zoo of vendors will be a significant effort.

Have you consider a different approach ? I recall we spoke about it long time back. At least I recall talking with Stefano about it :) Just to advertise bit vector with each summary where each bit covers a summary member. 1 would indicate presence of /32 reachability in the area, 0 would indicate lack of such atomic  prefix in an area.

No matter what happens you still advertise the same amount of information. It is predictable and while one can argue that it will make IGP more chatty clearly it will not be ON by default. And all machinery of pacing LSP/LSA generation would apply automagically.

Further receiving node may act on this info in exactly the same way as it would act on pulse.

Thx,
R.

On Fri, Nov 19, 2021 at 9:45 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert –

Thanx.

   Les

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

Peter,

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 19 Nov 2021 23:24:14 +0100

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 you brought IPv6 to this discussion :) If you think that one bit for
IPv6 next hop in a summary makes the idea not usable what happens when you
loose a dense POP and you need to pulse all atomic /128s being part of the
POP's TORs or compute if not kubernetes PODs in the computes. Even with
rate limit IGP may get hot pulsing ...

Thx,
R.

On Fri, Nov 19, 2021 at 11:09 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Robert –
>
>
>
> I believe you are referring to
> https://datatracker.ietf.org/doc/html/draft-swallow-isis-detailed-reach-01
> .
>
>
>
> The draft details a potential deployment scheme which depends upon a very
> disciplined assignment of loopbacks by the network operator. You can
> comment on how reasonable an assumption that is better than I.
>
> I also think the scale numbers discussed in the draft have increased
> significantly over the years – which further stresses the use of this
> approach.
>
>
>
>    Les
>
>
>
>
>
> *Sent:* Friday, November 19, 2021 1:30 PM
> *Cc:* Peter Psenak <ppsenak=[email-masked]>; Tony Li <
> [email-masked]>; Gyan Mishra <[email-masked]>; Christian Hopps <
> [email-masked]>; Aijun Wang <[email-masked]>; lsr <
> On Fri, Nov 19, 2021 at 9:45 PM Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
> Robert –
>
>
>

---

From: Aijun Wang <[email-masked]>
Date: Sat, 20 Nov 2021 11:40:00 +0800

Hi, Tony:

Aijun Wang
China Telecom

> On Nov 19, 2021, at 23:51, Tony Li <[email-masked]> wrote:
> 
> 
> Hi Aijun,
> 

[WAJ] Reachability is not equal to liveness, but the dead is equal to unreachability.  What we want is to alert other peer that some prefixes within the summary is unreachable and they should do some thing, for example, fast reroute to other nodes etc.
It is unreasonable that the ABR knows such unreachability but still claims that it can reach all the prefixes the summary address covered.

> Our job is to not design in mechanisms that lead to these bad outcomes.

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

> If you really want the service, please change the architecture to a registration mechanism as I outlined. This can and should be done outside of the IGP.  You’re asking for a proxy liveness service…

[WAJ] The registration mechanism, like BFD? requires the configuration overhead, is difficult to deploy in the large scale network. That the reason we prefer to the automatic mechanism.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 20 Nov 2021 11:53:00 +0100

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 does talks about other aspect of this mechanism.

Assume I have hierarchical IGP with 10,000 nodes.

Most PEs send service traffic to the local hubs only. Sporadically they may
send traffic to other PEs in other areas - say to 1% of them. Service
routes and most of remote next hops are dropped by RT filtering.

Tell me why do you propose a mechanism which puts burden on network
elements by blasting them with information they are never interested in ?
Leave alone that such information is completely not needed also on the P
routers in the core area and other areas.

Thx,
R.

---

From: Tony Li <[email-masked]>
Date: Sat, 20 Nov 2021 09:39:53 -0800

Hi Aijun,

> [WAJ] Reachability is not equal to liveness, but the dead is equal to unreachability.  

Sorry, no.  Dead is a lack of liveness.  You still have reachability.  You send packets and they still make it to the system. Ok, no one’s home and the packets fall on the floor, but they were delivered.

> What we want is to alert other peer that some prefixes within the summary is unreachable and they should do some thing, for example, fast reroute to other nodes etc.

Again, the ABR is claiming (and providing) reachability. You’re asking for negative liveness. That’s not something that routing protocols do, and can’t do without surrendering abstraction and scalability.

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

Those seem somewhat destructive. Not advertising the summary breaks all other services.  Instant network disaster. Having a threshold for the number of negative advertisements indicates that you don’t have a general, scalable solution.

> [WAJ] The registration mechanism, like BFD? requires the configuration overhead, is difficult to deploy in the large scale network. That the reason we prefer to the automatic mechanism.

No. You don’t need BFD.  You want a notification from the ABR.  This can be done automatically.  The ABR advertises that it provides a liveness notitification service as part of router capabilities. Interested parties open a connection to the ABR and indicate the hosts/prefixes that it is interested in. When there’s a failure, the ABR provides that indication. It can also provide a positive indication when the system is back up. True liveness!

Tony

---

From: Aijun Wang <[email-masked]>
Date: Sun, 21 Nov 2021 08:42:31 +0800

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 advertise as precise as liveness information, not the reachable but dead information. 
Pub/Sub style notification seems promising, but it will require the ABR store the subscription state which will certainly degrade its performance. 
On the other hand, let the receiver decides whether to utilize such information is distributed design and more robust? There is no much work to be done when they receive the PUAM message. Just to judge the originator of the prefix is valid or not.

Aijun Wang
China Telecom

> On Nov 21, 2021, at 01:40, Tony Li <[email-masked]> wrote:
> 
> 
> 
> Hi Aijun,
>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 21 Nov 2021 02:03:17 +0100

> 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 state/country, then city, then district/province, then
street. They do not blast you with pulses or stars that there is no one at
home or that restaurant is closed.

On the other hand some folks here state that while road signs are great
(summary analogy) we do need to know by road signs if the restaurant is
open before we head there. Hmm just imagine how would that work in
practice. Just imagine blasting this all over US when no one except few
folks is even interested in this information. Leave alone that their
infrastructure just is not designed to keep up with it.

Removing summary just because x % of restaurants are closed would be like
putting duct tape on traffic signs. Yes with the e-signs it is technically
possible but is this the right thing to do ?

If the restaurant is open you either use google service overlay (think BGP)
to tell you that with some amount of probability or you call them directly
and check before you jump into the car to drive (think directed in data
plane probe).

Last even if the restaurant is open there is no assurance they will take
your order when you arrive as they may experience power outage or run out
of rice for your favourite meal. So liveness of the PE does not really mean
that your service will be delivered.

Kind regards,
R.

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 20 Nov 2021 21:17:01 -0500

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
extension but then you pass the buck to MPLS which now is not scalable as
all the flooded prefixes are summarized in the IGP but now the LFIB has to
suffer from the domain wide flooding.

This issue with domain wide flooding gets much worse with seamless MPLS
with E2E LSP requirements from core to aggregation layer so now all the
area and levels within the entire domain had all host routes.  This can be
pretty tremendous for large operator networks and a huge scalability issue
that needs a solution.

See section 7.2

The solution documented in this document reduces the link state
database size in the control plane and the number of FIB
   entries in the forwarding plane.  As such, it solves the scaling of

   pure IP routers sharing the IGP with MPLS routers.  However, it does
   not decrease the number of LFIB entries so is not sufficient to solve
   the scaling of MPLS routers.  For this, an additional mechanism is
   required (e.g., introducing some MPLS hierarchy in LDP).  This is out
   of scope for this document.

Bottom of section 7.2

For protocols and applications which need to track egress LER
   availability, several solutions can be used, for example:

   - Rely on the LDP ordered label distribution control mode -- as
     defined in [LDP
<https://datatracker.ietf.org/doc/html/rfc5283#ref-LDP>] -- to know
the av.ailability of the LSP toward the

     egress LER.  The egress to ingress propagation time of that
     unreachability information is expected to be comparable to the IGP
     (but this may be implementation dependent).

   - Advertise LER reachability in the IGP for the purpose of the
     control plane in a way that does not create IP FIB entries in the
     forwarding plane.

Gyan> So for this to work for egress convergence availability tracking
you either are back to flooding the routes in the IGP or use LDP
ordered label distribution.

Even if you used LDP ordered label distribution is still does not
solve the problem of robbing Peter to pay Paul now dumping the
flooding of host routes on MPLS LFIB making it not scalable.

Most vendors by default use LDP ordered label distribution defined in RFC 3036.

However, net-net the problem is not solved.

Kind Regards

Gyan

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 20 Nov 2021 21:46:00 -0500

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

Gyan

On Sat, Nov 20, 2021 at 9:17 PM Gyan Mishra <[email-masked]> wrote:

> The solution documented in this document reduces the link state database size in the control plane and the number of FIB
>      defined in [LDP <https://datatracker.ietf.org/doc/html/rfc5283#ref-LDP>] -- to know the av.ailability of the LSP toward the
>
> Gyan> So for this to work for egress convergence availability tracking you either are back to flooding the routes in the IGP or use LDP ordered label distribution.
>
>
> Even if you used LDP ordered label distribution is still does not solve the problem of robbing Peter to pay Paul now dumping the flooding of host routes on MPLS LFIB making it not scalable.
>
>

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 20 Nov 2021 22:27:57 -0500

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 host routes is done for LSP to build within an AS,
however the domain wide flooding issue gets exacerbated with seamless MPLS
for E2E LSP  Core end Aggregation layers for Access layer E2E LSP.

RFC 5283 provides a LDP inter area extension however the specification
shifts the problem from the IGP RIB/FIB to  the MPLS LFIB.

So we don’t have a solution to be able to track component prefix host
routes that are part of a summary route to make summarization a viable
solution for MPLS.  This would allow us to use the RFC 5283 inter area LDP
extension and not have to flood the host routes into MPLS LFIB so can be
suppressed with LDP filter once we are able to track the component prefixes
that are part of the LPM summary FEC.

This solution would also help speed up convergence for LPM summarization
for IP based networks as well as  SRv6.

Kind Regards

Gyan

*Gyan Mishra*

*M 301 502-1347*

---

From: Aijun Wang <[email-masked]>
Date: Sun, 21 Nov 2021 11:30:34 +0800

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. The implementation/operator can open it only to the loop back address of the PE or Tunnel Ends.

Aijun Wang
China Telecom

> On Nov 21, 2021, at 09:03, Robert Raszuk <[email-masked]> wrote:
> 
> 
> 
> 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 state/country, then city, then district/province, then street. They do not blast you with pulses or stars that there is no one at home or that restaurant is closed. 
> 
> On the other hand some folks here state that while road signs are great (summary analogy) we do need to know by road signs if the restaurant is open before we head there. Hmm just imagine how would that work in practice. Just imagine blasting this all over US when no one except few folks is even interested in this information. Leave alone that their infrastructure just is not designed to keep up with it. 
> 
> Removing summary just because x % of restaurants are closed would be like putting duct tape on traffic signs. Yes with the e-signs it is technically possible but is this the right thing to do ? 
> 
> If the restaurant is open you either use google service overlay (think BGP) to tell you that with some amount of probability or you call them directly and check before you jump into the car to drive (think directed in data plane probe). 
> 
> Last even if the restaurant is open there is no assurance they will take your order when you arrive as they may experience power outage or run out of rice for your favourite meal. So liveness of the PE does not really mean that your service will be delivered. 
> 
> Kind regards,
> R.
>

---

From: Aditya Kaul <[email-masked]>
Date: Sun, 21 Nov 2021 12:56:12 +0800

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, 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 PE.I guess your other
assumption might relate to BGP service convergence being slower than the
IGP but then that's a different discussion.

Hopefully I am not misconstruing the thread's intent.

Regards,
Aditya

On Nov 21, 2021, at 11:30 AM, Aijun Wang <[email-masked]> wrote:

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. The
implementation/operator can open it only to the loop back address of the PE
or Tunnel Ends.

Aijun Wang
China Telecom

Really ???

Kind regards,
R.

---

From: Aijun Wang <[email-masked]>
Date: Sun, 21 Nov 2021 13:41:14 +0800

Hi, Aditya:

Aijun Wang
China Telecom

> On Nov 21, 2021, at 12:56, Aditya Kaul <[email-masked]> 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.

[WAJ] The IGP just to assure the road to the node or the node itself is available. If these are not available, even the BGP can dish out the cuisine, it is not available to the driver.

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

[WAJ] Normally, the RR does not sit inline the forwarding path among PEs, but ABR does. If the PEs span multiple areas, your design requires several pairs of RR, but indeed we need only one pair of them to accomplish the BGP sessions across different areas.

> I guess your other assumption might relate to BGP service convergence being slower than the IGP but then that's a different discussion.
>

---

From: Tony Li <[email-masked]>
Date: Sat, 20 Nov 2021 23:17:13 -0800

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 advertise its summary.

> Pub/Sub style notification seems promising, but it will require the ABR store the subscription state which will certainly degrade its performance. 

Baloney. A notification list address post-SPF is wholly outside of the performance path.

> On the other hand, let the receiver decides whether to utilize such information is distributed design and more robust? There is no much work to be done when they receive the PUAM message. Just to j…

Correct, you just flood information throughout the network that most of the nodes don’t care about, burdening others with additional flooding and database scale issues, just when there are failures.

Tony

---

From: Aijun Wang <[email-masked]>
Date: Sun, 21 Nov 2021 16:09:40 +0800

Hi, Tony:

Aijun Wang
China Telecom

> On Nov 21, 2021, at 15:17, Tony Li <[email-masked]> wrote:
> 
> 
> Hi Aijun,
> 

[WAJ] What the usage of the summary advertisement in such conditions excepts it misleads the nodes within the area it attached?
> Baloney. A notification list address post-SPF is wholly outside of the performance path.

[WAJ] Is there any existing mechanism to accomplish your proposal among the PEs?

> Correct, you just flood information throughout the network that most of the nodes don’t care about, burdening others with additional flooding and database scale issues, just when there are failures.

[WAJ] Within the network, the number of PEs often surpasses the number of P nodes. Even with P nodes, such information can also help them reroute/switch to other endpoints along the SRv6 tunnel backup path.
I think you could imagine the signal just as the alert information that often seen on the highway. It can certainly save the driver’s time. Wouldn’t you like to know such information immediately? Or you just drive as planned until near the target to know the road is broken?

---

From: Christian Hopps <[email-masked]>
Date: Sun, 21 Nov 2021 03:24:39 -0500

> On Nov 21, 2021, at 3:09 AM, Aijun Wang <[email-masked]> wrote:
> 
> Hi, Tony:
> 
> Aijun Wang
> China Telecom
> 

Perhaps it would help to consider another example of reachability vs liveness. Summaries are just one form of the more general concept of aggregation. Consider the Internet and aggregation done at the AS level. Would you have BGP flapping routes in the entire Internet based on hosts going up and down at the originating AS? No, we do not expect it. When you try to connect to a server in azure or aws etc you don’t expect routing to let you know that a server is down through an unreachable routing message, you expect TCP to tell you it can’t connect to it.

Thanks,
Chris.

---

From: Aijun Wang <[email-masked]>
Date: Sun, 21 Nov 2021 16:44:52 +0800

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 mentioned service.
But BGP NH or Tunnel Endpoint is relying on the IGP, knowing such unreachable information can certainly help the converge or switch of the overlay service on top of them, for example BGP PIC performance.

Aijun Wang
China Telecom

> On Nov 21, 2021, at 16:26, Christian Hopps <[email-masked]> wrote:
> 
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 21 Nov 2021 12:51:06 +0100

> 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 attached to host routes.
Stopping that breaks the game.

And btw LDP FECs where always host routes + label so unlike you say -
nothing new needed there. As I recall even TDP was carrying host addresses
with tags.

Thx,
R.

On Sun, Nov 21, 2021 at 3:46 AM Gyan Mishra <[email-masked]> wrote:

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

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 21 Nov 2021 12:56:36 +0100

Hi Aditya,

> ABR as NH and let ABR figure out the available egress PE.
>

Clever idea - unfortunately does not work :(

PEs along with next hop advertise service information (for example VPN
label demux) which is unfortunately not easy to synchronize across
multihomed site PEs.

So ABR can not set nhs and hide this complexity as it would have to swap
the VPN labels in the packets. If you want to make ABR acting as Option B
where they are full VPN gateways to the areas sure - that is deployed today
- but where most of the needs are for unreachable is when you use option C
or construct end to end path in one way or the other with no bottlenecks on
the way.

Thx,
R.

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 21 Nov 2021 11:19:31 -0500

> through the window this seems to be the current trend.

Gyan> SR-MPLS as it reuses the MPLS data plane but relies on IGP extension
to flood SID label instead of LDP for prefix and node SID it’s still exact
match host route so the solution we come up with for MPLS would apply to
SR-MPLS.  As for SRv6 it’s standard IP routing LPM based not FEC so
summarization natively works.  My thoughts for SRv6 is that the same
component host route tracking can be used as well with SRv6 or IPv4 or IPv6
forwarding plane.

> Stopping that breaks the game.

    Gyan> Agreed the flooding of host routes for seamless MPLS is a
requirement also for exact match FEC has to be a host route.

> nothing new needed there. As I recall even TDP was carrying host addresses

Gyan> Understood that LDP LIB and LFIB label mapping message FEC TLV has to
contain the exact match host route for the MPLS forwarding plane so
basically we are back in the same boat with RFC 5283 as it’s not a complete
solution as it just fixes the IGP RIB/FIB making summarization possible but
does not fix summarization with LDP as LDP still has to maintain all the
host routes.

I will try to work on MPLS based update to fix RFC 5283 so LDP can use
summarization LPM match.

Thx,
>> 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
>> So we desperately need a viable IGP summarization solution mitigate
>> domain wide flooding of host routes.
>>
>> Gyan
>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 21 Nov 2021 17:56:25 +0100

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 what is required.

Thx,
R.

On Sun, Nov 21, 2021 at 5:19 PM Gyan Mishra <[email-masked]> wrote:

> Gyan> Understood that LDP LIB and LFIB label mapping message FEC TLV has
> to contain the exact match host route for the MPLS forwarding plane so
>>>>> The fact that we are all in agreement that some network events will
>>>>> not work that well with the proposed solution seems to be a
>>>>> sufficient reason for me to consider different solution(s).
>>>>>
>>>>> Thx,
>>>>> R.
>>>>>
>>>> --
>>>>

---

From: Tony Li <[email-masked]>
Date: Sun, 21 Nov 2021 09:10:39 -0800

Hi Aijun,

> [WAJ] What the usage of the summary advertisement in such conditions excepts it misleads the nodes within the area it attached?

I think Chris answered this adequately.

> [WAJ] Is there any existing mechanism to accomplish your proposal among the PEs?

No, there is no existing mechanism.  PUAM is one new mechanism. I’m suggesting another one that’s architecturally cleaner.

> I think you could imagine the signal just as the alert information that often seen on the highway. It can certainly save the driver’s time. Wouldn’t you like to know such information immediately? O…

What I would like is if there was a centralized service, such as Google Maps, that simply did the path computation for me and updated it in real time. :)

Interestingly, that information isn’t flooded. It’s built with a scalable back end service and then unicast to the end user.

T

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 21 Nov 2021 12:56:54 -0500

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 need to
domain wide flood the loopbacks for SR-MPLS for prefix and node SID for
steering and for SRv6 as well would have to flood locators, prefix and node
SID as well as for seamless MPLS style building of E2E path as it does
apply to SR framework.

So I agree we would need IGP extension for both SR-MPLS and SRV6 for ABR &
ASBR summarization to avoid domain wide flooding seamless MPLS E2E path
instantiation.

Kind Regards

Gyan

On Sun, Nov 21, 2021 at 11:56 AM Robert Raszuk <[email-masked]> wrote:

>> Gyan> SR-MPLS as it reuses the MPLS data plane but relies on IGP
>> extension to flood SID label instead of LDP for prefix and node SID it’s
>> still exact match host route so the solution we come up with for MPLS would
>> apply to SR-MPLS.  As for SRv6 it’s standard IP routing LPM based not FEC
>> so summarization natively works.  My thoughts for SRv6 is that the same
>>>>> This issue with domain wide flooding gets much worse with seamless
>>>>> MPLS with E2E LSP requirements from core to aggregation layer so now all
>>>>> the area and levels within the entire domain had all host routes.  This can
>>>>> be pretty tremendous for large operator networks and a huge scalability
>>>>> issue that needs a solution.
>>>>>
>>>>> See section 7.2
>>>>>
>>>>>> For the pulse proposal - no one answered the question posted what is
>>>>>> a definition of mass failure. But maybe that will be the secret sauce of a
>>>>>> vendor :) ?
>>>>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 22 Nov 2021 10:47:52 +0800

Hi, Tony:

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Tony Li
Sent: Monday, November 22, 2021 1:11 AM
To: Aijun Wang <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <[email-masked]>; Christian Hopps <[email-masked]>; lsr <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Tony Przygienda <[email-masked]>
Subject: 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. overlay services are depending on the IGP, then knowing the unreachable information can certainly accelerate their convergence and switchover to the backup endpoints.

[WAJ] As I explained below, PUAM information is needed not only the PEs(for BGP scenario), but may be used by P router within the network(for Tunnel scenario). As also I explained previously, the implementation/operator can limit the PUAM only for /32 or /128 loopback address, which will not sacrifice the scalability of IGP, and at the same time, accelerate the convergence of the overlay services that depends on it.

Comparing with utilizing the existing procedures, Introducing another mechanism, such as centralize service, PUB/SUB mechanism as you proposed, isn't it more complex and less efficient? All the procedures that we considered will not omitted, the difference is only how to transfer the message.

T

Lsr mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/lsr> https://www.ietf.org/mailman/listinfo/lsr

---

From: Tony Li <[email-masked]>
Date: Sun, 21 Nov 2021 18:57:34 -0800

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/ <https://mailarchive.ietf.org/arch/msg/lsr/HBUDX5lcbcrKuPK1R7MbNC-mcGA/>

Yes, but you missed the point that BGP should carry the reachability in the first place and then the BGP withdraw would give you what you want.

Yes, I certainly understand that you want to change the IGP behavior to accomodate tunnel convergence. That part is quite clear.
We do not want to flood the negative liveness information in the IGP. That’s not its job, architecturally.

> Comparing with utilizing the existing procedures, Introducing another mechanism, such as centralize service, PUB/SUB mechanism as you proposed, isn't it more complex and less efficient? All the pro…

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.

Yes, it is more complex and harder than simply flooding things. It’s also much more likely to actually work well at scale and under stress.

It’s pretty common that you can either do things the right way or you can do things the easy way.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 22 Nov 2021 05:46:57 +0000

Tony -

[LES:] As I have stated previously, I share your concern about the behavior during massive events – and some care has to be taken to prevent making a bad situation worse.
That said, the WG (including you and I)  is taking on enhancements to support much faster flooding – on the order of hundreds (perhaps thousands) of LSPs/second. We believe this can be done safely (though proof has not yet been established).
So, if you believe (as your active participation suggests) that IGPs can support faster flooding – why do you believe they cannot support liveness notification at a similar scale?

I get that you consider such notifications as architecturally undesirable – we can agree to disagree on that point.
But I don’t get why you think the IGP’s ability to handle large scale events is a showstopper in this case.

    Les

Tony

---

From: Tony Li <[email-masked]>
Date: Sun, 21 Nov 2021 22:55:44 -0800

Les,

> That said, the WG (including you and I)  is taking on enhancements to support much faster flooding – on the order of hundreds (perhaps thousands) of LSPs/second. We believe this can be done safely…

And the point of doing that was to help improve IGP convergence time…

> So, if you believe (as your active participation suggests) that IGPs can support faster flooding – why do you believe they cannot support liveness notification at a similar scale?

… not waste our time by inflating the LSDB by the same amount that we sped up flooding.

Also, I don’t see how faster flooding has ANYTHING to do with it. Adding negative liveness information is primary a scale issue.

> But I don’t get why you think the IGP’s ability to handle large scale events is a showstopper in this case.

I am opposed to anything that adds to the scale of the LSDB. Doubly so if it does so during failures, when the IGP is already under stress. As you well know, making an IGP stable during normal operations is one thing. Ensuring that it is stable during worst case topological changes is quite another. Adding scale during a mass failure is pessimal timing.

T

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 22 Nov 2021 07:45:04 +0000

Tony –

I have been trying to gain a better understanding of your thinking – thanx for your responses which have helped in that regard.

I am not trying to convince you of anything – just want to add a few comments:

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 individual prefixes it knew about all the time. (Whether that is a wise choice in a given deployment is another matter.)

As to scale, you are making the assumption that a solution cannot be provided without introducing significant scale issues – but I don’t think that is the case.
I don’t want to use this thread to advocate for one candidate solution over another – I think that is best addressed in some subsequent thread. Just want to point out that the solution does not have to have the same scale characteristics as having no summaries.

Thanx for the discussion.

    Les

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

Les,

T

---

From: Peter Psenak <[email-masked]>
Date: Mon, 22 Nov 2021 11:12:08 +0100

On 22/11/2021 08:45, Les Ginsberg (ginsberg) wrote:
> Tony –
> 
> I have been trying to gain a better understanding of your thinking – 
> thanx for your responses which have helped in that regard.
> 
> 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 
> individual prefixes it knew about all the time. (Whether that is a wise 
> choice in a given deployment is another matter.)

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 that, it has been used very successfully for 
last 30 years.

thanks,
Peter

> 
> As to scale, you are making the assumption that a solution cannot be 
> provided without introducing significant scale issues – but I don’t 
> think that is the case.
> 
> I don’t want to use this thread to advocate for one candidate solution 
> over another – I think that is best addressed in some subsequent thread. 
> Just want to point out that the solution does not have to have the same 
> scale characteristics as having no summaries.
> 
> *Sent:* Sunday, November 21, 2021 10:56 PM
> *Cc:* Aijun Wang <[email-masked]>; Gyan Mishra 
> <[email-masked]>; Christian Hopps <[email-masked]>; lsr 
> <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Tony Przygienda 
> <[email-masked]>
> *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 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 previously, I share your concern about the
>     behavior during massive events – and some care has to be taken to
>     prevent making a bad situation worse./*
> 
>     */That said, the WG (including you and I)  is taking on enhancements
>     to support much faster flooding – on the order of hundreds (perhaps
>     thousands) of LSPs/second. We believe this can be done safely
>     (though proof has not yet been established)./*
> 
>     */So, if you believe (as your active participation suggests) that
>     IGPs can support faster flooding – why do you believe they cannot
>     support liveness notification at a similar scale?/*
> 
> Also, I don’t see how faster flooding has ANYTHING to do with it. Adding 
> negative liveness information is primary a scale issue.
> 
> */
> 
> /*
> 
> *//*
> 
>     */I get that you consider such notifications as architecturally
>     undesirable – we can agree to disagree on that point./*
> 
>     */But I don’t get why you think the IGP’s ability to handle large
>     scale events is a showstopper in this case./*
> 
> I am opposed to anything that adds to the scale of the LSDB. Doubly so 
> if it does so during failures, when the IGP is already under stress. As 
> you well know, making an IGP stable during normal operations is one 
> thing. Ensuring that it is stable during worst case topological changes 
> is quite another. Adding scale during a mass failure is pessimal timing.
> 
> T
>

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 22 Nov 2021 11:43:40 +0100

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 disturbances or you make hard architectural
choices & scale much better over time". Examples of that are abound in
systems design but it's unfortunately often RFC1295 (4). As a sidenote:
IETF has no intention or mechanism to stop people doing unscalable, poorly
designed things with their specs and that was ok as long people did not try
to push them onto the whole world without listening to folks who took the
scar tissue to get us the IETF working specs we have today which seems to
have become fashionable in last couple of years.

And fast flooding is a red herring here IMO, it does nothing but accelerate
the control loop, if the control loop is positively stable, it's good, if
the control loops are oscillating or start to negatively amplify
accelerating things just melts everything faster.

Ultimately, having followed this "discussion" my opinion is still that if
authors would like to abuse IGP as "domain wide broadcast" for liveliness
notification the "events" draft is far less fragile and convoluted but
should be kept in a service instance as basically "event based BFD
substitute" to not start to cause head-blocking on IGP resources. And AFAIR
Robert observed it's still not a very good indication compared to BFD, a
good solution would be e.g. in PE case a (hierarchical) MP2MP BFD PMSI
(assuming UDP healthy = TCP healthy which is however far less an assumption
than "flooding feels transport is OK").

-- tony

On Mon, Nov 22, 2021 at 7:55 AM Tony Li <[email-masked]> wrote:

>
> 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 have stated previously, I share your concern about the
> behavior during massive events – and some care has to be taken to prevent
> making a bad situation worse.*
> *That said, the WG (including you and I)  is taking on enhancements to
> support much faster flooding – on the order of hundreds (perhaps thousands)
> of LSPs/second. We believe this can be done safely (though proof has not
> yet been established).*
>
>
>
> *So, if you believe (as your active participation suggests) that IGPs can
> support faster flooding – why do you believe they cannot support liveness
> notification at a similar scale?*
>
>
>
> *I get that you consider such notifications as architecturally undesirable
> – we can agree to disagree on that point.*
> *But I don’t get why you think the IGP’s ability to handle large scale
> events is a showstopper in this case.*
>
>
>
> I am opposed to anything that adds to the scale of the LSDB. Doubly so if
> it does so during failures, when the IGP is already under stress. As you
> well know, making an IGP stable during normal operations is one thing.
> Ensuring that it is stable during worst case topological changes is quite
> another. Adding scale during a mass failure is pessimal timing.
>
> T
>
>
>

---

From: Aijun Wang <[email-masked]>
Date: Mon, 22 Nov 2021 20:18:18 +0800

Aijun Wang
China Telecom

> On Nov 22, 2021, at 18:44, Tony Przygienda <[email-masked]> 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 says "you either make easy choices and get an operationally unstable environment at scale/large disturbances or you make hard architectural choices & scale much better over time".

[WAJ] Easy choices doesn’t definitely get operationally unstable environment(we have explained in previous mails). And would you give some examples to illustrate “hard architecture but scale much better over time?”

> Examples of that are abound in systems design but it's unfortunately often RFC1295 (4). As a sidenote: IETF has no intention or mechanism to stop people doing unscalable, poorly designed things with their specs

[WAJ] like RIFT or flood reflector solutions in IGP?

> and that was ok as long people did not try to push them onto the whole world without listening to folks who took the scar tissue to get us the IETF working specs we have today which seems to have become fashionable in last couple of years. 
> 
> And fast flooding is a red herring here IMO, it does nothing but accelerate the control loop, if the control loop is positively stable, it's good, if the control loops are oscillating or start to negatively amplify accelerating things just melts everything faster. 

[WAJ] There is no control loop oscillation. We track only the down event.
> 
> Ultimately, having followed this "discussion" my opinion is still that if authors would like to abuse IGP as "domain wide broadcast" for liveliness notification the "events" draft is far less fragile and convoluted but should be kept in a service instance as basically "event based BFD substitute" to not start to cause head-blocking on IGP resources.

[WAJ] Seems you are not listening other person’s discussion. Please refer to Acee’s comments at https://mailarchive.ietf.org/arch/msg/lsr/zzaPetGzjHsu49KcyBrixQlo5G8/

> And AFAIR Robert observed it's still not a very good indication compared to BFD, a good solution would be e.g. in PE case a (hierarchical) MP2MP BFD PMSI (assuming UDP healthy = TCP healthy which is however far less an assumption than "flooding feels transport is OK"). 

[WAJ] Current solutions are not aimed only the BGP overlay service, but also the tunnel services. For tunnel services how you build MP2MP PMSI?

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 22 Nov 2021 08:53:41 -0500

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 <[email-masked]>
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.
>
> choices & scale much better over time".
>
>
> [WAJ] Easy choices doesn’t definitely get operationally unstable
> environment(we have explained in previous mails). And would you give some
> examples to illustrate “hard architecture but scale much better over time?”
>
> Examples of that are abound in systems design but it's unfortunately often
> RFC1295 (4). As a sidenote: IETF has no intention or mechanism to stop
> people doing unscalable, poorly designed things with their specs
>
>
> and that was ok as long people did not try to push them onto the whole
> world without listening to folks who took the scar tissue to get us the
> IETF working specs we have today which seems to have become fashionable in
> last couple of years.
>
>
> And fast flooding is a red herring here IMO, it does nothing but
> accelerate the control loop, if the control loop is positively stable, it's
> good, if the control loops are oscillating or start to negatively amplify
> substitute" to not start to cause head-blocking on IGP resources.
>
>
> [WAJ] Seems you are not listening other person’s discussion. Please refer
> to Acee’s comments at
> https://mailarchive.ietf.org/arch/msg/lsr/zzaPetGzjHsu49KcyBrixQlo5G8/
>
> And AFAIR Robert observed it's still not a very good indication compared
> to BFD, a good solution would be e.g. in PE case a (hierarchical) MP2MP BFD
> PMSI (assuming UDP healthy = TCP healthy which is however far less an
> assumption than "flooding feels transport is OK").
>
>
> [WAJ] Current solutions are not aimed only the BGP overlay service, but
> also the tunnel services. For tunnel services how you build MP2MP PMSI?
>
>
> -- tony
>
>> *I get that you consider such notifications as architecturally
>> undesirable – we can agree to disagree on that point.*

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 22 Nov 2021 14:59:30 +0100

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 <[email-masked]> wrote:

>> As he says "you either make easy choices and get an operationally
>> unstable environment at scale/large disturbances or you make hard
>> architectural choices & scale much better over time".
>>
>>
>> Examples of that are abound in systems design but it's unfortunately
>> often RFC1295 (4). As a sidenote: IETF has no intention or mechanism to
>> stop people doing unscalable, poorly designed things with their specs
>>
>>
>>> *So, if you believe (as your active participation suggests) that IGPs
>>> can support faster flooding – why do you believe they cannot support
>>> liveness notification at a similar scale?*
>>>
>>>
>>>
>>> if it does so during failures, when the IGP is already under stress. As you

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 22 Nov 2021 15:00:58 +0100

> would be. But regardless of that, it has been used very successfully for

No. Please read RFC5283.

Thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Mon, 22 Nov 2021 15:11:55 +0100

>     would be. But regardless of that, it has been used very successfully

and how many SPs have deployed it?

Hardly any, and maybe because of what is described in section-7.2

"For LER failure, given that the IGP
  aggregates IP routes on ABRs and no longer advertises specific
  prefixes, the control plane and more specifically the routing
  convergence behavior of protocols (e.g., [MP-BGP]) or applications
  (e.g., [L3-VPN]) may be changed in case of failure of the egress LER
  node."

And what RFC5283 suggests in the same section is:

     "Advertise LER reachability in the IGP for the purpose of the
      control plane in a way that does not create IP FIB entries in the
      forwarding plane."

Above defeats the prefix aggregation.

Peter

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 22 Nov 2021 15:26:01 +0100

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.

As example - some vendors support ordered LDP mode some do not. Some
support BGP recursion some do not. And the story goes on.

But I am not sure what point are you insisting on arguing ... If it is ok
to run host routes across areas we have no problem to start with so why to
propose anything new there.

Moreover as you very well know tons of opaque stuff is attached today to
leaked host routes and this curve is going up. So when you summarise you
stop propagating all of this. Is this really ok ?

Do not get me wrong I love summarization but it seems as discussed off line
- we would be much better to leak host routes with opaque stuff when needed
rather then then leak blindly everything everywhere.

Cheers,
R.

---

From: Peter Psenak <[email-masked]>
Date: Mon, 22 Nov 2021 15:40:39 +0100

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.
> 
> But I am not sure what point are you insisting on arguing ... If it is 
> ok to run host routes across areas we have no problem to start with so 
> why to propose anything new there.

all I'm trying to say is that IGPs do advertise host routes across areas 
today. Yes, it is sub-optimal, but hardly architecturally incorrect 
IMHO. We want to improve and allow effective use of aggregation, while 
keeping the fast notification about egress PE reachability loss in place 
to help overlay protocols converge fast. The situation would be much 
improved compared to what we have today.

thanks,
Peter

> Do not get me wrong I love summarization but it seems as discussed off 
> line - we would be much better to leak host routes with opaque stuff 
> when needed rather then then leak blindly everything everywhere.
> 
> Cheers,
> R.
> 
> 
> 
> 
> On Mon, Nov 22, 2021 at 3:12 PM Peter Psenak <[email-masked] 
>      >     would be. But regardless of that, it has been used very
>     successfully
>      >     for
>      >     last 30 years.
>      >
>      >
>      > No. Please read RFC5283.
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 22 Nov 2021 09:56:14 -0500

+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 today real world scenario.

Summarization is a tremendous optimization for operators.

With RFC 5283 the issue why it was never deployed is that it fixes half the
problem.  If fixed the IGP for with the LDP inter area extension can now
support LPM IGP match summarization so the RIB/FIB is optimized, however
the LFIB still has to maintain all the host routes FEC binding RFC 5036.

With the RFC 5283 solution we still have to track the liveliness of the
egress LSR which states can be done by advertising reachability via IGP and
then you are back to domain wide flooding even in the IGP.

Section 7.2

Here stated the LFIB remains not optimized

- The solution documented in this document reduces te link state
database size in the control plane and the number of FIB
   entries in the forwarding plane.  As such, it solves the scaling of

So this is quite unfortunate for RFC 5283 and why it was never
deployed by operators.

SRv6 is an answer but majority of all SPs are not there yet and we need to
be able support MPLS for a long time to come beyond our lifetime.

Kind Regards

Gyan

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 22 Nov 2021 16:14:08 +0100

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 routes from one
area/ASN would need to be magically transponded between ASBRs (all under
same administration). We know how to do that with host routes using say
RFC3107 safi 4.

How would one propagate those pulses ? New BGP SAFI ?

Put it back to BGP sounds like a problem on its own as some folks here just
do not get the concept of BGP recursion and that BGP can signal next hops
going down in milliseconds (+detection time + light propagation time)
across your network.

Thx,
R.

On Mon, Nov 22, 2021 at 3:56 PM Gyan Mishra <[email-masked]> wrote:

> With RFC 5283 the issue why it was never deployed is that it fixes half
> the problem.  If fixed the IGP for with the LDP inter area extension can
> now support LPM IGP match summarization so the RIB/FIB is optimized,
> however the LFIB still has to maintain all the host routes FEC binding RFC
> 5036.
>
> - The solution documented in this document reduces te link state database size in the control plane and the number of FIB
> So this is quite unfortunate for RFC 5283 and why it was never deployed by operators.
>
>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 22 Nov 2021 16:53:36 +0100

Robert,

On 22/11/2021 16:14, Robert Raszuk wrote:
> routes are present everywhere. MPLS networks build in early 2000s are 
> still running as is.
> 

depends on how domains are interconnected.

If it is done without BGP, using IGP redistribution, that can be done 
for pulses as well. No standardization required.

If there is BGP in between these IGP domains inside the SP network, you 
typically are carrying the PE loopbacks inside BGP itself. If not and 
you want to benefit from the pulses, you would have to define something 
in BGP to carry them between ASs.

thanks,
Peter

> Put it back to BGP sounds like a problem on its own as some folks here 
> just do not get the concept of BGP recursion and that BGP can signal 
> next hops going down in milliseconds (+detection time + light 
> propagation time) across your network.
> 
> Thx,
> R.
> 
> 
> 
> 
> 
> 
> On Mon, Nov 22, 2021 at 3:56 PM Gyan Mishra <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     +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 today real world scenario.
> 
>     With RFC 5283 the issue why it was never deployed is that it fixes
>     half the problem.  If fixed the IGP for with the LDP inter area
>     extension can now support LPM IGP match summarization so the RIB/FIB
>     is optimized, however the LFIB still has to maintain all the host
>     routes FEC binding RFC 5036.
> 
>     With the RFC 5283 solution we still have to track the liveliness of
>     the egress LSR which states can be done by advertising reachability
>     via IGP and then you are back to domain wide flooding even in the IGP.
> 
>     Section 7.2
> 
>     SRv6 is an answer but majority of all SPs are not there yet and we
>     need to be able support MPLS for a long time to come beyond our
>     lifetime.
> 
>     Kind Regards
> 
>     Gyan
> 
>     On Mon, Nov 22, 2021 at 9:40 AM Peter Psenak <[email-masked]
>          > On Mon, Nov 22, 2021 at 3:12 PM Peter Psenak
>         <[email-masked] <mailto:[email-masked]>
>          > <mailto:[email-masked] <mailto:[email-masked]>>> 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 that, it has been used
>         very
>          >     successfully
>          >      >     for
>          >      >     last 30 years.
>          >      >
>          >      >
>          >      > No. Please read RFC5283.
>          >
>          >      >
>          >      > Thx,
>          >      > R.
>     /Network Solutions A//rchitect /
> 
>     /Email [email-masked] <mailto:[email-masked]>//
>     /
> 
>     /M 301 502-1347
> 
>     /
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 22 Nov 2021 10:59:51 -0500

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 and can use LPM match  as the SRv6 locators
can be LPM summary routes in steering between areas with way point SR-TE
 BSID policies on ABRs or ASBRs to stitch the E2E path.

SRv6-BE BGP service overlay the egress PE  signals the L2 L3 VPN service
SID for BGP overlay route to SR source node or for SRv6-TE egress PE colors
overlay route using RFC 9012 Color extended community for the E2E path
instantiation.

As the signaling is egress to ingress for the path instantiation,   the
seamless MPLS style domain wide flooding for E2E LSP stateful path is not
required.

However summarization is still valuable in an SRv6 domain for summarization
of SIDs flooded via SRv6 IGP extension domain wide.

Kind Regards

Gyan

On Mon, Nov 22, 2021 at 8:59 AM Robert Raszuk <[email-masked]> wrote:

>>> Ultimately, having followed this "discussion" my opinion is still that
>>> if authors would like to abuse IGP as "domain wide broadcast" for
>>> liveliness notification the "events" draft is far less fragile and
>>> convoluted but should be kept in a service instance as basically "event
>>> based BFD substitute" to not start to cause head-blocking on IGP resources.
>>>
>>>
>>> [WAJ] Seems you are not listening other person’s discussion. Please
>>> refer to Acee’s comments at
>>>> Also, I don’t see how faster flooding has ANYTHING to do with it.
>>>> Adding negative liveness information is primary a scale issue.
>>>>
>>>>
>>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Tony Li <[email-masked]>
Date: Mon, 22 Nov 2021 08:52:13 -0800

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

The IGP knows many things. I object to adding things to the LSDB that aren’t already there. If people want to leak things outside of the area, I object to that. I know that people do it already. Yes, there are valid cases where it’s necessary and there are tools to do it. People abuse the privilege and then wonder why their IGP has indigestion. Go figure.

I object to adding negative liveness to the LSDB because of the scale and because it adds scale during failures.

> I don’t want to use this thread to advocate for one candidate solution over another – I think that is best addressed in some subsequent thread. Just want to point out that the solution does not hav…

My understanding is that N node failures would result in O(N) bytes added to the LSDB.  If someone has a way to compress that information to O(1), I (and Claude Shannon) would be interested.

Tony

---

From: Christian Hopps <[email-masked]>
Date: Mon, 22 Nov 2021 16:29:19 -0500

Gyan Mishra <[email-masked]> writes:

> 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 today real world scenario.
>

I'm having a hard time imagining 300,000 or 500,000 PEs that need this "liveness as a host route" notification for. Where are these hundreds of thousands of hosts coming from that ever need to be in the IGP?

Large operators may have prefixes for each of their internal links or each of their router loopback addresss, so this can lead to 1000s of routes; however, it does not imply 100 times that many host routes being present at all.

Perhaps this is just a hole in my knowledge though.

Thanks,
Chris.

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 23 Nov 2021 00:05:28 -0500

On Mon, Nov 22, 2021 at 4:35 PM Christian Hopps <[email-masked]> wrote:

> I'm having a hard time imagining 300,000 or 500,000 PEs that need this
> "liveness as a host route" notification for. Where are these hundreds of
> thousands of hosts coming from that ever need to be in the IGP?
>
> Large operators may have prefixes for each of their internal links or each
> of their router loopback addresss, so this can lead to 1000s of routes;
> however, it does not imply 100 times that many host routes being present at
> all.
>

Gyan> For large operators running MPLS in order to support seamless Unified
/ Seamless MPLS the requirements for domain wide flooding from Core to
Aggregation layers made up of many areas.  A typical large operator would
easily have 10k nodes in each aggregation domain with a 100 aggregation
domains plus the backbone Level 2 nodes over 1000+  with multiple  large
Level 1 areas tie to aggregation layer.

The loopbacks are flooded but are carried in BGP-LU labeled unicast RIB
inter domain, also hierarchical MPLS CSC is utilized as well so that does
reduce the impact of flooding.

So only within an aggregation domain would you have all the loopbacks
flooded in the IGP but going between aggregation domains to access layer
connectivity it would be all BGP-LU RIB with  hierarchical MPLS between
core and aggregation layers.

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

*Gyan Mishra*

*M 301 502-1347*

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 23 Nov 2021 15:16:09 +0800

Hi, Tony:

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

Les,

 

The IGP knows many things. I object to adding things to the LSDB that aren’t already there.

[WAJ] Then, how to explain the newly defined “Dynamic Flooding LSA” in https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding-09, which is not already in LSDB before?

If people want to leak things outside of the area, I object to that. I know that people do it already. Yes, there are valid cases where it’s necessary and there are tools to do it. People abuse the privilege and then wonder why their IGP has indigestion. Go figure.

[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 some overlay services(which defeat the user experiences).

Within the real network, there is very rare chance for the massive failure. And even such thing happen accidently, the information about node liveness is countable, is there any router can’t process such information?

The received unreachable information does not trigger the SPF calculation. Will they influence intensively the performance of the router?

 

[WAJ] Do you have other determined solutions except the PUB/SUB mechanism that does not exist in current IGP?

Tony

---

From: Peter Psenak <[email-masked]>
Date: Tue, 23 Nov 2021 09:30:18 +0100

Hi Chris,

> I'm having a hard time imagining 300,000 or 500,000 PEs that need this "liveness as a host route" notification for. Where are these hundreds of thousands of hosts coming from that ever need to be i…

It's more like tens of thousands from what I have seen.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 23 Nov 2021 09:39:38 +0100

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 failure and react to it in your RP/RE
regardless how it is signalled. If triggered by ABRs you not only need to
detect the failure of a node, but also flood it locally within the local
area.

Light propagation speed last time I checked does not seems to be different
for BGP vs OSPF/ISIS packets.

Thx,
R.

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 23 Nov 2021 17:03:54 +0800

Hi, Robert:

When the node is failed, or is detached from the network, it can’t send the BGP update to other peers already.

And, as we have discussed, the potential usage of such information is not only BGP, but may be tunnel endpoints.

Yes, I agree, the light speed is the same.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Robert Raszuk
Sent: Tuesday, November 23, 2021 4:40 PM
To: Aijun Wang <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <[email-masked]>; Christian Hopps <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Tony Przygienda <[email-masked]>
Subject: 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 failure and react to it in your RP/RE regardless how it is signalled. If triggered by ABRs you not only need to detect the failure of a node, but also flood it locally within the local area. 

Light propagation speed last time I checked does not seems to be different for BGP vs OSPF/ISIS packets. 

Thx,

R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 23 Nov 2021 11:03:29 +0100

> When the node is failed, or is detached from the network, it can’t send
the BGP update to other peers already.

LOL ... that's given. Same for IGP too.

The UPDATE will be generated by the BGP peer of such node - typically RR.
And if you run BFD on that session it can be as fast as loosing IGP adj to
an IGP neighbour of the failing node.

Cheers,
R.

On Tue, Nov 23, 2021 at 10:03 AM Aijun Wang <[email-masked]>
wrote:

> *From:* [email-masked] <[email-masked]> *On Behalf Of *Robert
> Raszuk
> *Sent:* Tuesday, November 23, 2021 4:40 PM
> *Cc:* Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <
> [email-masked]>; Christian Hopps <[email-masked]>; Tony Li <
> [email-masked]>; lsr <[email-masked]>; Acee Lindem (acee) <[email-masked]>;
> Tony Przygienda <[email-masked]>

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 23 Nov 2021 11:14:09 +0100

> It's more like tens of thousands from what I have seen.

I don't know the specific network talked about here by Guayn where he
claims to see 100s of Ks of host routes on a router  either. Though IME
seeing igp RIB is excess of few 10Ks routes (in a single instance/topology)
is quiet exceptional for a lot of practical reasons in real deployments.

As side discussion, I'm getting lost how a SRv6 PE-PE is somehow a
drastically different, novel way of addressing tunnel endpoints. Nothing
prevents you from summarizing (v6) loopback addresses on PEs AFAIS in any
other tunneling technology (that preconditions having an addressing
discipline of course but it seems the same is true for SRv6). I stand
enlightened but AFAIS a tunnel is a tunnel is a tunnel, what we talk about
here is adding something that provides a partial (since it does not verify
the data path needed for the control or transport tunnels) SSAP liveliness
indication to IGP on whatever endpoint (which happens in IP being roughly
<address>:port whereas we imply by a loss of address the loss of all
services which in itself is an assumption which is probably fair enough as
long BGP has all services on the same routing instance, not a given thing
in the future AFAIS ;-) Where I agree with TLi again that it's not
something that should be in IGP scope (or at minimum not shared with the
instance responsible to do the IP reachability computation).

-- tony

>
> thanks,
> Peter
>
> >
> > Large operators may have prefixes for each of their internal links or
> each of their router loopback addresss, so this can lead to 1000s of
> routes; however, it does not imply 100 times that many host routes being
> present at all.
> >

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 23 Nov 2021 11:18:56 +0100

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

---

From: Aijun Wang <[email-masked]>
Date: Tue, 23 Nov 2021 19:38:37 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 23, 2021, at 18:04, Robert Raszuk <[email-masked]> wrote:
> 
> 
> 
> The UPDATE will be generated by the BGP peer of such node - typically RR. And if you run BFD on that session it can be as fast as loosing IGP adj to an IGP neighbour of the failing node. 
[WAJ] Then you depend again the BFD session which there is configuration overhead. For IGP solution, the BFD is not required. 
And, for tunnels situations, where you configure the monitor peer?

Aijun Wang
China Telecom

> 
> Cheers,
> R.
> 
> 
> 
> 
>> On Tue, Nov 23, 2021 at 10:03 AM Aijun Wang <[email-masked]> wrote:
>> Hi, Robert:
>> 
>>  
>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 23 Nov 2021 12:41:49 +0100

> For IGP solution, the BFD is not required.

Excuse me ?

BFD is used on vast majority of the WAN links today as those links are not
always dark fiber such that you can detect LOS. Those WAN links are
(unfortunately) emulated circuits which require BFD to detect failure in a
reasonable time.

I hope you are not talking about IGP hellos or BGP keepalives here.

We are talking PE-P or PE-RR.

Thx,
R.

On Tue, Nov 23, 2021 at 12:38 PM Aijun Wang <[email-masked]>
wrote:

> [WAJ] Then you depend again the BFD session which there is configuration
> overhead. For IGP solution, the BFD is not required.

---

From: Aijun Wang <[email-masked]>
Date: Tue, 23 Nov 2021 19:53:59 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 23, 2021, at 19:42, Robert Raszuk <[email-masked]> wrote:
> 
> 
> 
> BFD is used on vast majority of the WAN links today as those links are not always dark fiber such that you can detect LOS. Those WAN links are (unfortunately) emulated circuits which require BFD to detect failure in a reasonable time. 
> 

[WAJ] Once there is a link/node failure, upon receiving the updated LSA, the ABR can calculate the missed prefixes within its attached area, as described in https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-4

> 
> Thx,
> R.
> 
> 
> 
>> On Tue, Nov 23, 2021 at 12:38 PM Aijun Wang <[email-masked]> wrote:
>> Hi, Robert:
>> 
>> Aijun Wang
>> China Telecom
>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 23 Nov 2021 13:00:25 +0100

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 or
CFM etc.... That is way before ABR will receive any LSA/LSP from the
adjacent nodes informing it of the failed adj. And in fact all such adj
nodes MUST do it fast as ABR will not react till it hears bad news from
every node previously connected to such PE.

In every solution we work on we must see a full picture, not just single
pieces of the puzzle.

Thx,
R.

---

From: Aijun Wang <[email-masked]>
Date: Tue, 23 Nov 2021 20:26:34 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 23, 2021, at 20:00, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Dear Aijun,
>  
>> [WAJ] Once there is a link/node failure, upon receiving the updated LSA, the ABR ....
> 
> The entire discussion here is to do it reasonably fast or as fast as possible.
[WAJ] And also as less configuration as possible. We have invested several tools to increase the speed of LSA flooding. 
> That is why such detection must happen quickly via LOS or BFD or CFM etc.... That is way before ABR will receive any LSA/LSP from the adjacent nodes informing it of the failed adj. And in fact all such adj nodes MUST do it fast as ABR will not react till it hears bad news from every node previously connected to such PE.
[WAJ] The reaction time depend on the IGP convergence time after one node is detached from the network. It should be in milliseconds within one area? Right?
> 
> In every solution we work on we must see a full picture, not just single pieces of the puzzle. 
> 
> Thx,
> R.
> 
> 
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 23 Nov 2021 13:41:12 +0100

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, 2021 at 1:26 PM Aijun Wang <[email-masked]>
wrote:

> possible.
> [WAJ] And also as less configuration as possible. We have invested several
> tools to increase the speed of LSA flooding.
>
> That is why such detection must happen quickly via LOS or BFD or CFM
> etc.... That is way before ABR will receive any LSA/LSP from the adjacent
> nodes informing it of the failed adj. And in fact all such adj nodes MUST
> do it fast as ABR will not react till it hears bad news from every node
> previously connected to such PE.
>
> [WAJ] The reaction time depend on the IGP convergence time after one node
> is detached from the network. It should be in milliseconds within one area?
> Right?
>
>

---

From: Christian Hopps <[email-masked]>
Date: Tue, 23 Nov 2021 07:36:47 -0500

Aijun Wang <[email-masked]> writes:

> [WAJ] And also as less configuration as possible. We have invested
> several tools to increase the speed of LSA flooding.

You keep mentioning less configuration or less configuration complexity when people mention BFD. This isn't any sort of justification for not using BFD.

Operators use central management systems now a days, that generate a routers configuration, they aren't hand typing configuration into routers anymore. There's no problem at all with enabling BFD through configuration, and it's use is absolutely not predicated based on how one has to configure it.

Saying BFD is hard to configure is not valid to me. If you are advocating for something that would replace BFD, I hope you have a stronger argument against using BFD.

Thanks,
Chris.
[WG member hat - for previous emails on this thread too -- forgot to include]

>
>     That is why such detection must happen quickly via LOS or BFD or
>     CFM etc.... That is way before ABR will receive any LSA/LSP from
>     the adjacent nodes informing it of the failed adj. And in fact
>     all such adj nodes MUST do it fast as ABR will not react till it
>     hears bad news from every node previously connected to such PE.
>
> [WAJ] The reaction time depend on the IGP convergence time after one
> node is detached from the network. It should be in milliseconds
> within one area? Right?
>
>

---

From: Aijun Wang <[email-masked]>
Date: Tue, 23 Nov 2021 21:15:25 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 23, 2021, at 20:41, Robert Raszuk <[email-masked]> 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 failures occur to the ABR notice it via only IGP procedures. Shouldn’t it be within millisecond within one area? 
> 
> 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, 2021 at 1:26 PM Aijun Wang <[email-masked]> wrote:
>> Hi, Robert:
>> 
>> Aijun Wang
>> China Telecom
>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 23 Nov 2021 14:21:20 +0100

> [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 detect the failure, all works discussed are
pointless. That's why your statement that no BFD is needed is just not
correct.

And if BFD is there as a prerequisite it can equally bring IGP adj down or
BGP session down.

Thx a lot,
R.

---

From: Aijun Wang <[email-masked]>
Date: Tue, 23 Nov 2021 22:56:53 +0800

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 <[email-masked]> wrote:
> 
>

---

From: Aijun Wang <[email-masked]>
Date: Tue, 23 Nov 2021 23:14:23 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 23, 2021, at 21:22, Robert Raszuk <[email-masked]> wrote:
> 
> 
> 
> So unless you can quickly detect the failure, all works discussed are pointless. That's why your statement that no BFD is needed is just not correct. 
> 
> And if BFD is there as a prerequisite it can equally bring IGP adj down or BGP session down. 
> 
[WAJ] we do not care the liveness of OSPF instance. What we want to know is the reachable or unreachable status of some host routes. Such results can be deducted from active LSA updates.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 23 Nov 2021 16:27:46 +0100

> 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 Wang <[email-masked]>
wrote:

> [WAJ] we do not care the liveness of OSPF instance. What we want to know
> is the reachable or unreachable status of some host routes. Such results
> can be deducted from active LSA updates.
>
> Thx a lot,
> R.
>
>
>

---

From: Christian Hopps <[email-masked]>
Date: Tue, 23 Nov 2021 10:25:38 -0500

Aijun Wang <[email-masked]> 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 down detection b/c BFD was too hard to configure. I'm not sure what use case you are talking about above.

Configuring things is not hard, and isn't a reason to invent new technology by itself, is what I'm saying. Operators of large networks generally have central management systems where they enable services and the mgmt system then automatically generates configuration files as complex as they need to be which the system then loads onto the devices.

Thanks,
Chris.
[wg member hat]

>> Operators use central management systems now a days, that generate a routers
>> configuration, they aren't hand typing configuration into routers anymore.
>> There's no problem at all with enabling BFD through configuration, and it's
>> use is absolutely not predicated based on how one has to configure it.
>>

---

From: Tony Li <[email-masked]>
Date: Tue, 23 Nov 2021 08:34:26 -0800

> On Nov 23, 2021, at 6:56 AM, Aijun Wang <[email-masked]> wrote:
> 

Normally, BFD would be configured on each hop individually.

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 23 Nov 2021 08:37:38 -0800

> And if BFD is there as a prerequisite it can equally bring IGP adj down or BGP session down. 

Furthermore, once there is detection, the adjacencies need to update LSAs/LSPs and flood them. Flooding may require many hops to get to the ABR.

If your requirement really is one millisecond, then nothing that we’ve discussed is even the right order of magnitude.

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 23 Nov 2021 08:51:48 -0800

Hi Aijun,

> The received unreachable information does not trigger the SPF calculation. Will they influence intensively the performance of the router?

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 can react outside of a failure scenario.

Having a scale failure on top of a topology failure is a far more painful scenario.

The odds of a mass failure may be low. The fact of the matter is that they still happen. It is our job to ensure that the IGP performs well when it does.  

Increasing the size of the LSDB always affects performance. It slows flooding. Some nodes may not realize that SPF is not needed.  When LSP fragments are rearranged, inferring that SPF is not necessary is non-trivial. Impacting router and network performance is a given.

> [WAJ] Do you have other determined solutions except the PUB/SUB mechanism that does not exist in current IGP?

None of the mechanisms being discussed currently exist.

I have no objections to Robert’s BGP propagation ideas if that’s workable.

This is simply not the IGP’s job and the IGP is not a dump truck.

Tony

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 24 Nov 2021 05:19:34 +0000

WG,

MPLS egress protection framework RFC 8679 provides a mechanism to locally protect the traffic during
PE failures. The concepts can be applied to SRv6 as well. This mechanism is much more efficient and quick because it locally provides fast protection
And switchover to the other PE.
If you compare this  to  the mechanisms being discussed in this thread where the failure information is being
propagated by the egress PE to ABR and then  ABR to the ingress, the failover is going to be much slower.
The egress protection technology does not flood any information outside of the domain and hence does not
affect the IGP scale.

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
Shraddha

Juniper Business Use Only
From: Lsr <[email-masked]> On Behalf Of Tony Li
Sent: Tuesday, November 23, 2021 10:22 PM
To: Aijun Wang <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <[email-masked]>; Christian Hopps <[email-masked]>; lsr <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Tony Przygienda <[email-masked]>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[External Email. Be cautious of content]

Hi Aijun,

Tony

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 24 Nov 2021 13:44:22 +0800

Hi, Shraddha:

If the traffic is steered via the SRv6 policy, the intermediate points
should also be protected. There are already one draft to propose the
solution( please refer to
https://datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protect
ion-05.)  In such situation, if the intermediate points located in different
areas, how then know the liveness of each other if ABR has the summary
address advertised? We will not consider to configure BFD on every
intermediate points.

Best Regards

Aijun Wang

China Telecom

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

WG,

MPLS egress protection framework RFC 8679 provides a mechanism to locally
protect the traffic during

PE failures. The concepts can be applied to SRv6 as well. This mechanism is
much more efficient and quick because it locally provides fast protection

If you compare this  to  the mechanisms being discussed in this thread where
the failure information is being

propagated by the egress PE to ABR and then  ABR to the ingress, the
failover is going to be much slower.

The egress protection technology does not flood any information outside of
the domain and hence does not

affect the IGP scale.

I would be interested to see if people have use cases where egress
protection can’t be applied.

Rgds

Shraddha

From: Lsr <[email-masked] <mailto:[email-masked]> > On Behalf Of
Tony Li
Sent: Tuesday, November 23, 2021 10:22 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>
>; Gyan Mishra <[email-masked] <mailto:[email-masked]> >;
Christian Hopps <[email-masked] <mailto:[email-masked]> >; lsr
<[email-masked] <mailto:[email-masked]> >; Acee Lindem (acee) <[email-masked]
<mailto:[email-masked]> >; Tony Przygienda <[email-masked]
<mailto:[email-masked]> >
Subject: 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 some overlay services(which defeat the user experiences).

Within the real network, there is very rare chance for the massive failure.
And even such thing happen accidently, the information about node liveness
is countable, is there any router can’t process such information?

The received unreachable information does not trigger the SPF calculation.
Will they influence intensively the performance of the router?

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 can react outside of a
failure scenario.

Having a scale failure on top of a topology failure is a far more painful
scenario.

The odds of a mass failure may be low. The fact of the matter is that they
still happen. It is our job to ensure that the IGP performs well when it
does.  

Increasing the size of the LSDB always affects performance. It slows
flooding. Some nodes may not realize that SPF is not needed.  When LSP
fragments are rearranged, inferring that SPF is not necessary is
non-trivial. Impacting router and network performance is a given.

My understanding is that N node failures would result in O(N) bytes added to
the LSDB.  If someone has a way to compress that information to O(1), I (and
Claude Shannon) would be interested.

[WAJ] Do you have other determined solutions except the PUB/SUB mechanism
that does not exist in current IGP?

Tony

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 24 Nov 2021 17:11:33 +0800

Hi, Tony:

Sent: Wednesday, November 24, 2021 12:52 AM

Hi Aijun,

 

[WAJ] What we want to do is the “Positive Summary”+” Specific Negative Information”. This can have both the summary scale advantage and also decrease the convergence time that based on the protocol hello timer.

[WAJ] PUAM does not increase the overall size of the LSDB. It utilizes the existing LSA/TLV/Sub-TLV.

 

[WAJ] BGP is used within the internet, adding the false information within its protocol should be examined more carefully. As we have mentioned several times, the overall goals are not only for BGP usecaes, but also the prevailing Tunnel services.

Tony

---

From: Peter Psenak <[email-masked]>
Date: Wed, 24 Nov 2021 10:23:19 +0100

Shraddha,

On 24/11/2021 06:19, Shraddha Hegde wrote:
> PE failures. The concepts can be applied to SRv6 as well. This mechanism 
> is much more efficient and quick because it locally provides fast protection

it requires SID allocation to be synchronized between multiple egress 
PEs. With per CE SID allocation and multiple next-hops on each PE, the 
number of SIDs become large and keeping them in sync is challenging.

Using anycast SID approach, you are loosing overlay (BGP) ECMP performed 
at the ingress and replace it with underlay (IGP) ECMP towards the 
egress. This may prevent BGP to load balance across multiple PEs or even 
pick one as a preferred one.

So while it is a alternative, it has its drawbacks. We are trying to 
provide a solution which would not pose any extra requirement to SID 
allocation, nor affect BGP in any way.

thanks,
Peter

> *From:* Lsr <[email-masked]> *On Behalf Of *Tony Li
> *Sent:* Tuesday, November 23, 2021 10:22 PM
> *Cc:* Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra 
> *[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, operator should either
>     advertise the host routes across areas(which has scale problem), or
>     lose the fast convergences for some overlay services(which defeat
>     the user experiences)./*
> 
>     */Within the real network, there is very rare chance for the massive
>     failure. And even such thing happen accidently, the information
>     about node liveness is countable, is there any router can’t process
>     such information?/*
> 
>     */The received unreachable information does not trigger the SPF
>     calculation. Will they influence intensively the performance of the
>     router?/*
> 
> 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 can 
> react outside of a failure scenario.
> 
> The odds of a mass failure may be low. The fact of the matter is that 
> they still happen. It is our job to ensure that the IGP performs well 
> when it does.
> 
>     My understanding is that N node failures would result in O(N) bytes
>     added to the LSDB.  If someone has a way to compress that
>     information to O(1), I (and Claude Shannon) would be interested.
> 
>     */[WAJ] Do you have other determined solutions except the PUB/SUB
>     mechanism that does not exist in current IGP?/*
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 24 Nov 2021 11:01:58 +0100

Peter,

> it requires SID allocation to be synchronized between multiple egress PEs.

That is not correct.

The concept Shraddha is describing does not require any synchronization of
either VPN demux label or SIDs.

In an essence you create based on regular service routing propagation a
shadow FIB/LFIB/SID-FIB on the backup PEs. The PLR uses different label/SID
to steer traffic to such shadow FIB/LFIB/SID-FIB.

Yes it costs some resources but other then that it is a viable option.

I was thinking if I should bring it to this thread however it is a
different category of solution hence and pretty well known hence did not
mentioned it.

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 24 Nov 2021 11:12:28 +0100

Aijun,

Nothing Shraddha is describing is about protecting intermediate hops.

She illustrated different solutions for egress protection of PEs.

It has some cost and some deployment limitations but it is an option to
consider.

Thx,
R.

On Wed, Nov 24, 2021 at 6:44 AM Aijun Wang <[email-masked]>
wrote:

> https://datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05.)
> In such situation, if the intermediate points located in different areas,
> how then know the liveness of each other if ABR has the summary address
> advertised? We will not consider to configure BFD on every intermediate
> points.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *Shraddha
> Hegde
> *Sent:* Wednesday, November 24, 2021 1:20 PM
> *To:* Tony Li <[email-masked]>; Aijun Wang <[email-masked]>
> [email-masked]>; Christian Hopps <[email-masked]>; lsr <
> [email-masked]>; Christian Hopps <[email-masked]>; lsr <
> *[WAJ] If we have no such mechanism, operator should either advertise the
> convergences for some overlay services(which defeat the user experiences).*
>
> *Within the real network, there is very rare chance for the massive
> failure. And even such thing happen accidently, the information about node
> liveness is countable, is there any router can**’**t process such
> information?*
>
> *The received unreachable information does not trigger the SPF
> calculation. Will they influence intensively the performance of the router?*
>
>
>
>
>
> 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 can react outside
> of a failure scenario.
>
>
>
> My understanding is that N node failures would result in O(N) bytes added
> to the LSDB.  If someone has a way to compress that information to O(1), I
> (and Claude Shannon) would be interested.
>
> *[WAJ] Do you have other determined solutions except the PUB/SUB mechanism
> that does not exist in current IGP?*
>
>
>
>
>

---

From: Aijun Wang <[email-masked]>
Date: Wed, 24 Nov 2021 18:36:49 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 24, 2021, at 18:12, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Aijun,
> 
> It has some cost and some deployment limitations but it is an option to consider. 

[WAJ] Yes. What I want to express is that there are situations that Egress Protection only is not enough, which is asking by Shraddha.

> 
> Thx,
> R.
> 
>> On Wed, Nov 24, 2021 at 6:44 AM Aijun Wang <[email-masked]> wrote:
>> Hi, Shraddha:
>> 
>>  
>> 
>> If the traffic is steered via the SRv6 policy, the intermediate points should also be protected. There are already one draft to propose the solution( please refer to https://datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05.)  In such situation, if the intermediate points located in different areas, how then know the liveness of each other if ABR has the summary address advertised? We will not consider to configure BFD on every intermediate points.
>> 
>>  
>> 
>>  
>> 
>> Best Regards
>> 
>>  
>> 
>> Aijun Wang
>> 
>> China Telecom
>> 
>>  
>> 
>> From: [email-masked] <[email-masked]> On Behalf Of Shraddha Hegde

---

From: Tony Li <[email-masked]>
Date: Wed, 24 Nov 2021 11:58:40 -0800

Hi Aijun,

> [WAJ] What we want to do is the “Positive Summary”+” Specific Negative Information”. This can have both the summary scale advantage and also decrease the convergence time that based on the protocol…

I do understand that.  Do you understand that I think that that’s a Really Bad Idea?

> [WAJ] PUAM does not increase the overall size of the LSDB. It utilizes the existing LSA/TLV/Sub-TLV.

You’re advertising bits that would not be otherwise advertised.  That increases the size of the LSDB.  Utilizing existing TLVs is irrelevant.

> [WAJ] BGP is used within the internet, adding the false information within its protocol should be examined more carefully. As we have mentioned several times, the overall goals are not only for BGP…

Understood.  BGP is also not a dump truck, but has far better scaling properties, so is less likely to have catastrophic failures due to some negative information.

T

---

From: Aijun Wang <[email-masked]>
Date: Thu, 25 Nov 2021 07:13:53 +0800

Hi, Tony:

Aijun Wang
China Telecom

> On Nov 25, 2021, at 03:59, Tony Li <[email-masked]> wrote:
> 
> 
> 
> Hi Aijun,
> 
[WAJ] No. As we have discussed on the list, there is no other better solution to solve the problem. Actually, when ABR does the summary work, it may overstate the reachable addresses. 
When the host is within the summary range but is not used, it’s OK.  But when the in-service host become unreachable and ABR knows this, it should give the other nodes the accurate information to assist them to switch to other services/backup points.

> You’re advertising bits that would not be otherwise advertised.  That increases the size of the LSDB.  Utilizing existing TLVs is irrelevant.

[WAJ] No. OSPF/ISIS has been designed to be extensible to accommodate the newly necessary information. If we stick to your point, the fixed format LSA is sufficient.

> Understood.  BGP is also not a dump truck, but has far better scaling properties, so is less likely to have catastrophic failures due to some negative information.

[WAJ] It is the IGP advertises the inaccurate information, why let BGP clear up? Won’t you estimate the IDR experts will resist?

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 25 Nov 2021 00:35:06 +0100

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 who configure leaking for a subset of area routes.

When you configure a summary half of the addresses may be not even
configured. ABRs do nothing about it.

#2

> As we have discussed on the list, there is no other better solution to
solve the problem.

Of course there are. Bunch of them in fact. Trivial to demonstrate too in
shipping code.

But neither lack nor presence of alternative solutions is a valid
justification to any protocol extension.

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

BGP propagates service routes and if service is not up those routes should
be removed asap. I think this is clear to anyone.

In addition BGP can also and with much better scaling properties to a link
state protocol withdraw next hops for such service routes which I am sure
will be much faster end to end then IGP. After all please consider that it
is also BGP which needs to trigger best path on all remote PEs to select
alternative path.

Last please tell me one person in IDR who will oppose to make BGP withdraws
go faster (if needed as personally if your configuration is rigth I believe
it is already fine - of course provided that you are using decent BGP
implementation all the way).

Kind regards,
Robert

On Thu, Nov 25, 2021 at 12:14 AM Aijun Wang <[email-masked]>
wrote:

> *[WAJ] What we want to do is the “Positive Summary”+” Specific Negative
> Information”. This can have both the summary scale advantage and also
> decrease the convergence time that based on the protocol hello timer.*
>
>
>
> [WAJ] No. As we have discussed on the list, there is no other better
> solution to solve the problem. Actually, when ABR does the summary work, it
> may overstate the reachable addresses.
> When the host is within the summary range but is not used, it’s OK.  But
> when the in-service host become unreachable and ABR knows this, it should
> give the other nodes the accurate information to assist them to switch to
> other services/backup points.
>
>
>
>
> *[WAJ] PUAM does not increase the overall size of the LSDB. It utilizes
> the existing LSA/TLV/Sub-TLV.*
>
>
>
> You’re advertising bits that would not be otherwise advertised.  That
> increases the size of the LSDB.  Utilizing existing TLVs is irrelevant.
>
>
> [WAJ] No. OSPF/ISIS has been designed to be extensible to accommodate the
> newly necessary information. If we stick to your point, the fixed format
> LSA is sufficient.
>
>
>
> *[WAJ] BGP is used within the internet, adding the false information
> within its protocol should be examined more carefully. As we have mentioned
> several times, the overall goals are not only for BGP usecaes, but also the
> prevailing Tunnel services.*
>
>
>
> Understood.  BGP is also not a dump truck, but has far better scaling
> properties, so is less likely to have catastrophic failures due to some
> negative information.
>
>
> [WAJ] It is the IGP advertises the inaccurate information, why let BGP
> clear up? Won’t you estimate the IDR experts will resist?
>
>
> T
>
>

---

From: Aijun Wang <[email-masked]>
Date: Thu, 25 Nov 2021 11:06:53 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 25, 2021, at 07:35, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hi Aijun,
> 
> 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. 
> 
> When you configure a summary half of the addresses may be not even configured. ABRs do nothing about it. 

[WAJ] OK. The operator let the ABR do something. If we follow this logic, I think these configuration act as the ACL of the prefixes. Won’t some thing likes the following let the work of operator easier?
#Deny one
#Permit All

And, we also can think further under this POV: the IGP itself cannot meet all the scale requirements. The network design, the operator intervention are all key factors for this aim. Then why you and Tony assert that advertise the necessary negative information will significantly degrade the scalability of IGP? I think they are similar with the positive information.

> 
> 
> #2 
> 
> > As we have discussed on the list, there is no other better solution to solve the problem.
> 
> Of course there are. Bunch of them in fact. Trivial to demonstrate too in shipping code. 

[WAJ] Please illustrate one of them that can solve the problems that we mentioned simultaneously. For example, the liveness of BGP PEER, the liveness of SRv6 intermediate points .

> 
> But neither lack nor presence of alternative solutions is a valid justification to any protocol extension. 

[WAJ] Then, what is the valid justification?

> There is nothing inaccurate in the IGP advertisement. IGP does precisely what the operator configured it to do. 

[WAJ] It lack some more precise control mechanisms. Currently it can only allow all, or advertise all. 
> 
> BGP propagates service routes and if service is not up those routes should be removed asap. I think this is clear to anyone. 

[WAJ] First, the reachable underlay information is not advertised via BGP. 
But we can still think further along your proposal: If the BGP advertise this host route is unreachable, but the IGP still think it has the knowledge to reach it, will this puzzle the router?

> 
> In addition BGP can also and with much better scaling properties to a link state protocol withdraw next hops for such service routes which I am sure will be much faster end to end then IGP. After all please consider that it is also BGP which needs to trigger best path on all remote PEs to select alternative path. 

[WAJ] The above action is for the overlay prefixes, not for underlying prefixes.

> 
> Last please tell me one person in IDR who will oppose to make BGP withdraws go faster (if needed as personally if your configuration is rigth I believe it is already fine - of course provided that you are using decent BGP implementation all the way). 

[WAJ] BGP should be responsible for advertising and revoking of the prefixes that it advertised. It should not interfere with the information that other protocol advertised.
> 
> Kind regards,
> Robert
> 
> 
> 
> 
> 
> 
>> On Thu, Nov 25, 2021 at 12:14 AM Aijun Wang <[email-masked]> wrote:
>> Hi, Tony:
>> 
>> Aijun Wang
>> China Telecom
>>

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 25 Nov 2021 04:10:43 +0000

Aijun,

There are multiple possible solutions for the SR-Policy mid-point failure scenario

  1.  Use anycast SID as mid-points for redundancy
  2.  Mid-point failure local protection by looking up next sid (This is probably the one you pointed out)
  3.  E2E S-BFD for SR-Policy  path liveness detection

If you punch a hole in the summary, the other area nodes come to know about the mid-point failure
and remove the failed node reachability. It is not clear how that is solving the SR-Policy liveness problem.

Rgds
Shraddha

Juniper Business Use Only
From: Aijun Wang <[email-masked]>
Sent: Wednesday, November 24, 2021 11:14 AM
To: Shraddha Hegde <[email-masked]>; 'Tony Li' <[email-masked]>
Cc: 'Les Ginsberg (ginsberg)' <[email-masked]>; 'Gyan Mishra' <[email-masked]>; 'Christian Hopps' <[email-masked]>; 'lsr' <[email-masked]>; 'Acee Lindem (acee)' <[email-masked]>; 'Tony Przygienda' <[email-masked]>
Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi, Shraddha:

If the traffic is steered via the SRv6 policy, the intermediate points should also be protected. There are already one draft to propose the solution( please refer to https://datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05__;!!NEt6yMaO-gk!SSAVRO90Q62ieX5DTTgZBW4FKiC_YHXU9biL8pK-jEOUv7jmUHGUaHAt89kXBaSb$>.)  In such situation, if the intermediate points located in different areas, how then know the liveness of each other if ABR has the summary address advertised? We will not consider to configure BFD on every intermediate points.

Best Regards

Aijun Wang
China Telecom

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

WG,

Rgds
Shraddha

Juniper Business Use Only
From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Tony Li
Sent: Tuesday, November 23, 2021 10:22 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi Aijun,

Tony

---

From: Huzhibo <[email-masked]>
Date: Thu, 25 Nov 2021 09:30:08 +0000

Hi Shraddha:
     MPLS egress protection is a FRR mechanism, PUA is a hard convergence mechanism. I don't think there's a conflict between the two solution.
Also, as far as I know, MPLS egress protection has not been deployed on a large scale.

Thanks

Zhibo

From: Lsr [mailto:[email-masked]] On Behalf Of Shraddha Hegde

WG,

Rgds
Shraddha

Hi Aijun,

Tony

---

From: Huzhibo <[email-masked]>
Date: Thu, 25 Nov 2021 09:34:28 +0000

Hi, Shraddha:

If you punch a hole in the summary, the other area nodes come to know about the mid-point failure.---> Yes, you're right. Once any node knows about the mid-point failure，It can execution local protection by looking up next sid to fix SRv6 Policy reachability.

Thanks

Zhibo

From: Lsr [mailto:[email-masked]] On Behalf Of Shraddha Hegde
Sent: Thursday, November 25, 2021 12:11 PM
To: Aijun Wang <[email-masked]>; 'Tony Li' <[email-masked]>
Cc: 'Les Ginsberg (ginsberg)' <[email-masked]>; 'Gyan Mishra' <[email-masked]>; 'Christian Hopps' <[email-masked]>; 'lsr' <[email-masked]>; 'Acee Lindem (acee)' <[email-masked]>; 'Tony Przygienda' <[email-masked]>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Aijun,

Rgds
Shraddha

Juniper Business Use Only
From: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 24, 2021 11:14 AM
To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; 'Tony Li' <[email-masked]<mailto:[email-masked]>>
Cc: 'Les Ginsberg (ginsberg)' <[email-masked]<mailto:[email-masked]>>; 'Gyan Mishra' <[email-masked]<mailto:[email-masked]>>; 'Christian Hopps' <[email-masked]<mailto:[email-masked]>>; 'lsr' <[email-masked]<mailto:[email-masked]>>; 'Acee Lindem (acee)' <[email-masked]<mailto:[email-masked]>>; 'Tony Przygienda' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi, Shraddha:

Best Regards

Aijun Wang
China Telecom

WG,

Rgds
Shraddha

Hi Aijun,

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 25 Nov 2021 11:38:59 +0100

Hi Aijun,

> allow all, or advertise all.

Yes - and this is a good problem to be fixed. To me this is day one spec
bug.

Leaking should not be sender, but receiver driven. In fact one could also
argue that leaking does not need to be flooded, but send by IGP as unicast.
Maybe using reflection for scalability.

I think no one here will object to fixing it. However if you want to break
what is working fine (even if only during rear and stressful moments to the
IGP) that is not the right approach.

I am talking about building hierarchy.

You have:

#3 - NLRI: Service Routing with PE_NH (BGP)
#2 - NLRI: PE_NH advertisement with ABR as NH (BGP)
#1 - ABR IGP underlay (with summaries) (IGP)

Thinking more on this #2 perhaps can use BGP-LS (maybe first decent use
case for this SAFI :)

Thx,
R.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 25 Nov 2021 11:29:45 -0500

Hi Shraddha

The  PUA draft is detecting the BGP  NH liveliness based on the PUA
protection mechanism for immediate  control plane convergence immediately
on alternative next - next hop, analogous to FRR link and node protection
but without the complexity.

I agree the egress protection RFC 8679  mechanism using RSVP-TE Egress
protection extension RFC 8400 can provide fast  FRR link and mode
protection mechanism for global repair but at a operational cost of RSVP-TE
FRR protection schemes which may or may not be deployed by the operator.

The PUA and event notification drafts provide a simple IGP extension based
mechanism to provide the same and can be utilized in scenarios where
RSVP-TE may not be deployed or desirable.  I agree in most cases  large
aggregation domains converged  transport networks with MPLS-TP transport
core that RSVP-TE is deployed.

PUA provides next hop  liveliness detection and protection that can be
applied to SRv6 SR-TE policy as well, similar to what S-BFD SR-TE policy
liveliness, this PUA draft is providing similar via next hop liveliness in
protecting the egress PE SRv6 SR-TE policy.

Kind Regards

Gyan

On Wed, Nov 24, 2021 at 11:10 PM Shraddha Hegde <[email-masked]>
wrote:

> *From:* Aijun Wang <[email-masked]>
> *Sent:* Wednesday, November 24, 2021 11:14 AM
> *To:* Shraddha Hegde <[email-masked]>; 'Tony Li' <[email-masked]>
> *Cc:* 'Les Ginsberg (ginsberg)' <[email-masked]>; 'Gyan Mishra' <
> [email-masked]>; 'Christian Hopps' <[email-masked]>; 'lsr' <
> [email-masked]>; 'Acee Lindem (acee)' <[email-masked]>; 'Tony Przygienda' <
> [email-masked]>
> *Subject:* RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
> LSR Meeting Minutes
>
>
>
> https://datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05__;!!NEt6yMaO-gk!SSAVRO90Q62ieX5DTTgZBW4FKiC_YHXU9biL8pK-jEOUv7jmUHGUaHAt89kXBaSb$>
> .)  In such situation, if the intermediate points located in different
> liveness is countable, is there any router can’t process such information?*
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 25 Nov 2021 17:33:32 +0100

RFC 8679 does not require RSVP-TE to work.

Best,
R.

On Thu, Nov 25, 2021 at 5:30 PM Gyan Mishra <[email-masked]> wrote:

>> they still happen. It is our job to ensure that the IGP performs well when
>> it does.
>>
>>
>>
>> *[WAJ] Do you have other determined solutions except the PUB/SUB
>> mechanism that does not exist in current IGP?*
>>
>>
>>
>>
>>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 25 Nov 2021 12:12:26 -0500

Understood as this egress protection framework applies to all current and
future protocols, however if you are using RSVP-TE which in most cases you
are today with converged transport aggregation domain then you would use
the RFC 8400 extension.

Happy Thanksgiving!🦃🍽

Gyan

On Thu, Nov 25, 2021 at 11:33 AM Robert Raszuk <[email-masked]> wrote:

>> The PUA and event notification drafts provide a simple IGP extension
>> based mechanism to provide the same and can be utilized in scenarios where
>>> [email-masked]>; 'Acee Lindem (acee)' <[email-masked]>; 'Tony Przygienda'
>>> <[email-masked]>
>>> 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
>>> added to the LSDB.  If someone has a way to compress that information to
>>> O(1), I (and Claude Shannon) would be interested.
>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 25 Nov 2021 18:25:08 +0100

Dear LSR WG,

I wanted to visualize the scenario we are so deeply discussing here.
Specifically BGP vs IGP flooding as well as applicability of RFC8679.

Below are three options comparing what it takes to distribute bad news in
BGP vs IGP. Keep in mind that only PE2 on the illustration is interested in
this bad news.

All in respect to L3VPN Option C as example of the service.

*Option 1* - Classic/ Today's design. If you simply enable BFD on IBGP
between PE1 and RR I bet we would not even be discussing anything as things
will just work well as is today.

*Option 2 -* BGP recursion as discussed earlier to speed up NH down
propagation vs service route withdraw.

Again very easy to accomplish today modulo your BGP implementation. RR1 to
PE1 can be two BGP session - one with BFD one without to easily separate
the sequence of BGP events.

*Option 3* - BGP-LS from ABRs

BGP-LS essentially is carrying those PUA/PULSES to those who need it.

In all cases RFC8679 can still protect against PE1 failure at local PLR
directing traffic to backup PE1' (not on the picture but we assume it is
there otherwise it is all moot).

And in fact local protection is the only one which can assure minimum
service disruption time.

For PUA/PULSE to get triggered by ABR all PE1 IGP neighbours must report
PE1 to be out - hence we are already limited to the local area detection of
PE1 down and local flooding.

Now imagine someone will not like to use BFD+BGP. Well that means that IBGP
will time out in 180 sec. That also means that whatever PUA/PULSE is there
it MUST "last" min 200 sec on the remote PEs.

(Also attaching pdf with the above illustration in case jpg-s are poor).

Many thx,
Robert

---

From: Peter Psenak <[email-masked]>
Date: Thu, 25 Nov 2021 18:45:34 +0100

Robert,

On 25/11/2021 18:25, Robert Raszuk wrote:
> Below are three options comparing what it takes to distribute bad news 
> in BGP vs IGP. Keep in mind that only PE2 on the illustration is 
> interested in this bad news.
> 
> between PE1 and RR I bet we would not even be discussing anything as 
> things will just work well as is today.

I don't understand how BFD between PE1 and RR is going to address the 
problem in hand. If PE1 goes down, RR will have to withdraw all 
individual BGP prefixes advertised by PE1. Could be global internet 
routes, internet in VRF is not uncommon either. With BGP per prefix 
withdrawal the convergence is slow by definition. We want BGP PIC like 
behavior and that is not what you have described above.

> image.png

same as above.

> 
> image.png
> 
> Again very easy to accomplish today modulo your BGP implementation. RR1 
> to PE1 can be two BGP session - one with BFD one without to easily 
> separate the sequence of BGP events.
> 

BGP can carry pulses, but as I mentioned several times there are SP 
networks that do not run MPLS and use other tunneling mechanisms. They 
would not appreciate BGP only solution.

Having a solution in both IGP and BGP and let user decide which one he 
wants to use seems a better approach to me.

thanks,
Peter

> image.png
> PE1 to be out - hence we are already limited to the local area detection 
> of PE1 down and local flooding.
> 
> Now imagine someone will not like to use BFD+BGP. Well that means that 
> IBGP will time out in 180 sec. That also means that whatever PUA/PULSE 
> is there it MUST "last" min 200 sec on the remote PEs.
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 25 Nov 2021 20:21:52 +0100

Hi Peter,

First BGP MP_UNREACH propagation via RRs is really fast.

Please observe that if your BGP implementation is smart you do not need to
withdraw prefix by prefix in any application which uses VRFs. You can
withdraw RD/64s only when you detect that the PE went down. Furthermore as
you know with auto RD allocation RD format is usually BGP_ROUTER-ID:XXXX so
to withdraw all service routes once the PE went down you could just send
RD/32 single NLRI !

There is a lot of options.

In respect to option 2 - you do not need to speed up service BGP withdraws
at all. You are using indirection and you are withdrawing recursive next
hop irrespective on how many service routes are present including Internet.
So it is not "same as above" at all. I am really not sure what is so
difficult in this scenario that folks just do not get it.

Thx a lot,
Robert

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 26 Nov 2021 04:49:03 +0000

Huzhibo,

Local protection is always executed on the node where failure occurs (for link protection) and the previous node
(for node failure). You don’t really require the failure event to propagate to another domain to trigger local protection.

Rgds
Shraddha

Juniper Business Use Only
From: Huzhibo <huzhibo=[email-masked]>
Sent: Thursday, November 25, 2021 3:04 PM
To: Shraddha Hegde <[email-masked]>; Aijun Wang <[email-masked]>; 'Tony Li' <[email-masked]>
Cc: 'Les Ginsberg (ginsberg)' <[email-masked]>; 'Gyan Mishra' <[email-masked]>; 'Christian Hopps' <[email-masked]>; 'lsr' <[email-masked]>; 'Acee Lindem (acee)' <[email-masked]>; 'Tony Przygienda' <[email-masked]>
Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi, Shraddha:

Thanks

Zhibo

To: Aijun Wang <[email-masked]<mailto:[email-masked]>>; 'Tony Li' <[email-masked]<mailto:[email-masked]>>

Aijun,

Rgds
Shraddha

Hi, Shraddha:

Best Regards

Aijun Wang
China Telecom

WG,

Rgds
Shraddha

Hi Aijun,

Tony

---

From: Huzhibo <[email-masked]>
Date: Fri, 26 Nov 2021 08:09:24 +0000

Hi, Shraddha:

     If there are a large number of CE-to-PE mix-homing scenarios, specifying the master/backup relationship of egress protection is complex, which greatly increases deployment complexity. Therefore, local protection is not applicable to all scenarios. In addition, local protection also generates suboptimal paths. Therefore, even if local protection is deployed, speeding up ingress PE convergence is useful.

Regards

Zhibo

From: Lsr [mailto:[email-masked]] On Behalf Of Shraddha Hegde
Sent: Friday, November 26, 2021 12:49 PM
To: Huzhibo <huzhibo=[email-masked]>; Aijun Wang <[email-masked]>; 'Tony Li' <[email-masked]>
Cc: 'Les Ginsberg (ginsberg)' <[email-masked]>; 'Gyan Mishra' <[email-masked]>; 'Christian Hopps' <[email-masked]>; 'lsr' <[email-masked]>; 'Acee Lindem (acee)' <[email-masked]>; 'Tony Przygienda' <[email-masked]>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Huzhibo,

Rgds
Shraddha

Juniper Business Use Only
From: Huzhibo <huzhibo=[email-masked]<mailto:huzhibo=[email-masked]>>
Sent: Thursday, November 25, 2021 3:04 PM
To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; 'Tony Li' <[email-masked]<mailto:[email-masked]>>
Cc: 'Les Ginsberg (ginsberg)' <[email-masked]<mailto:[email-masked]>>; 'Gyan Mishra' <[email-masked]<mailto:[email-masked]>>; 'Christian Hopps' <[email-masked]<mailto:[email-masked]>>; 'lsr' <[email-masked]<mailto:[email-masked]>>; 'Acee Lindem (acee)' <[email-masked]<mailto:[email-masked]>>; 'Tony Przygienda' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi, Shraddha:

Thanks

Zhibo

Aijun,

Rgds
Shraddha

Hi, Shraddha:

Best Regards

Aijun Wang
China Telecom

WG,

Rgds
Shraddha

Hi Aijun,

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Nov 2021 09:59:43 +0100

Huzhibo,

> specifying the master/backup relationship of egress protection is complex

Sure is - but there is absolutely no requirement to do it. BGP already
carries all information needed to instantiate such protection. It is
therefore all dynamic and automated.

As said cost is extra LFIB space on the PEs acting as a backup. With per
VRF or per CE label allocation that is not big deal. With per prefix label
allocation yes that can be a resource constraint to consider.

So if we are discussing drawbacks of any proposal let's just use correct
arguments :)

Cheers,
R.

On Fri, Nov 26, 2021 at 9:09 AM Huzhibo <huzhibo=[email-masked]>
wrote:

> Hi, Shraddha:
>
>
>
>      If there are a large number of CE-to-PE mix-homing scenarios,
> specifying the master/backup relationship of egress protection is complex,
> which greatly increases deployment complexity. Therefore, local protection
> is not applicable to all scenarios. In addition, local protection also
> generates suboptimal paths. Therefore, even if local protection is
> deployed, speeding up ingress PE convergence is useful.
>
>
>
> Regards
>
>
>
> Zhibo
>
>
>
> *From:* Lsr [mailto:[email-masked]] *On Behalf Of *Shraddha Hegde
> *Sent:* Friday, November 26, 2021 12:49 PM
> *To:* Huzhibo <huzhibo=[email-masked]>; Aijun Wang <
> [email-masked]>; 'Tony Li' <[email-masked]>
> (for node failure). You don’t really require the failure event to
> propagate to another domain to trigger local protection.
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> *From:* Huzhibo <huzhibo=[email-masked]>
> *Sent:* Thursday, November 25, 2021 3:04 PM
> *To:* Shraddha Hegde <[email-masked]>; Aijun Wang <
> [email-masked]>; 'Tony Li' <[email-masked]>
> If you punch a hole in the summary, the other area nodes come to know
> about the mid-point failure.---> Yes, you're right. Once any node knows
> about the mid-point failure，It can execution local protection by looking
> up next sid to fix SRv6 Policy reachability.
>
>
>
> Thanks
>
>
>
> Zhibo
>
>
>
>
>
> *From:* Lsr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Shraddha Hegde
> *Sent:* Thursday, November 25, 2021 12:11 PM
> *To:* Aijun Wang <[email-masked]>; 'Tony Li' <[email-masked]>

---

From: Peter Psenak <[email-masked]>
Date: Fri, 26 Nov 2021 10:30:56 +0100

Hi Robert,

On 25/11/2021 20:21, Robert Raszuk wrote:
> Please observe that if your BGP implementation is smart you do not need 
> to withdraw prefix by prefix in any application which uses VRFs. You can 
> withdraw RD/64s only when you detect that the PE went down. Furthermore 
> as you know with auto RD allocation RD format is usually 
> BGP_ROUTER-ID:XXXX so to withdraw all service routes once the PE went 
> down you could just send RD/32 single NLRI !
> 

lot of assumptions about the implementation and deployment. Also for 
default table I assume RD does not help.

> 
> In respect to option 2 - you do not need to speed up service BGP 
> withdraws at all. You are using indirection and you are withdrawing 
> recursive next hop irrespective on how many service routes are present 
> including Internet. So it is not "same as above" at all. I am really not 
> sure what is so difficult in this scenario that folks just do not get it.

again, if you use option 2. There are way too many networks without it.

In summary, we need something that works independent of the BGP design 
and also works outside of BGP.

thanks,
Peter
> 
> Thx a lot,
> Robert
> 
> 
> On Thu, Nov 25, 2021 at 6:45 PM Peter Psenak <[email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Nov 2021 15:06:51 +0100

Peter,

> again, if you use option 2. There are way too many networks without it.

There is even more networks without PUA/PULSE today. Should that be a
factor ?

> and also works outside of BGP.

Really ? Is that the requirement that the solution provided MUST not use
BGP ?

Please kindly describe a full practical deployment scenario where PULSE
helps when BGP is not used at all in the network for distributing service
reachability.

OSPF and ISIS are *link state* protocols. You are asking to extend them to
carry *node state* now. Specifically just to carry the UP -> DOWN
transitions of a node state and moreover in an ephemeral fashion.

Thx,
R,

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 26 Nov 2021 10:26:53 -0500

Robert

Just want to chime in on the primary context of PUA/Pulse design is to
provide protection of the underlay egress PE next hops host routes that are
summarized to provide an egress PE protection mechanism similar to RFC 8679
but focused on IGP to track the component prefixes of the summary route as
the protection mechanism.

So the use case for PUA/Pulse is honed in on being able to eliminate domain
wide flooding and make summarization viable and still have FRR style fast
protection of next hops so that the overlay service routes have minimal to
none disruption.  The problem with the summarization is the component
prefixes need to be tracked to provide that feedback mechanism that the
component is dead so the control plane can converge instantly just as it’s
able to converge instantly with domain wide flooding of LPM routes which
can take advantage of existing local protection mechanisms LFA/RLFA/TI-LFA.

Kind Regards

Gyan

On Fri, Nov 26, 2021 at 9:07 AM Robert Raszuk <[email-masked]> wrote:

> OSPF and ISIS are *link state* protocols. You are asking to extend them
> to carry *node state* now. Specifically just to carry the UP -> DOWN
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Peter Psenak <[email-masked]>
Date: Fri, 26 Nov 2021 16:38:36 +0100

Robert,

> There is even more networks without PUA/PULSE today. Should that be a 

the solution should not depend on any particular deployment of the 
overlay protocol.

> Really ? Is that the requirement that the solution provided MUST not use 

for me the solution ideally should work for with any overlay protocol.

> helps when BGP is not used at all in the network for distributing 
> service reachability.

I have explained that several times to you. There are SP networks 
running the services on top of p2p IP sec tunnels for example, with no BGP.

> transitions of a node state and moreover in an ephemeral fashion.

no, I'm only talking about the prefix unrechability. Something that link 
state protocols advertise happily today.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Nov 2021 17:18:00 +0100

Peter,

Technically I see no justification to run any service within your own
domian over IPSec.

In those cases simple IP encapsulation works fine.

So let's zoom on this scenario ... Your PEs communicate over IP
encapsulation which does not require any connection establishment.

They start to exchange packets using  summary routes.

PE1 goes down and PULSE reaches remote PE2 - then what exactly is to happen
there ?

In RIB you still have valid summary route. You do not have in RIB /32 for
remote PE1. PULSE comes and what ?

If you run BGP it could trigger next hop invalidation and best path re-run.
But there is no BGP as you say.

Depending on how you implement encapsulation you could remove such encap
rewrite from FIB, but for how long ? And what will tell you that the remote
PE is up again ?

All in all for PULSE to directly affect the data plane I think lot's of new
code needs to be written, tested and deployed. Leave alone aspect of
network wide flooding of those PULSEs.

Many thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 26 Nov 2021 17:36:44 +0100

Robert,

> Technically I see no justification to run any service within your own 

tell people that are doing so, not me.

> encapsulation which does not require any connection establishment.

it's tunneling and there can be L3 or L2 client traffic being sent over 
these tunnels. Having a fast tunnel end-pointy down notification 
(without the need to run multi-hop BFD) helps the overlay network 
convergence. Same as with BGP.

Just accept the fact that other overlay protocols exists out there and 
are actively being used. If you are not willing to accept tt, no point 
discussing further.

thanks,
Peter

> PE1 goes down and PULSE reaches remote PE2 - then what exactly is to 
> happen there ?
> 
> In RIB you still have valid summary route. You do not have in RIB /32 
> for remote PE1. PULSE comes and what ?
> 
> If you run BGP it could trigger next hop invalidation and best path 
> re-run. But there is no BGP as you say.
> 
> rewrite from FIB, but for how long ? And what will tell you that the 
> remote PE is up again ?
> 
> All in all for PULSE to directly affect the data plane I think lot's of 
> new code needs to be written, tested and deployed. Leave alone aspect of 
> On Fri, Nov 26, 2021 at 4:38 PM Peter Psenak <[email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Nov 2021 17:47:12 +0100

Peter,

As I told you many times I do see a need to signal summary member liveness.
Otherwise I would not be spending time here.

But what I am trying to discuss is the proposed mechanism of such
signalling and possible alternatives.

I suggested to you to do selective leaking. I do not recall seeing any
answer from you on that. Les acked you did not. Maybe you want to first
discuss internally which is fine.

So back to the topic.

How about you just leak those PEs which went down with a flag "DOWN" and
when it comes up you clear that flag. That way the IGP carries the liveness
in exactly the same way as today via leaking everything.

However you at least is going to be leaking subset not everything. And this
is not going to be ephemeral but permanent. Maybe when PE is back stable
after 12h or any other long timer you stop leaking.

See it is very hard to support a proposal when you - someone who wrote a
prototype for it - can not answer basic question on how will it work with
just encapsulation. Yet you use p2p tunnel as example on how this is
useful. Sure tunnel will go down and will not come up till remote PE is
back in business. But with just encap (say mGRE) this is no longer possible
as the interface there is p2mp so it can not go down if even one remote PE
is still up.

Thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 26 Nov 2021 18:07:36 +0100

Robert,

On 26/11/2021 17:47, Robert Raszuk wrote:
> Peter,
> 
> As I told you many times I do see a need to signal summary member 
> liveness. Otherwise I would not be spending time here.
> 
> when it comes up you clear that flag. That way the IGP carries the 
> liveness in exactly the same way as today via leaking everything.

that's similar what the PUA draft proposes. The disadvantages is that 
you need to flood twice:

  a) prefix DOWN itself
  b) clean the DOWN prefixes as you can not keep them around forever.

and you add to the existing LSDB, which goes against the summarization 
itself.

Pulse cleans up itself without any additional flooding, that's the whole 
idea of it. It also is not part of the LSDB that IGP uses for 
computation, so it does not affect the scale.

> 
> However you at least is going to be leaking subset not everything. And 
> this is not going to be ephemeral but permanent. Maybe when PE is back 
> stable after 12h or any other long timer you stop leaking.

see above why the pulse.

thanks,
Peter

> prototype for it - can not answer basic question on how will it work 
> with just encapsulation. Yet you use p2p tunnel as example on how this 
> is useful. Sure tunnel will go down and will not come up till remote PE 
> is back in business. But with just encap (say mGRE) this is no longer 
> possible as the interface there is p2mp so it can not go down if even 
> one remote PE is still up.
> 
> Thx,
> R.
> 
> 
> 
> 
> On Fri, Nov 26, 2021 at 5:36 PM Peter Psenak <[email-masked] 
>     <mailto:[email-masked]>
>      >      > Peter,
>      >      >     again, if you use option 2. There are way too many
>     networks
>      >     without it.
>      >      >
>      >      >
>      >      > There is even more networks without PUA/PULSE today.
>     Should that
>      >     be a
>      >      > factor ?
>      >
>      >      >     In summary, we need something that works independent
>     of the
>      >     BGP design
>      >      >     and also works outside of BGP.
>      >      >
>      >      >
>      >      > Really ? Is that the requirement that the solution
>     provided MUST
>      >     not use
>      >      > BGP ?
>      >
>      >      > Please kindly describe a full practical deployment
>     scenario where
>      >     PULSE
>      >      > helps when BGP is not used at all in the network for
>     distributing
>      >      > service reachability.
>      >
>      >     running the services on top of p2p IP sec tunnels for
>     example, with
>      >     no BGP.
>      >
>      >      >
>      >      > OSPF and ISIS are *link state* protocols. You are asking to
>      >     extend them
>      >      > to carry *node state* now. Specifically just to carry the
>     UP -> DOWN
>      >      > transitions of a node state and moreover in an ephemeral
>     fashion.
>      >
>      >     no, I'm only talking about the prefix unrechability.
>     Something that
>      >     link
>      >      > R,

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Nov 2021 19:20:35 +0100

> idea of it.

That's the most scary and not well understood part of it. Ghosts ! Appears
and magically disappears.

> It also is not part of the LSDB that IGP uses for

Well unless you are going to send it in completely separate LSAs/LSPs what
you state above may not be really true.

see above why the pulse.

I asked a very simple question. In your scenario - no BGP - there is* p2mp**
tunnel* - How does PULSE work on the PEs receiving it ?

It's ok to say - It does not work. But I would like to see an answer to
this.

Thx,
R.

---

From: Aijun Wang <[email-masked]>
Date: Sat, 27 Nov 2021 08:12:52 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 27, 2021, at 00:47, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Peter,
> 
> As I told you many times I do see a need to signal summary member liveness. Otherwise I would not be spending time here. 
[WAJ] Welcome to join us.
> 
> But what I am trying to discuss is the proposed mechanism of such signalling and possible alternatives. 
[WAJ] As Peter and I state several times, we want to find the generic solution for different scenarios. BGP exist or not.
> 
> I suggested to you to do selective leaking. I do not recall seeing any answer from you on that. Les acked you did not. Maybe you want to first discuss internally which is fine. 

[WAJ] For BGP scenarios, there maybe only subset of nodes interested in such messages. But for other scenarios, such as SRv6 policy based TE, the node within the IGP all interested such messages. Flooding them within the IGP is the efficient way. 
Selective leaking requires the additional configuration which we want to avoid from the beginning.

> 
> So back to the topic. 
> 
> How about you just leak those PEs which went down with a flag "DOWN" and when it comes up you clear that flag. That way the IGP carries the liveness in exactly the same way as today via leaking everything. 

> 
> However you at least is going to be leaking subset not everything. And this is not going to be ephemeral but permanent. Maybe when PE is back stable after 12h or any other long timer you stop leaking. 
[WAJ] Theoretically, the “DOWN” information should only be sent once to trigger the control plane action. For reliability, they can be sent several times(operator can configure), doesn’t need last until the node is backup again.
> 
> See it is very hard to support a proposal when you - someone who wrote a prototype for it - can not answer basic question on how will it work with just encapsulation. Yet you use p2p tunnel as example on how this is useful. Sure tunnel will go down and will not come up till remote PE is back in business.

> But with just encap (say mGRE) this is no longer possible as the interface there is p2mp so it can not go down if even one remote PE is still up. 
[WAJ] P2MP tunnel should take different action. Only the failure endpoint will not be used.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 27 Nov 2021 01:25:42 +0100

Aijun,

[WAJ] As Peter and I state several times, we want to find the generic
> solution for different scenarios. BGP exist or not.
>

Maybe you missed my point. I am not aware of any production router stack
which would not support BGP. That is irrespective of if BGP is used for
service distribution in any given network or not.

Honestly I know deployments (hint MSDC) which do not use IGP, but I am not
aware of any network which is not using BGP.

But I am open to evaluate other protocols to distribute requested
information. I am not stuck on BGP. As mentioned a lot of pub-sub message
bus solutions fit that bill.

Selective leaking requires the additional configuration which we want to
> avoid from the beginning.
>

No one (well at least not me) would recommend any form of selective leaking
by hand cfg. It goes without saying that subscription to selective leaking
MUST be automated.

 For reliability, they can be sent several times(operator can configure),
> doesn’t need last until the node is backup again.
>

That is interesting ... first time I hear that. And what if node which went
down was removed from the network forever ? You will need to go to each ABR
and manually stop PUAs/PULSES ?

[WAJ] P2MP tunnel should take different action. Only the failure endpoint
> will not be used.

Easy to say ... Sure you can remove the adj from FIB. But for how long -
that is the question - very important when we are talking about any
ephemeral form of signalling.

Kind regards,
Robert

---

From: Aijun Wang <[email-masked]>
Date: Sat, 27 Nov 2021 08:26:57 +0800

Hi,Shraddha:

Aijun Wang
China Telecom

> On Nov 26, 2021, at 12:49, Shraddha Hegde <[email-masked]> wrote:
> 
> 
> Huzhibo,
>  
> (for node failure).
[WAJ] For SRv6 policy based tunnel, the previous node may not be the neighbor node. It may locate in other area.
> You don’t really require the failure event to propagate to another domain to trigger local protection.
>  
> Rgds
> Shraddha
>  
>  
> Use anycast SID as mid-points for redundancy
> Mid-point failure local protection by looking up next sid (This is probably the one you pointed out)
> E2E S-BFD for SR-Policy  path liveness detection
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 27 Nov 2021 01:33:15 +0100

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 ingress node
which applies a full SID list. And that IMHO is a role of SR inband OAM not
IGP especially when you are crossing areas.

Many thx,
Robert

---

From: Huzhibo <[email-masked]>
Date: Sat, 27 Nov 2021 03:13:16 +0000

Hi Robert:

There may be other egress protection solution. However, the PLR is a P node and cannot sense BGP information. The PLR needs to establish a master/backup PE relationship. In some implementations as I know, It was manually specified in some way. Dynamic and automated I'm not sure if there's a available and safe solution.

Regards

Zhibo

发件人: Lsr [mailto:[email-masked]] 代表 Robert Raszuk
发送时间: 2021年11月26日 17:00
收件人: Huzhibo <huzhibo=[email-masked]>
抄送: Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Christian Hopps <[email-masked]>; Aijun Wang <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>; Shraddha Hegde <shraddha=[email-masked]>; Tony Przygienda <[email-masked]>
主题: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Huzhibo,

> specifying the master/backup relationship of egress protection is complex

Sure is - but there is absolutely no requirement to do it. BGP already carries all information needed to instantiate such protection. It is therefore all dynamic and automated.

As said cost is extra LFIB space on the PEs acting as a backup. With per VRF or per CE label allocation that is not big deal. With per prefix label allocation yes that can be a resource constraint to consider.

So if we are discussing drawbacks of any proposal let's just use correct arguments :)

Cheers,
R.

On Fri, Nov 26, 2021 at 9:09 AM Huzhibo <huzhibo=[email-masked]<mailto:[email-masked]>> wrote:
Hi, Shraddha:

Regards

Zhibo

From: Lsr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Shraddha Hegde
Sent: Friday, November 26, 2021 12:49 PM
To: Huzhibo <huzhibo=[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; 'Tony Li' <[email-masked]<mailto:[email-masked]>>
Cc: 'Les Ginsberg (ginsberg)' <[email-masked]<mailto:[email-masked]>>; 'Gyan Mishra' <[email-masked]<mailto:[email-masked]>>; 'Christian Hopps' <[email-masked]<mailto:[email-masked]>>; 'lsr' <[email-masked]<mailto:[email-masked]>>; 'Acee Lindem (acee)' <[email-masked]<mailto:[email-masked]>>; 'Tony Przygienda' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Huzhibo,

Rgds
Shraddha

Hi, Shraddha:

Thanks

Zhibo

Aijun,

Rgds
Shraddha

Hi, Shraddha:

Best Regards

Aijun Wang
China Telecom

WG,

Rgds
Shraddha

Hi Aijun,

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 27 Nov 2021 11:18:40 +0100

All P routers (except very few exceptions) run the very same software as
PEs. So it can easily build a session to RR to learn the routes.

Thx,
R.

On Sat, Nov 27, 2021 at 4:13 AM Huzhibo <huzhibo=[email-masked]>
wrote:

> Hi Robert:
>
>
>
> There may be other egress protection solution. However, the PLR is a P
> node and cannot sense BGP information. The PLR needs to establish a
> master/backup PE relationship. In some implementations as I know, It was
> manually specified in some way. Dynamic and automated I'm not sure if
> there's a available and safe solution.
>
>
>
> Regards
>
>
>
> Zhibo
>
>
>
> *发件人:* Lsr [mailto:[email-masked]] *代表 *Robert Raszuk
> *发送时间:* 2021年11月26日 17:00
> *收件人:* Huzhibo <huzhibo=[email-masked]>
> *抄送:* Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <
> [email-masked]>; Acee Lindem (acee) <[email-masked]>; Christian
> Hopps <[email-masked]>; Aijun Wang <[email-masked]>; Tony
> Li <[email-masked]>; lsr <[email-masked]>; Shraddha Hegde <shraddha=
> [email-masked]>; Tony Przygienda <[email-masked]>
> *主题:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR
> Meeting Minutes
>
>
>
>
>
> Huzhibo,
>
>
>
> On Fri, Nov 26, 2021 at 9:09 AM Huzhibo <huzhibo=
> [email-masked]> wrote:
>
> Hi, Shraddha:
>
>
>
> about the mid-point failure
>

---

From: Aijun Wang <[email-masked]>
Date: Sat, 27 Nov 2021 19:04:54 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 27, 2021, at 18:19, Robert Raszuk <[email-masked]> wrote:
> 
> 
> 
> All P routers (except very few exceptions) run the very same software as PEs. So it can easily build a session to RR to learn the routes. 
[WAJ] if we agree all P routers and PE routers expect to receive such information, is there any advantage to use BGP to transfer information? Considering there are some unsolved questions that we mentioned for your proposal in another thread?

> 
> Thx,
> R.
> 
>> On Sat, Nov 27, 2021 at 4:13 AM Huzhibo <huzhibo=[email-masked]> wrote:
>> Hi Robert:
>> 
>>  
>> 
>> On Fri, Nov 26, 2021 at 9:09 AM Huzhibo <huzhibo=[email-masked]> wrote:
>> 
>> Hi, Shraddha:
>> 
>>  
>>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 27 Nov 2021 15:01:50 +0100

> > All P routers (except very few exceptions) run the very same software
> > as PEs. So it can easily build a session to RR to learn the routes.
>
> [WAJ] if we agree all P routers and PE routers expect to receive such
information,

Not all but only those adjacent to PEs under such protection scheme.

> is there any advantage to use BGP to transfer information?

Yes.

> Considering there are some unsolved questions that we mentioned for your
> proposal in another thread?

Consider them resolved.

Thx,
R.

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 28 Nov 2021 01:10:53 -0500

Robert

For using PUA/Pulse ideas of providing same mechanisms in BGP, however as
PIC cannot be utilized for the iBGP next hop component prefix tracking in
any of the three options both PUA & Pulse would provide a much faster
protection for next hop component prefix  tracking then using BGP.

Since the underlay route recursive for iBGP is carried in the IGP and the
summarization is done by the IGP it makes sense to have an IGP based
solution.

With option 1 running single hop BFD with IGP millisecond detection time
along with LFA/RLFA/TI-LFA local protection for FRR convergence.  You won’t
achieve anywhere close to the same with BFD with the iBGP peering.

With Option 2 again same answer as option 1 it’s much better to have IGP
for BGP recursive next hop tracking using PUA/Pulse.

Option 3 is the only one I can see maybe possible but then again BGP is not
a dump truck either, and I don’t know if operators would like the event
notification pulses / PUA mechanism in BGP-LS.  Especially if operators are
already using PCE or PCE CC centralized controller, it’s doubtful that they
would want to overload and impact BGP-LS NBI as it’s already being used to
build the network graph.

RFC 8679 egress protection has its place and is a viable alternative for
egress PE next hop liveliness
for large domains where operators are using RSVP-TE or otherwise.  Also as
mentioned in the thread SRv6 S-BFD for SR policy liveliness also makes
sense as possible mid point protection alternatives.

Kind Regards

Gyan

On Thu, Nov 25, 2021 at 12:26 PM Robert Raszuk <[email-masked]> wrote:

> IBGP will time out in 180 sec. That also means that whatever PUA/PULSE is
> there it MUST "last" min 200 sec on the remote PEs.
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 28 Nov 2021 01:25:10 -0500

Robert

Are we talking here about applying RFC 8679 egress protection to SRV6
policy protection mechanism as compared to PUA/Pulse IGP based solution?

Gyan

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 28 Nov 2021 14:11:19 +0100

> however as PIC cannot be utilized for the iBGP next hop component

Who told you that ?

PIC stands for Prefix Independent Convergence and its core function which
is hierarchical FIB structure careless how the information about next hop
down event arrives to the network element.

> Since the underlay route recursive for iBGP is carried in the IGP

In the Option 2 and Option 3 as illustrated it is carried in BGP not IGP.

> achieve anywhere close to the same with BFD with the iBGP peering.

BFD timers are protocol/client agnostic.

LFA/RLFA/TI-LFA all are completely orthogonal to the current discussion so
bringing it here is simple destruction of the topic.

And I would prefer if you explain in details why BFD for IBGP can not be
used to detect the PE going down instead of throwing assertions of the
type: "You won't achieve" I understand the power of myths, but I prefer we
should rather talk about facts.

> for BGP recursive next hop tracking using PUA/Pulse.

If you say that Option 2 is the same answer as Option 1 that is clear
indication that you did not get it. And again statements like "it's much
better" without providing real technical arguments are not helpful.

> would want to overload and impact BGP-LS NBI as it’s already being used to

Fine. As I mentioned we could use ZeroMQ or invent new TCP/QUIC protocol. I
have no problem with that.

Rgs,
R.

On Thu, Nov 25, 2021 at 12:26 PM Robert Raszuk <[email-masked]> wrote:
>> to PE1 can be two BGP session - one with BFD one without to easily separate

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 28 Nov 2021 16:13:18 -0500

Hi Robert

In-line

> down event arrives to the network element.

  I am talking about BGP PIC Edge pre programmed backup path on PE for eBGP
which is different then PIC core which uses H-FIB yields  faster
convergence RIB/FIB convergence so next hop updates in the core FIB and not
BGP prefixes.

PIC core does not have a MBB style pre programmed backup path  as PIC Edge.

Also  IGP protection mechanisms LFA/RLFA/TILFA you say are orthogonal as we
are taking “BGP versus IGP” for PUA/Pulse mechanism I think that is
relevant as far as convergence and which method is better for PUA/Pulse.
Also the H-FIB is the 2 layer FIB restructure for faster BGP  prefix
independent convergence, however not the same as local protection you get
with IGP protection above.

Also with iBGP multi hop BFD over IGP discussion there is a dependency on
the IGP so if the IGP is slower to converge as does not have BFD enabled on
the IGP as well as don’t have local protection mechanisms enabled as well
LFA/RLFA/TILFA the IGP will be slow to converge and thus iBGP with BFD will
be slow as well to converge as it’s based on BGP NH tracking callback BGP
to IGP recursive route to next hop attribute.

Also I don’t think operators would be game to run BFD over both IGP P2P
links as well as iBGP peering. That would be quite an overkill and a hard
sell as for any gains looking at pros and cons.  Also if you have tons of
PEs which in this case for large operators domains that is quite a number
of BFD sessions PE-RR and would be overkill. Even though running in
hardware still it’s a hard sell for operators to see the gain.

So it still boils down to IGP convergence as iBGP is dependent recursion to
IGP.  Also you have the BGP propagation time relaying on overlay of the
PUA/PULSE  PE-RR-PE.

There  is also a issue similar to what is mentioned related to BGP-LS
overloading BGP as BGP is not a ubiquitous dump truck as mentioned about
the IGP adding an extension and impact of iBGP operations with event
notification is not desirable to operators.

With PUA/PULSE would yield an instant local protection style convergence as
compare to using BGP which has IGP dependencies and a non protected
convergence.

> BFD timers are protocol/client agnostic
>

     Gyan> Understood.  My point here is on the local protection moreso
then the BFD timers

> bringing it here is simple destruction of the topic.

Gyan> I don’t think so as mentioned above as we are  talking about BGP
versus IGP for PUA/Pulse and which is better so it’s completely relevant.

> better" without providing real technical arguments are not helpful.

Gyan> please see above.

> Fine. As I mentioned we could use ZeroMQ or invent new TCP/QUIC protocol.
> I have no problem with that.
>

>>> in BGP vs IGP. Keep in mind that only PE2 on the illustration is interested
>>> in this bad news.
>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 28 Nov 2021 22:31:47 +0100

Gyan,

#1 Detection of PE DOWN event when using BFD over IBGP does not depend on
IGP convergence.

#2 Both PUA/PULSE are triggered at ABR by local area IGP complete
convergence. The very same local IGP convergence will complete faster to
RRs in the area when RRs are part of the IGP. That can be a trigger if you
are allergic to run BFD over IBGP

#3 As to BFD session scaling, that limit is important in respect to 100s or
1000s EBGP sessions from such PE. Not when talking about adding two more
sessions to RRs.

That should do it for now.

Rgs,
R.

On Sun, Nov 28, 2021 at 10:13 PM Gyan Mishra <[email-masked]> wrote:

>   I am talking about BGP PIC Edge pre programmed backup path on PE for
> eBGP which is different then PIC core which uses H-FIB yields  faster
> Also  IGP protection mechanisms LFA/RLFA/TILFA you say are orthogonal as
> we are taking “BGP versus IGP” for PUA/Pulse mechanism I think that is
> So it still boils down to IGP convergence as iBGP is dependent recursion
> to IGP.  Also you have the BGP propagation time relaying on overlay of the
> PUA/PULSE  PE-RR-PE.
>
> With PUA/PULSE would yield an instant local protection style convergence
> as compare to using BGP which has IGP dependencies and a non protected
> convergence.
>
>>
>> LFA/RLFA/TI-LFA all are completely orthogonal to the current discussion
>> so bringing it here is simple destruction of the topic.
>>
>
> Option 3 is the only one I can see maybe possible but then again BGP is
>>> not a dump truck either, and I don’t know if operators would like the event
>>>> For PUA/PULSE to get triggered by ABR all PE1 IGP neighbours must
>>>> report PE1 to be out - hence we are already limited to the local area
>>>> detection of PE1 down and local flooding.
>>>>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 28 Nov 2021 18:42:56 -0500

Robert

In-line

> #1 Detection of PE DOWN event when using BFD over IBGP does not depend on

BFD over iBGP would use multi hop BFD RFC 5883 which utilizes the same
mechanisms defined in single hop BFD RFC 5881 but over multi hop.  There
are caveats with demultiplexing the multiple BFD sessions control packets
however in this scenario I don’t believe there will be multiple BFD
sessions.

RFC 5882 Generic application of BFD mentions below section 2

   An implementation SHOULD establish only a single BFD session per data
   protocol path, regardless of the number of applications that wish to
   utilize it.  There is no additional value in having multiple BFD
   sessions to the same endpoints.

Operators would have single hop P2P BFD over IGP client and having another
iBGP BFD session would be over the same data path.

This would really preclude the use of BGP for PUA/Pulse right not the bat.

In DC and maybe other environments as long as the PE and RR are directly
connected then no IGP dependency exists.

In the large operator domains where PUA/Pulse would be utilized the PE and
RR would at least traverse some number of P routers so would not be
directly connected.

So the IGP would provide reachability between the PE and RR loopbacks and
so the IGP would have to be converged for BGP TCP session to establish.

Am I missing something?

> are allergic to run BFD over IBGP

Gyan> PUA and Pulse use flooding mechanisms which is instantaneous to
propagate the down event to then other areas for the protected instant
convergence.  The RR flood of PUA / Pulse event would be hierarchical
framework so would reflected upstream over multiple hops.   As the IGP has
its local protection optimizations as well as BFD single hop detection of
next hop failure the convergence would be instantaneous.

>
> #3 As to BFD session scaling, that limit is important in respect to 100s
> or 1000s EBGP sessions from such PE. Not when talking about adding two more
> sessions to RRs.
>

    Gyan> Scale would be on the RR now terminating many BFD sessions.

>>> PIC stands for Prefix Independent Convergence and its core function
>>> which is hierarchical FIB structure careless how the information about next
>>> hop down event arrives to the network element.
>>>
>>
>>> Fine. As I mentioned we could use ZeroMQ or invent new TCP/QUIC
>>> protocol. I have no problem with that.
>>>
>>
>>
>>> Rgs,
>>> R.
>>>
>>>
>>>>> *Option 1* - Classic/ Today's design. If you simply enable BFD on
>>>>> IBGP between PE1 and RR I bet we would not even be discussing anything as
>>>>> Again very easy to accomplish today modulo your BGP implementation.
>>>>> RR1 to PE1 can be two BGP session - one with BFD one without to easily
>>>>> In all cases RFC8679 can still protect against PE1 failure at local
>>>>> PLR directing traffic to backup PE1' (not on the picture but we assume it
>>>>> is there otherwise it is all moot).
>>>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 29 Nov 2021 00:56:09 +0100

> so the IGP would have to be converged for BGP TCP session to establish.

Yes. Entire concept of PUA/PULSE is about detecting transition to "DOWN"
state of the PE.

So talking about IGP convergence for TCP session to be established is
completely irrelevant,

> next hop failure the convergence would be instantaneous.

Whow !

#1 - Nothing is instantaneous

#2 - Before PUA/PULSE code kicks in local area must *fully* converge first.

#3 - Hierarchy is good for you.

#4 - Withdraw propagation via RRs is very fast (max - miliseconds)

#5 - Propagating single or few BGP withdrawal messages over two RRs is much
faster then flooding over 2 areas and N IGP nodes (which btw have zero
interest in this opaque to them information).

>     Gyan> Scale would be on the RR now terminating many BFD sessions.

That is not of any practical issue considering current support numbers used
for EBGP BFD as example.

Many thx,
R.

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 28 Nov 2021 20:38:17 -0500

Robert

In your BGP PUA/PULSE options where BGP detects the Down PE, how would that
event be sent back to IGP to trigger it to converge on alternate path.

As this is an event notification of a Down PE would you use the same next
hop tracking BGP callback to IGP for the event notification or maybe some
other mechanism?

> Yes. Entire concept of PUA/PULSE is about detecting transition to "DOWN"

Gyan> ok

> So talking about IGP convergence for TCP session to be established is

Gyan> So here we are talking specifically about the down event propagation
via BGP.  Understood.  As we delve into convergence and BFD that’s where
all my questions noted come up in the thread.  I think my convergence
related comments on iBGP is still a valid.

> #1 - Nothing is instantaneous

    This solution uses IGP flooding mechanics for the event flooding which
is fast

> #2 - Before PUA/PULSE code kicks in local area must *fully* converge

Gyan> The event would be flooded domain wide as i would be of interest to
any routers in the other area so does not require the local area to be
converged first as this is event notification being propagated and not a
routing update.

Gyan> The sequence of events is first the detection of node down in the
origin area, followed by flooding of the event domain wide and lastly
convergence of the egress PE based on the event notification.  This would
be very fast in milliseconds.  We are not flooding the entire LSDB it’s
just the PE down event being flooded so very fast.

> #5 - Propagating single or few BGP withdrawal messages over two RRs is
> much faster then flooding over 2 areas and N IGP nodes (which btw have zero
> That is not of any practical issue considering current support numbers
> used for EBGP BFD as example.
>

     Gyan> Understood

*Gyan Mishra*

*M 301 502-1347*

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 29 Nov 2021 09:42:57 +0800

Hi, Robert:

Let’s review your BGP proposals again after the previous intense discussions.

Option 1: Obviously can’t solve the current problem, we can drop it off.

Option 2: You require not only the BFD session between RR and PE(not one-hop BFD, but multi-hop BFD), but also additional IBGP session between RR and PE.  Considering there are so many PEs, then your proposal require the additional BGP sessions  and multi-hop BFD sessions on all these PEs. Right?  Comparing with the automatic PUA/PULSE mechanism, which one is easy to operate?

Option 3: The “DOWN” detection on ABR is same as PUA/PULSE, the different is how to propagate such “DOWN” information. Considering we have observed that all P/PE router in other areas may be interested such information, your proposal will require every P/PE router run BGP-LS, which is not the aimed deploy scenarios for BGP-LS.

Then, if IGP has such capabilities, why bother BGP? What is the benefit?

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Robert Raszuk
Sent: Friday, November 26, 2021 1:25 AM
To: lsr <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Tony Li <[email-masked]>; Aijun Wang <[email-masked]>; Shraddha Hegde <[email-masked]>; Peter Psenak <[email-masked]>
Subject: [Lsr] BGP vs PUA/PULSE

Dear LSR WG,

I wanted to visualize the scenario we are so deeply discussing here. Specifically BGP vs IGP flooding as well as applicability of RFC8679. 

Below are three options comparing what it takes to distribute bad news in BGP vs IGP. Keep in mind that only PE2 on the illustration is interested in this bad news. 

Option 1 - Classic/ Today's design. If you simply enable BFD on IBGP between PE1 and RR I bet we would not even be discussing anything as things will just work well as is today. 

Option 2 - BGP recursion as discussed earlier to speed up NH down propagation vs service route withdraw. 

Again very easy to accomplish today modulo your BGP implementation. RR1 to PE1 can be two BGP session - one with BFD one without to easily separate the sequence of BGP events. 

Option 3 - BGP-LS from ABRs 

In all cases RFC8679 can still protect against PE1 failure at local PLR directing traffic to backup PE1' (not on the picture but we assume it is there otherwise it is all moot). 

And in fact local protection is the only one which can assure minimum service disruption time. 

For PUA/PULSE to get triggered by ABR all PE1 IGP neighbours must report PE1 to be out - hence we are already limited to the local area detection of PE1 down and local flooding.

Now imagine someone will not like to use BFD+BGP. Well that means that IBGP will time out in 180 sec. That also means that whatever PUA/PULSE is there it MUST "last" min 200 sec on the remote PEs.  

Many thx,

Robert

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 29 Nov 2021 09:31:39 +0100

Aijun,

As I wrote to Gyan earlier RR in Option 2 and ABR in Option 3 can use
today's local area IGP to find out about PE going down. No need for any
additional iBGP sessions with BFD there or even enabling new messages on
the existing sessions. That said IBGPP between RRs to PEs is pretty much
already there so not sure what is the point you are making about
operational overhead.

In option 1 we can solve the problem too. I am not dropping it off - but
sure you may. I already described how to make BGP withdrawals to be
aggregated.

> Then, if IGP has such capabilities, why bother BGP? What is the benefit?

One reason is to keep underlay topology rock solid and *immune* to anything
which happens in any area. PUA/PULSE makes it weaker. Melting maybe not,
but clearly impacted.

Just imagine I have 8 level ISIS and have 1000s of virtual PEs flapping in
the last chain of the hierarchy. Is this wise to flood that events in my
entire 8 level IGP ? Hint:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-extended-hierarchy/

Areas are build to protect other areas from any topological changes. Here
you are opening up the doors so the insects can come in. Sure maybe one or
few of them will just bother you only a little, but the moment you see
swarm of them it is already too late.

Best,
R.

On Mon, Nov 29, 2021 at 2:43 AM Aijun Wang <[email-masked]>
wrote:

> Option 2: You require not only the BFD session between RR and PE(not
> one-hop BFD, but multi-hop BFD), but also additional IBGP session between
> RR and PE.  Considering there are so many PEs, then your proposal require
> the additional BGP sessions  and multi-hop BFD sessions on all these PEs.
> Right?  Comparing with the automatic PUA/PULSE mechanism, which one is easy
> to operate?
>
> Option 3: The “DOWN” detection on ABR is same as PUA/PULSE, the different
> is how to propagate such “DOWN” information. Considering we have observed
> that all P/PE router in other areas may be interested such information,
> your proposal will require every P/PE router run BGP-LS, which is not the
> aimed deploy scenarios for BGP-LS.
>
>
>
> *Sent:* Friday, November 26, 2021 1:25 AM
> *To:* lsr <[email-masked]>
> *Cc:* Les Ginsberg (ginsberg) <[email-masked]>; Tony Li <
> [email-masked]>; Aijun Wang <[email-masked]>; Shraddha Hegde <
> [email-masked]>; Peter Psenak <[email-masked]>
> *Subject:* [Lsr] BGP vs PUA/PULSE
>
>
>
> Dear LSR WG,
>
>
>

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 29 Nov 2021 17:15:19 +0800

Hi, Robert:

From: Robert Raszuk <[email-masked]> 
Sent: Monday, November 29, 2021 4:32 PM
To: Aijun Wang <[email-masked]>
Cc: lsr <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Tony Li <[email-masked]>; Shraddha Hegde <[email-masked]>; Peter Psenak <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Aijun,

As I wrote to Gyan earlier RR in Option 2 and ABR in Option 3 can use today's local area IGP to find out about PE going down. No need for any additional iBGP sessions with BFD there or even enabling new messages on the existing sessions. That said IBGPP between RRs to PEs is pretty much already there so not sure what is the point you are making about operational overhead. 

[WAJ] For Option 2, the RR is always located at the different area that the PE stays. Then if there is no BFD, it can’t find out the PE going down instantly when the summary prefix is advertised.

Per my understanding, you need one additional iBGP session(PE1 and RR1) to advertise the BGP NH information(for recursive BGP nexthop lookup), right? If so, I think these are all operational overhead.

In option 1 we can solve the problem too. I am not dropping it off - but sure you may. I already described how to make BGP withdrawals to be aggregated.

[WAJ] How to achieve the BGP fast convergence? Sorry to miss it.

> Then, if IGP has such capabilities, why bother BGP? What is the benefit?

One reason is to keep underlay topology rock solid and immune to anything which happens in any area. PUA/PULSE makes it weaker. Melting maybe not, but clearly impacted. 

Just imagine I have 8 level ISIS and have 1000s of virtual PEs flapping in the last chain of the hierarchy. Is this wise to flood that events in my entire 8 level IGP ? Hint: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-extended-hierarchy/

Areas are build to protect other areas from any topological changes.

[WAJ] Yes. But It does not prevent the LSA flooding.  The main aim of area isolation is just to avoid the SPF churn? As we stated earlier, PUA/PULSE does not trigger the SPF calculation.

It is also possible that the nodes within the entire 8 level IGP(Although we seldom design so many hierarches network) are all interested in such message, for example, the SRv6 TE path span all of these levels? 

Here you are opening up the doors so the insects can come in. Sure maybe one or few of them will just bother you only a little, but the moment you see swarm of them it is already too late. 

Best,

R.

On Mon, Nov 29, 2021 at 2:43 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Robert Raszuk
Sent: Friday, November 26, 2021 1:25 AM
To: lsr <[email-masked] <mailto:[email-masked]> >
Cc: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> >; Tony Li <[email-masked] <mailto:[email-masked]> >; Aijun Wang <[email-masked] <mailto:[email-masked]> >; Shraddha Hegde <[email-masked] <mailto:[email-masked]> >; Peter Psenak <[email-masked] <mailto:[email-masked]> >
Subject: [Lsr] BGP vs PUA/PULSE

Dear LSR WG,

 

 

 

Many thx,

Robert

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 29 Nov 2021 10:26:53 +0100

On Mon, Nov 29, 2021 at 09:42:57AM +0800, Aijun Wang wrote:

[ ... ]

|    Option 3: The “DOWN” detection on ABR is same as PUA/PULSE, the different
|    is how to propagate such “DOWN” information. Considering we have observed
|    that all P/PE router in other areas may be interested such information,
|    your proposal will require every P/PE router run BGP-LS, which is not the
|    aimed deploy scenarios for BGP-LS.
 
HG> BGP-LS has been conceived to solve the very problem of providing visibility of other
area's link state. I fail to see what is out of scope here.

|    Then, if IGP has such capabilities, why bother BGP? What is the benefit?

HG> simply put: seperation of concerns. Agreed consensus is to mostly use the
IGP for topology discovery and put the bulk of carrying reachability information
into BGP which gives us:

1) flow-control capabilities (=by virtue of TCP) and
2) furthermore operators can scale and isolate the distribution vehicle for a given AFI/SAFI service
   using a dedicated RR infrastructure which does not mess with your bread and butter service
   infra.

IMO it is not a good idea to put (negative) reachability information back into the IGP as you
would loose this "seperation of concerns" aspect and potentially de-stabilize your topology discovery
tool and hence *all* your bread-and-butter services.

HTH,

/hannes

---

From: Peter Psenak <[email-masked]>
Date: Mon, 29 Nov 2021 10:39:37 +0100

Robert,

On 26/11/2021 19:20, Robert Raszuk wrote:
> That's the most scary and not well understood part of it. Ghosts ! 
> Appears and magically disappears.

think of it as LSP with the lifetime of 60 sec. Nothing magical about it.

> Well unless you are going to send it in completely separate LSAs/LSPs 
> what you state above may not be really true.

have you read draft-ppsenak-lsr-igp-event-notification-00?

It is using a completely new set of PDUs for its operation.

thanks,
Peter

> 
>     see above why the pulse.
> 
> 
> I asked a very simple question. In your scenario - no BGP - there 
> is*p2mp**tunnel* - How does PULSE work on the PEs receiving it ?
>

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 29 Nov 2021 19:16:18 +0800

Hi, Hannes:

-----Original Message-----
From: Hannes Gredler <[email-masked]> 
Sent: Monday, November 29, 2021 5:27 PM
To: Aijun Wang <[email-masked]>
Cc: 'Robert Raszuk' <[email-masked]>; 'lsr' <[email-masked]>; 'Les Ginsberg (ginsberg)' <[email-masked]>; 'Tony Li' <[email-masked]>; 'Shraddha Hegde' <[email-masked]>; 'Peter Psenak' <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

[ ... ]

HG> BGP-LS has been conceived to solve the very problem of providing 
HG> visibility of other
area's link state. I fail to see what is out of scope here.
[WAJ] Yes. But it is not for the nodes within IGP itself. It's main aim is to feed the underlay topology information to the controller.

HG> simply put: seperation of concerns. Agreed consensus is to mostly 
HG> use the
IGP for topology discovery and put the bulk of carrying reachability information into BGP which gives us:

IMO it is not a good idea to put (negative) reachability information back into the IGP as you would loose this "seperation of concerns" aspect and potentially de-stabilize your topology discovery tool and hence *all* your bread-and-butter services.
[WAJ] Yes. We are seeking the solution to the potential use of such unreachable information. Current BGP solutions has not convinced me until now.

HTH,

/hannes

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 29 Nov 2021 13:58:24 +0100

Hey Peter,

> think of it as LSP with the lifetime of 60 sec. Nothing magical about it.

That 60 sec is not long enough.

If folks do not want to quickly detect the failure by iBGP by running BFD
def iBGP holdtime is 180 sec ! So right there if you timeout PULSE after 60
sec the broken best paths may kick in again. If anything I recommend you
make it min. 200 sec.

> It is using a completely new set of PDUs for its operation.

Sure. That comment was more towards proposed PUA encoding.

Thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Mon, 29 Nov 2021 14:26:20 +0100

Hi Robert,

On 29/11/2021 13:58, Robert Raszuk wrote:
> If folks do not want to quickly detect the failure by iBGP by running 
> BFD def iBGP holdtime is 180 sec ! So right there if you timeout PULSE 
> after 60 sec the broken best paths may kick in again. If anything I 
> recommend you make it min. 200 sec.

ok, whatever we believe is sufficient.

thanks,
Peter

---

From: Aijun Wang <[email-masked]>
Date: Mon, 29 Nov 2021 21:31:12 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 29, 2021, at 20:59, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hey Peter,
>  
> If folks do not want to quickly detect the failure by iBGP by running BFD def iBGP holdtime is 180 sec ! So right there if you timeout PULSE after 60 sec the broken best paths may kick in again. If anything I recommend you make it min. 200 sec. 
> 

[WAJ] For PUA solution, when the router receives the prefix, it should check first its originator information. If it is NULL then trigger the overlay service switchover and noting else; if not, follow the normal LSA procedures. Is there any confused step?

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 29 Nov 2021 16:45:48 +0100

hi aijun,

On Mon, Nov 29, 2021 at 07:16:18PM +0800, Aijun Wang wrote:
| Hi, Hannes:
| 
| -----Original Message-----
| From: Hannes Gredler <[email-masked]> 
| Sent: Monday, November 29, 2021 5:27 PM
| To: Aijun Wang <[email-masked]>
| Cc: 'Robert Raszuk' <[email-masked]>; 'lsr' <[email-masked]>; 'Les Ginsberg (ginsberg)' <[email-masked]>; 'Tony Li' <[email-masked]>; 'Shraddha Hegde' <[email-masked]>; 'Peter Psenak' <[email-masked]>
| Subject: Re: [Lsr] BGP vs PUA/PULSE
| 
| On Mon, Nov 29, 2021 at 09:42:57AM +0800, Aijun Wang wrote:
| 
| [ ... ]
| 
| |    Option 3: The “DOWN” detection on ABR is same as PUA/PULSE, the different
| |    is how to propagate such “DOWN” information. Considering we have observed
| |    that all P/PE router in other areas may be interested such information,
| |    your proposal will require every P/PE router run BGP-LS, which is not the
| |    aimed deploy scenarios for BGP-LS.
|  
| HG> BGP-LS has been conceived to solve the very problem of providing 
| HG> visibility of other
| area's link state. I fail to see what is out of scope here.
| [WAJ] Yes. But it is not for the nodes within IGP itself. It's main aim is to feed the underlay topology information to the controller.

HG> BGP-LS has been used now beyond 3rd party controllers. I do also see you as co-author of some drafts in LSVR
    Note that a similar protocol machinery like used in LSVR can be made to work for your use case here.

| |    Then, if IGP has such capabilities, why bother BGP? What is the benefit?
| 
| HG> simply put: seperation of concerns. Agreed consensus is to mostly 
| HG> use the
| IGP for topology discovery and put the bulk of carrying reachability information into BGP which gives us:
| 
| 1) flow-control capabilities (=by virtue of TCP) and
| 2) furthermore operators can scale and isolate the distribution vehicle for a given AFI/SAFI service
|    using a dedicated RR infrastructure which does not mess with your bread and butter service
|    infra.
| 
| IMO it is not a good idea to put (negative) reachability information back into the IGP as you would loose this "seperation of concerns" aspect and potentially de-stabilize your topology discovery tool and hence *all* your bread-and-butter services.
| [WAJ] Yes. We are seeking the solution to the potential use of such unreachable information. Current BGP solutions has not convinced me until now.

perhaps you start elaborating what *exactly* you find not convincing of the proposed IGP/BGP split.

thanks,

/hannes

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 29 Nov 2021 17:27:45 +0000

Speaking as WG Chair:

I believe this discussion has gone off track and the details of the BGP alternatives need to be discussed on the IDR list. For the purposes of the LSR discussion, Robert believes that this is a problem that needs to be solved but that it could be better solved using BGP as described in draft-raszuk-idr-yet-another-complex-idr-draft-00.txt. 

Correct me if I'm wrong... 

Thanks,
Acee

On 11/29/21, 10:46 AM, "Lsr on behalf of Hannes Gredler" <[email-masked] on behalf of [email-masked]> wrote:

    hi aijun,

    thanks,

    /hannes

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 29 Nov 2021 19:29:23 +0100

Hi Acee,

> Robert believes that this is a problem that needs to be solved but that
it could be better
> solved using BGP as described in
draft-raszuk-idr-yet-another-complex-idr-draft-00.txt.
> Correct me if I'm wrong...

Indeed you are not correct.

The draft name (if at needed to have a draft on basic BGP operation) would
be:

draft-raszuk-idr-simple-nh-down-signalling-00.txt

Keep in mind that Option 1 and Option 2 as described does not require a
single line of code change to any decent shipping BGP implementation.

Please observe that the functionality discussed here as an additional
optimisation to normal BGP has already been submitted to IDR in 2005 and
presented in IDR WG meeting:

https://www.ietf.org/archive/id/draft-raszuk-aggr-withdraw-00.txt

As this is just an optimisation two conclusions surfaced at that time

Conclusion 1 - "If you configure your network correctly BGP as is works
just fine"

Conclusion 2 - "Some of the enhancements can be done with local vendor
knobs which do not require protocol extensions"

Kind regards,
Robert.

On Mon, Nov 29, 2021 at 6:27 PM Acee Lindem (acee) <[email-masked]> wrote:

> Speaking as WG Chair:
>
> I believe this discussion has gone off track and the details of the BGP
> alternatives need to be discussed on the IDR list. For the purposes of the
> LSR discussion, Robert believes that this is a problem that needs to be
> solved but that it could be better solved using BGP as described in
> draft-raszuk-idr-yet-another-complex-idr-draft-00.txt.
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 29 Nov 2021 22:39:17 +0000

Hannes -

Thanx for bringing a new voice into the discussion.

Please see inline.

> Sent: Monday, November 29, 2021 1:27 AM

> Cc: 'Robert Raszuk' <[email-masked]>; 'lsr' <[email-masked]>; Les Ginsberg

> (ginsberg) <[email-masked]>; 'Tony Li' <[email-masked]>; 'Shraddha

> Hegde' <[email-masked]>; Peter Psenak (ppsenak)

> <[email-masked]>

> |    Option 3: The “DOWN” detection on ABR is same as PUA/PULSE, the

> different

> |    is how to propagate such “DOWN” information. Considering we have

> observed

> visibility of other

[LES:] BGP-LS only advertises what the IGPs themselves advertise.

In this case, both IGP proposals involve ephemeral advertisements - so even if we were to define BGP-LS support for these new advertisements - they wouldn't persist long enough to be reflected in BGP-LS.

So, I really don’t know why we are discussing BGP-LS in the context of this thread.

(This seems to be one example of what Acee correctly identified as this discussion going "off track".)

> HG> simply put: seperation of concerns. Agreed consensus is to mostly use

> the

> IGP for topology discovery and put the bulk of carrying reachability

> information

[LES:] I am not convinced either side can claim "consensus" in this discussion. That is a work in progress. 😊

However, when you say IGPs are (exclusively?) for topology discovery - it seems to suggest that IGP shouldn’t be advertising prefix reachability at all. Hopefully, that is not what you intend.

One of the points that still baffles me is the assertion of an architectural violation in the IGP proposals.

It is OK for IGPs to advertise all prefixes covered by a summary (i.e., do not summarize).

It is OK for IGPs to advertise multiple summaries (e.g., multiple /24s instead of a single /16).

It is even OK for IGPs to advertise some prefixes covered by a summary along with the summary (don’t know if any implementations do this - but they could).

None of this is an "architectural violation".

But advertising a summary and signaling the loss of reachability to a specific prefix covered by the summary is seen by some as an architectural violation.

Sorry, I still don't understand this argument.

You can not like the approach. You can be concerned about scaling properties (more on that below). You can question the effectiveness of ephemeral advertisements.

These kinds of objections/concerns I can easily understand - even if we don’t agree on their significance.

But claiming that "IGPs are not supposed to do this"??

Not grokking this.

We have not added any new information to the IGP itself. We are only suggesting a new form of advertisement to signal some information already known to the IGP, but which is currently not advertised (in some deployments) by the configuration of summaries.

> 2) furthermore operators can scale and isolate the distribution vehicle for a

> given AFI/SAFI service

>    using a dedicated RR infrastructure which does not mess with your bread

> and butter service

> IMO it is not a good idea to put (negative) reachability information back into

> the IGP as you

> would loose this "seperation of concerns" aspect and potentially de-stabilize

> your topology discovery

[LES:] The questions of scale (as I have previously commented) are very legitimate - and more has to be specified before an IGP solution would be considered ready for deployment. But there are tools easily applicable to address this (rate limiting, embedded summarization, perhaps others).

The more significant point is to focus on the goal - which in this usage is improved convergence time.

When the network is largely stable, convergence improvements can be achieved w/o risk.

When widespread failures occur, real time signaling of any type is unlikely to provide improved convergence - which is why the IGPs today shift the focus from convergence to stability by slowing down the rate of updates sent and SPFs performed. This is STILL true even in the fast convergence/FRR era.

I see no reason why the same tools should not be used in this case.

   Les

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 29 Nov 2021 23:53:38 +0100

Hi Les,

Just to summarize my personal take on this thread in the light of your last
email.

#1 - I am not ok with the ephemeral nature of the advertisements. (I
proposed an alternative).

#2 - I am not ok with spreading the information everywhere including all P
and PE routers which do not need it.

#3 - 1 days ago you said: "The legitimate question is whether folks see it
as appropriate to have an IGP based solution for the problem." So bringing
a BGP alternative seems to be very much in line with your guidance for this
thread.

#4 - I am not sure it is OK for IGP to advertise a bunch of area local info
to every IGP node. The fact that it was pushed through IETF with brute
force does not make it a great protocol evolution. Maybe now it is time to
close that gate ?

Kind regards,
Robert

>
> In this case, both IGP proposals involve ephemeral advertisements - so
> even if we were to define BGP-LS support for these new advertisements -
> they wouldn't persist long enough to be reflected in BGP-LS.
>
> [LES:] I am not convinced either side can claim "consensus" in this
> discussion. That is a work in progress. 😊
>
> However, when you say IGPs are (exclusively?) for topology discovery - it
> seems to suggest that IGP shouldn’t be advertising prefix reachability at
> all. Hopefully, that is not what you intend.
>
>
>
> One of the points that still baffles me is the assertion of an
> architectural violation in the IGP proposals.
>
>
>
> It is even OK for IGPs to advertise some prefixes covered by a summary
> along with the summary (don’t know if any implementations do this - but
> they could).
>
> But advertising a summary and signaling the loss of reachability to a
> specific prefix covered by the summary is seen by some as an architectural
> violation.
>
> You can not like the approach. You can be concerned about scaling
> properties (more on that below). You can question the effectiveness of
> ephemeral advertisements.
>
> We have not added any new information to the IGP itself. We are only
> suggesting a new form of advertisement to signal some information already
> known to the IGP, but which is currently not advertised (in some
> deployments) by the configuration of summaries.
>
> [LES:] The questions of scale (as I have previously commented) are very
> legitimate - and more has to be specified before an IGP solution would be
> considered ready for deployment. But there are tools easily applicable to
> address this (rate limiting, embedded summarization, perhaps others).
>
> When widespread failures occur, real time signaling of any type is
> unlikely to provide improved convergence - which is why the IGPs today
> shift the focus from convergence to stability by slowing down the rate of
> updates sent and SPFs performed. This is STILL true even in the fast
> convergence/FRR era.
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 29 Nov 2021 23:54:23 +0100

s/ 1 days ago you said/ 11 days ago you said/

Apologies,
R.

On Mon, Nov 29, 2021 at 11:53 PM Robert Raszuk <[email-masked]> wrote:

> Hi Les,
>
> Just to summarize my personal take on this thread in the light of your
> last email.
>
> #4 - I am not sure it is OK for IGP to advertise a bunch of area local
> info to every IGP node. The fact that it was pushed through IETF with brute

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 29 Nov 2021 23:08:04 +0000

Robert –

From: Lsr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Monday, November 29, 2021 2:54 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Aijun Wang <[email-masked]>; Shraddha Hegde <[email-masked]>; Tony Li <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

[LES:] Thanx for the correction. 😊

Apologies,
R.

On Mon, Nov 29, 2021 at 11:53 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Les,

Just to summarize my personal take on this thread in the light of your last email.

#1 - I am not ok with the ephemeral nature of the advertisements. (I proposed an alternative).

[LES:] So are you agreeing that an IGP solution should be pursued??
This thread is (or should be) about whether the WG wants to pursue an IGP based solution at all.
If we have consensus on that, then we can discuss (in another thread hopefully) whether either of the two current proposals is a good starting point – or whether a yet to be defined new IGP proposal is best.
We aren’t there yet.

#2 - I am not ok with spreading the information everywhere including all P and PE routers which do not need it.

[LES:] Understood. But IGPs should not be used to provide a subscription service. That is definitely inconsistent with the nature of a link state protocol.
So, if your preferred solution is a subscription service, then you are saying “not an IGP solution”.

#3 - 1 days ago you said: "The legitimate question is whether folks see it as appropriate to have an IGP based solution for the problem." So bringing a BGP alternative seems to be very much in line with your guidance for this thread.

[LES:] Having a BGP solution is a legitimate consideration, but its relevance to this thread is only whether it precludes an IGP solution.
Some folks (including me) believe both may prove to be useful.
But actual discussion of a BGP solution belongs in IDR (as Acee recently emphasized).
Please try to keep this thread focused on the question of whether an IGP solution should/should not be pursued.

#4 - I am not sure it is OK for IGP to advertise a bunch of area local info to every IGP node. The fact that it was pushed through IETF with brute force does not make it a great protocol evolution. Maybe now it is time to close that gate ?

[LES:] This seems to be a variant of point #2 – and my response is the same.

   Les

Kind regards,
Robert

Not grokking this.

   Les

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Nov 2021 15:17:35 -0800

Hi Robert,
I'm catching up with the discussion and it is very likely that someone has
asked my question:

What the BFD session between PE1 and RR is intended to detect?

BFD is not really the mechanism to indicate the health of a particular
application on a remote node. I feel that there are some implicit
assumptions of how RR interprets the failure detected. But how RR can
differentiate between a failure of the BFD system on PE1 from the failure
of the path between RR and PE1? Or these do not require characterization? I
am trying to understand what needs to be detected and compare it to which
failures can trigger a BFD session going down.

Regards,
Greg

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 30 Nov 2021 00:20:39 +0100

Hi Les,

Great, we are finally getting some focus !

Stating as an open question to use IGP or not for signalling PE
disappearance seems to me not proper in light of the facts that IGP can do
it already today by leaking.

IMO we are debating two proposals - both ephemeral - both introducing even
more opaque data to be flooded by IGP. I guess this is the crux of the
issue.

IGPs should flood topology without any subscription. 100%. But we are not
debating that. We are debating the scope of opaque information distribution
by IGPs. Opaque to the topology computation. That along with leaking should
be subscription based. Yes IGPs can help with that easily. I think both are
completely different paradigms and we should not put them in the same
basket.

Many thx,
Robert

On Tue, Nov 30, 2021 at 12:08 AM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Robert –
>
>
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Monday, November 29, 2021 2:54 PM
> *Cc:* Aijun Wang <[email-masked]>; Shraddha Hegde <
> [email-masked]>; Tony Li <[email-masked]>; Hannes Gredler <
> [email-masked]>; lsr <[email-masked]>; Peter Psenak (ppsenak) <
> [email-masked]>
> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
>
>
>
> *[LES:] Thanx for the correction. **😊*
>
>
>
> Apologies,
>
> R.
>
>
>
> *[LES:] So are you agreeing that an IGP solution should be pursued??*
>
> *This thread is (or should be) about whether the WG wants to pursue an IGP
> based solution at all.*
>
> *If we have consensus on that, then we can discuss (in another thread
> hopefully) whether either of the two current proposals is a good starting
> point – or whether a yet to be defined new IGP proposal is best.*
>
> *We aren’t there yet.*
>
>
>
> *[LES:] Understood. But IGPs should not be used to provide a subscription
> service. That is definitely inconsistent with the nature of a link state
> protocol.*
>
> *So, if your preferred solution is a subscription service, then you are
> saying “not an IGP solution”.*
>
>
>
> *[LES:] Having a BGP solution is a legitimate consideration, but its
> relevance to this thread is only whether it precludes an IGP solution.*
>
> *Some folks (including me) believe both may prove to be useful.*
>
> *But actual discussion of a BGP solution belongs in IDR (as Acee recently
> emphasized).*
>
> *Please try to keep this thread focused on the question of whether an IGP
> solution should/should not be pursued.*
>
>
>
> *[LES:] This seems to be a variant of point #2 – and my response is the
> same.*
>
>
>
> *   Les*
>
>
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>

---

From: Tony Li <[email-masked]>
Date: Mon, 29 Nov 2021 15:21:59 -0800

Les, 

> [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 topology discovery - it seems to suggest that IGP shouldn’t be advertising prefix reachability at all. Hopefully, that is not what you intend.

My position is simple: IGPs provide topology discovery, reachability, and path computation. They do not provide ‘liveness’ and are not intended to. Trying to force an IGP to carry liveness information violates the architecture of the protocol. That was never the problem to be solved. Just because you have a prefix for 1.1.1/24 does NOT imply that 1.1.1.1 will accept your packets or even that there is any host within 1.1.1/24 that will, only that the prefix is supposed to be within the advertiser’s area.

> It is OK for IGPs to advertise all prefixes covered by a summary (i.e., do not summarize).

The point of summarization is to create scalability through abstraction. If a domain does NOT want abstraction, that’s perfectly ok. Don’t summarize. Don’t use areas. Run everything as a single flat area.

However, if a domain chooses to summarize and then generates innumerable prefixes, you will forgo abstraction and scalability. The implicit implication is that this will somehow work, when it in fact will not. Further, in the proposals that we’ve seen, the end users will not know about this until the worst possible time: a mass failure. Engineering in a catastrophic failure mode into the protocol violates the architecture and is not acceptable.

> None of this is an "architectural violation".

Hopefully, these violations of abstraction are carefully considered manual exceptions that will not explode in the end user’s face at the worst possible time.

> Sorry, I still don't understand this argument.

First off, the point is not the loss of reachability. It’s the loss of liveness.  This is key. We’re suddenly changing the roles and responsibilities of the IGP. And we’re sacrificing scalability at the same time.

> But claiming that "IGPs are not supposed to do this"??

What is it that the IGPs are supposed to do? As mentioned, liveness was not one of those things. Ever.  A node goes down in an area and now we need to signal this outside of the area? That’s a major scope creep.

> We have not added any new information to the IGP itself. We are only suggesting a new form of advertisement to signal some information already known to the IGP, but which is currently not advertise…

More specific prefixes (specifically host routes) outside of their area is certainly new information.

> [LES:] The questions of scale (as I have previously commented) are very legitimate - and more has to be specified before an IGP solution would be considered ready for deployment. But there are tool…

All of the tools that I have seen would seem to break the intended functionality if invoked. Pretty clearly, they are not a robust solution.

> I see no reason why the same tools should not be used in this case.

There is no issue with stable networks, but that’s not the issue. Our concern is to provide a stable service despite the network having a widespread failure.
The tools that are proposed would limit either the number or rate of the negative advertisements. The result is that there would NOT be rapid convergence. That’s to say that the proposed solutions really don’t do what they claim to do. Why would we intentionally defraud our users?

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 30 Nov 2021 00:22:34 +0100

Hi Greg,

The multihop BFD there is to detect PE liveness. It can travel any IGP link
in the area. The entire discussion here is about signalling PE going down.
BFD is used as one way to detect it.

Kind regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 30 Nov 2021 00:29:38 +0100

Hi Tony,

> Hopefully, these violations of abstraction are carefully considered manual
> exceptions that will not explode in the end user’s face at the worst
> possible time.
>

Actually all of the above explode immediately and that is a feature not a
bug. Once enabled if a user sees some form of network meltdown or issue it
can shut it off and modify the network.

That is why I am against ephemeral nature of the proposed mechanism. As
such this can be seen as altitude based ticking bomb just waiting to reach
the high enough flight level.

Best,
Robert

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Nov 2021 15:40:42 -0800

Hi Robert,
can you please clarify what do you mean by "liveness"?
Also, please note that BFD is not detecting the "liveness" of the remote
node. BFD, according to RFC 5880, is "intended to detect faults in the
bidirectional path between two forwarding engines, including interfaces,
data link(s), and to the extent possible the forwarding engines
themselves". Thus, RR may be detecting and reacting to failures of all
these elements that may not affect PE's role in an EVPN in any way.

Regards,
Greg

On Mon, Nov 29, 2021 at 3:22 PM Robert Raszuk <[email-masked]> wrote:

> Hi Greg,
>
> The multihop BFD there is to detect PE liveness. It can travel any IGP
> link in the area. The entire discussion here is about signalling PE going
> down. BFD is used as one way to detect it.
>
> Kind regards,
> R.
>
>
>
>> I'm catching up with the discussion and it is very likely that someone
>> has asked my question:
>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 30 Nov 2021 00:47:46 +0100

Yes .. well almost.

Depending on the connectivity restoration times in any given network vs
configured BFD timers with multihop BFD sessions we can detect the endpoint
UP -> DOWN transition.

And that is the goal here.

Thx,
R.

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Nov 2021 15:57:28 -0800

Hi Robert,
I need to stress that the state of a BFD session is not reflective of the
state of the node where the remote BFD system is located. As I understand
it, the path between RR and PE1 is not relevant to the EVPN. But it is
essential to the state of the BFD session. In my opinion, using a BFD
session between PE1 and RR is likely to produce both false negatives and
false positives. From my OAM PoV, the most reliable option is, as you've
pointed out, to run BFD over EVPN underlay between PEs. Second best -
single-hop BFD sessions between PE and its neighbors in the underlay.

Regards,
Greg

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 30 Nov 2021 01:07:52 +0100

Hi Greg,

/* Changing the subject as the other thread just tried to re-focus on IGP
*/
/* Keeping lsr WG cc-ed just as FYI */

>From my OAM PoV, the most reliable option is, as you've pointed out, to run
> BFD over EVPN underlay between PEs.
>

If BFD would have autodiscovery built in, that would indeed be the ultimate
solution. Of course folks will worry about scaling and number of BFD
sessions to be run PE-PE.

But if BFD between all PEs would be an option why RR to PE in the local
area would not be a viable solution ?

Both would be multihop, both would be subject to all transit failures etc
...

Also just FYI this discussion is not about EVPN :) Some people claimed that
the solution should not even consider BGP presence for any service.

Thx,
R.

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Nov 2021 16:22:12 -0800

Hi Robert,
great idea to spawn the new discussion thread, thank you!
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

On Mon, Nov 29, 2021 at 4:08 PM Robert Raszuk <[email-masked]> wrote:

> From my OAM PoV, the most reliable option is, as you've pointed out, to
>> run BFD over EVPN underlay between PEs.
>>
>
> If BFD would have autodiscovery built in, that would indeed be the
> ultimate solution. Of course folks will worry about scaling and number of
> BFD sessions to be run PE-PE.
>
GIM>> I sense that it is not "BFD autodiscovery" but an advertisement of
BFD multi-hop system readiness to the particular PE. That, as I think of
it, can be done in a control or management plane.

> area would not be a viable solution ?
GIM>>Because, in the case of PE-PE, BFD control packets will be
fate-sharing with data packets. But the path between RR and PE might not be
used for carrying data packets at all.

> Both would be multihop, both would be subject to all transit failures etc
GIM>> I think that there's a difference between the impact a path failure
has on the data traffic. In the case of monitoring PE-PE path in the
underlay and using the same encapsulation as data traffic is representative
of the data experience. A failure of the PE-RR path, in my understanding,
may be not representative at all. BFD session between RR and PE may fail
while PE is absolutely functional from the service PoV. On the other hand,
PE might be disconnected from the service while the BFD session to RR is in
the Up state.

>
> Also just FYI this discussion is not about EVPN :) Some people claimed
> that the solution should not even consider BGP presence for any service.
>
> Thx,
> R.
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 30 Nov 2021 01:35:01 +0100

Hi Greg,

> it, can be done in a control or management plane.

Agreed.

> used for carrying data packets at all.

100%. But that was accounted for. Reason being that you have at least
two RRs in an area. The point of BFD was to use detect that PE went down.

You are absolutely right that it may report RR disconnect from the network
while PE is up and data plane from remote PEs can reach it. That is why we
have more than one RR.

As far as fate sharing PE-PE BFD with real user data - I think it is not
always the case. But this is completely separate discussion :)

Also please keep in mind that PE going down can be learned by RRs by
listening to the IGP. No BFD needed.

> while PE is absolutely functional from the service PoV.
>

Please keep in mind that this entire discussion is not about data plane
failure end to end :)  Yes, it's pretty sad. This entire debate  is to
indicate domain wide that the IGP component on a PE went down.

No one considers data plane liveness and even as you observed data plane
encapsulation congruence. Clearly this is not a true OAM discussion.

> On the other hand, PE might be disconnected from the service while the BFD
> session to RR is in the Up state.
>

Not likely if you keep in mind that to trigger any remote action such
failure would have to happen to all RRs.

Thx a lot,
R.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 30 Nov 2021 00:39:06 +0000

Tony –

Let me try one example – see if it helps.

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 the prefixes of interest and asks the IGP vendor to support advertising reachability to the tagged prefixes in addition to the summary (even though they are covered by summary).
Are we still within the IGP set of responsibilities IYO?

Now, if the ABR so configured loses reachability to one of the tagged prefixes, what should it do?
Clearly, it needs to stop advertising reachability for that prefix. But how can this be used to achieve what the customer desires i.e., fast reaction to the loss of reachability?
One can imagine some feature that looks at history and tracks when the summary address was first advertised and when the tagged prefix covered by the summary was first advertised and try to deduce what this means if reachability to the tagged prefix is withdrawn  - but this is problematic as it depends on history.

What we propose is that if a customer wants to use summaries, they should feel free to do so. But if they want faster detection of loss of reachability to (some) destinations covered by the summary, there is a new advertisement which provides this which avoids the ambiguities mentioned above.
Again, the IGP isn’t acquiring new information – it has always known this information – it just hasn’t had a way to advertise this in the presence of summaries.
And, the use of tagging to identify the prefixes which may be advertised using the new mechanism is one way to deal with scale issues.

??

I also want to point out that we are NOT asking IGPs to detect/advertise loss of liveness. Just loss of reachability. Maybe the node associated with the prefix is down – maybe it is up but we no longer have a path to it. We are not asking the ABR to determine why it no longer has reachability.

   Les

From: Tony Li <[email-masked]> On Behalf Of Tony Li
Sent: Monday, November 29, 2021 3:22 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Hannes Gredler <[email-masked]>; Aijun Wang <[email-masked]>; Robert Raszuk <[email-masked]>; lsr <[email-masked]>; Tony Li <[email-masked]>; Shraddha Hegde <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Les,

Tony

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 29 Nov 2021 19:44:23 -0500

Robert

> two RRs in an area. The point of BFD was to use detect that PE went down.

Gyan> What Greg is alluding is a very good point to consider is that the RR
in many cases in operator networks sit in the “control plane” path which is
separate from the data plane path.  So the E2E forwarding plane path
between the PEs, the RR has no knowledge as is it sits outside the
forwarding plane path.  That being said the PE to RR path is disjoint from
the PE-PE path so from the PE-RR  RR POV may think the PE is up or down
thus the false positive or negative. That would be the case regardless of
how many RRs are deployed.

>> On the other hand, PE might be disconnected from the service while the
>> BFD session to RR is in the Up state.
>>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 29 Nov 2021 19:48:36 -0500

On Mon, Nov 29, 2021 at 7:44 PM Gyan Mishra <[email-masked]> wrote:

> Gyan> What Greg is alluding is a very good point to consider is that the
> RR in many cases in operator networks sit in the “control plane” path which
> is separate from the data plane path.  So the E2E forwarding plane path

    Gyan> The RR being mutually exclusive of the forwarding plane is on
purpose as  you very well know you don’t want to ever have traffic flow
accidentally forwarding through an RR as is not meant to forward traffic
due to different platform type which could be a NFV software box or
physical but made to handle control plan traffic not data plane traffic.

>
>> You are absolutely right that it may report RR disconnect from the
>> network while PE is up and data plane from remote PEs can reach it. That is
>> why we have more than one RR.
>>
>>> Both would be multihop, both would be subject to all transit failures
>>>> etc ...
>>>>
>>> GIM>> I think that there's a difference between the impact a path
>>> failure has on the data traffic. In the case of monitoring PE-PE path in
>>> the underlay and using the same encapsulation as data traffic is
>>> representative of the data experience. A failure of the PE-RR path, in my
>>> understanding, may be not representative at all. BFD session between RR and
>>> PE may fail while PE is absolutely functional from the service PoV.
>>>
>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 29 Nov 2021 20:11:13 -0500

Robert

**Top posting here**

So as the RR sits in the control plane completely disjoint from the
forwarding plane, as far as a BGP base solution detection of liveliness PE
down detection,  this will yield false positive or negative and thus I
don’t think is a viable alternative to IGP based solution.

I agree if RR are not deployed or the RR is a PE or P box sitting in the
forwarding plane then your BGP solution is viable.

Many Thanks,

Gyan
On Mon, Nov 29, 2021 at 7:48 PM Gyan Mishra <[email-masked]> wrote:

>>>> GIM>> I sense that it is not "BFD autodiscovery" but an advertisement
>>>> of BFD multi-hop system readiness to the particular PE. That, as I think of

*Gyan Mishra*

*M 301 502-1347*

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 30 Nov 2021 09:16:57 +0800

>From the discussion, I think we can get the conclusion that BFD based detection for the mentioned problem is not reliable (between PE/RR) and scalable(among PEs).

Then also the BGP based solution.

So let’s focus how to implement it within the IGP?  Thanks Greg’s analysis.

And one supplement for Robert’s comments: RR is always not located within the same area as PEs, then can’t know the down of PE nodes immediately when the summary is configured between areas.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Gyan Mishra
Sent: Tuesday, November 30, 2021 8:44 AM
To: Robert Raszuk <[email-masked]>
Cc: Greg Mirsky <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] BFD aspects

Robert 

On Mon, Nov 29, 2021 at 7:35 PM Robert Raszuk <[email-masked] <mailto:[email-masked]> > wrote:

Hi Greg,

If BFD would have autodiscovery built in, that would indeed be the ultimate solution. Of course folks will worry about scaling and number of BFD sessions to be run PE-PE. 

GIM>> I sense that it is not "BFD autodiscovery" but an advertisement of BFD multi-hop system readiness to the particular PE. That, as I think of it, can be done in a control or management plane.

Agreed. 

But if BFD between all PEs would be an option why RR to PE in the local area would not be a viable solution ? 

GIM>>Because, in the case of PE-PE, BFD control packets will be fate-sharing with data packets. But the path between RR and PE might not be used for carrying data packets at all.

100%. But that was accounted for. Reason being that you have at least two RRs in an area. The point of BFD was to use detect that PE went down. 

Gyan> What Greg is alluding is a very good point to consider is that the RR in many cases in operator networks sit in the “control plane” path which is separate from the data plane path.  So the E2E forwarding plane path between the PEs, the RR has no knowledge as is it sits outside the forwarding plane path.  That being said the PE to RR path is disjoint from the PE-PE path so from the PE-RR  RR POV may think the PE is up or down thus the false positive or negative. That would be the case regardless of how many RRs are deployed.

You are absolutely right that it may report RR disconnect from the network while PE is up and data plane from remote PEs can reach it. That is why we have more than one RR. 

As far as fate sharing PE-PE BFD with real user data - I think it is not always the case. But this is completely separate discussion :) 

Also please keep in mind that PE going down can be learned by RRs by listening to the IGP. No BFD needed. 

Both would be multihop, both would be subject to all transit failures etc ... 

GIM>> I think that there's a difference between the impact a path failure has on the data traffic. In the case of monitoring PE-PE path in the underlay and using the same encapsulation as data traffic is representative of the data experience. A failure of the PE-RR path, in my understanding, may be not representative at all. BFD session between RR and PE may fail while PE is absolutely functional from the service PoV. 

Please keep in mind that this entire discussion is not about data plane failure end to end :)  Yes, it's pretty sad. This entire debate  is to indicate domain wide that the IGP component on a PE went down. 

No one considers data plane liveness and even as you observed data plane encapsulation congruence. Clearly this is not a true OAM discussion. 

On the other hand, PE might be disconnected from the service while the BFD session to RR is in the Up state.

Not likely if you keep in mind that to trigger any remote action such failure would have to happen to all RRs. 

Thx a lot,
R.

-- 

Gyan Mishra

M 301 502-1347

---

From: Tony Li <[email-masked]>
Date: Mon, 29 Nov 2021 18:08:51 -0800

Les,

> Are we still within the IGP set of responsibilities IYO?

IMHO, no.

You’re intentionally breaking summarization and advertising liveness.  You can claim that it’s just reachability, but it’s not.  If it were reachability, then you’d be ok with a static prefix assignment.

> Clearly, it needs to stop advertising reachability for that prefix.

No, it doesn’t. Static summarization is the preferred approach.  It’s stable.  

You may recall back in the ‘90s that we did dynamic advertisement and withdrawl in BGP.  That quickly got frowned on because of the resulting churn.  No different here.

> Again, the IGP isn’t acquiring new information – it has always known this information – it just hasn’t had a way to advertise this in the presence of summaries.

You’re propagating new information out of the area. And doing so at the wrong time.  I would MUCH rather just leak the prefixes when things are working than add stress in failure modes.

> And, the use of tagging to identify the prefixes which may be advertised using the new mechanism is one way to deal with scale issues.

How? If there are 10,000 tagged prefixes, how does that not become 10,000 negative leaks?

Tony

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Nov 2021 18:17:53 -0800

Hi Aijun,
could you please elaborate on how you see that this discussion leads to the
"BFD based detection for the mentioned problem is not [...] scalable(among
PEs)" conclusion? I hope that there's nothing I've said or suggested lead
you to this conclusion. Personally, I believe that BFD-based PE-PE is the
best technical solution. I understand that an operator may be dissatisfied
with the additional configuration of the BFD session. As noted, I believe
that can be addressed in the management plane or minor extensions in the
control plane (BGP or not). If a particular implementation (or a
combination of the implementation and HW) has a scaling challenge with
multi-hop BFD, then that could be not enough sufficient
technical justification for a somewhat controversial proposal.

Regards,
Greg

On Mon, Nov 29, 2021 at 5:17 PM Aijun Wang <[email-masked]>
wrote:

> From the discussion, I think we can get the conclusion that BFD based
> detection for the mentioned problem is not reliable (between PE/RR) and
> scalable(among PEs).
>
> And one supplement for Robert’s comments: RR is always not located within
> the same area as PEs, then can’t know the down of PE nodes immediately when
> the summary is configured between areas.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *Gyan
> Mishra
> *Sent:* Tuesday, November 30, 2021 8:44 AM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* Greg Mirsky <[email-masked]>; lsr <[email-masked]>
> *Subject:* Re: [Lsr] BFD aspects
>
>
>
>
>
> Robert
>
>
>

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 30 Nov 2021 10:26:24 +0800

Hi, Greg:

Firstly, regardless of which methods to be used for the multihop BFD approach, it is certainly the configuration overhead if you image there are 10,000 PEs as Tony often raised as one example. 

Shouldn’t you configure each pair of them to detect the PE-PE connection?

It is obvious not scalable.

Best Regards

Aijun Wang

China Telecom

From: Greg Mirsky <[email-masked]> 
Sent: Tuesday, November 30, 2021 10:18 AM
To: Aijun Wang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Robert Raszuk <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] BFD aspects

Hi Aijun,

could you please elaborate on how you see that this discussion leads to the "BFD based detection for the mentioned problem is not [...] scalable(among PEs)" conclusion? I hope that there's nothing I've said or suggested lead you to this conclusion. Personally, I believe that BFD-based PE-PE is the best technical solution. I understand that an operator may be dissatisfied with the additional configuration of the BFD session. As noted, I believe that can be addressed in the management plane or minor extensions in the control plane (BGP or not). If a particular implementation (or a combination of the implementation and HW) has a scaling challenge with multi-hop BFD, then that could be not enough sufficient technical justification for a somewhat controversial proposal.

Regards,

Greg

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Gyan Mishra
Sent: Tuesday, November 30, 2021 8:44 AM
To: Robert Raszuk <[email-masked] <mailto:[email-masked]> >
Cc: Greg Mirsky <[email-masked] <mailto:[email-masked]> >; lsr <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] BFD aspects

Robert 

Hi Greg,

Agreed. 

Thx a lot,
R.

-- 

Gyan Mishra

M 301 502-1347

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Nov 2021 18:47:17 -0800

Hi Aijun,
thank you for confirming that it is not the conclusion one can arrive based
on my discussion with Robert. Secondly, the problem you describe, I
wouldn't characterize as a scaling issue with using multi-hop BFD
monitoring path continuity in the underlay network. In my opinion, it is an
operational overhead that can be addressed by an intelligent management
plane or a few extensions in the control plane that is setting an overlay.
Since the management plane is usually a proprietary solution, I invite
anyone interested in working on BFD auto-configuration extensions in the
control plane. I much appreciate references to the use cases that can
benefit from such extensions.

Regards,
Greg

On Mon, Nov 29, 2021 at 6:26 PM Aijun Wang <[email-masked]>
wrote:

> Hi, Greg:
>
>
>
> Firstly, regardless of which methods to be used for the multihop BFD
> approach, it is certainly the configuration overhead if you image there are
> 10,000 PEs as Tony often raised as one example.
>
> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Tuesday, November 30, 2021 10:18 AM
> *Cc:* Gyan Mishra <[email-masked]>; Robert Raszuk <
> [email-masked]>; lsr <[email-masked]>
> could you please elaborate on how you see that this discussion leads to
> the "BFD based detection for the mentioned problem is not [...]
> scalable(among PEs)" conclusion? I hope that there's nothing I've said or
> suggested lead you to this conclusion. Personally, I believe that BFD-based
> PE-PE is the best technical solution. I understand that an operator may be
> dissatisfied with the additional configuration of the BFD session. As
> noted, I believe that can be addressed in the management plane or minor
> extensions in the control plane (BGP or not). If a particular
> implementation (or a combination of the implementation and HW) has a
> scaling challenge with multi-hop BFD, then that could be not enough
> sufficient technical justification for a somewhat controversial proposal.
>
>
>
> Regards,
>
> Greg
>
>
>
> the same area as PEs, then can’t know the down of PE nodes immediately
> when the summary is configured between areas.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> RR in many cases in operator networks sit in the “control plane” path
> which is separate from the data plane path.  So the E2E forwarding plane
> path between the PEs, the RR has no knowledge as is it sits outside the

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 29 Nov 2021 21:52:01 -0500

Hi Greg

I think the bigger issue not related to use of multi hop BFD and BFD
scalability as that is all done in hardware and most vendors can support
the high number of sessions.

The bigger issue is the viability of using BGP to detect the remote PE down
events and false positive and negative due to RR sitting outside of the
forwarding plane topology which is a requirement for operators since the RR
platform is made for control plane scale and not high line rate data plane
forwarding scale as the PE & P nodes.  This is the typical SP core
architecture that the RR sits separate from the forwarding plane for the
separation of control plane and data plane framework which is also inherent
to MVPN, EVPN control plane  procedures as well.

Many Thanks

Gyan

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 29 Nov 2021 21:57:46 -0500

Hi Greg

Is there any advantage for operators to run multi hop BFD PE-RR BGP client
versus single hop BFD for IGP P2P clients which is typically done.  Also
any issues with running both above simultaneously also any benefit in doing
so.

Many Thanks

Gyan

On Mon, Nov 29, 2021 at 9:47 PM Greg Mirsky <[email-masked]> wrote:

> Hi Aijun,
> thank you for confirming that it is not the conclusion one can arrive
> based on my discussion with Robert. Secondly, the problem you describe, I
>> And one supplement for Robert’s comments: RR is always not located
>> within the same area as PEs, then can’t know the down of PE nodes
>> immediately when the summary is configured between areas.
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>

*Gyan Mishra*

*M 301 502-1347*

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 30 Nov 2021 11:07:09 +0800

Hi, Greg:

Even the BFD auto-configuration extensions has been standardized and implemented, won’t the network be filled with the detect packets, instead of the user packets?

For PUA/PULSE solution, the mentioned LSA will only be emerged when the node status change from “UP” to “DOWN”, but the BFD packet will be sent continuously when these PEs are active. 

Which one is efficient?

Certainly, we will consider the massive failure situations, even it will occur in very rare circumstances.

Best Regards

Aijun Wang

China Telecom

From: Greg Mirsky <[email-masked]> 
Sent: Tuesday, November 30, 2021 10:47 AM
To: Aijun Wang <[email-masked]>
Cc: lsr <[email-masked]>; Gyan Mishra <[email-masked]>; Robert Raszuk <[email-masked]>
Subject: Re: [Lsr] BFD aspects

Hi Aijun,

thank you for confirming that it is not the conclusion one can arrive based on my discussion with Robert. Secondly, the problem you describe, I wouldn't characterize as a scaling issue with using multi-hop BFD monitoring path continuity in the underlay network. In my opinion, it is an operational overhead that can be addressed by an intelligent management plane or a few extensions in the control plane that is setting an overlay. Since the management plane is usually a proprietary solution, I invite anyone interested in working on BFD auto-configuration extensions in the control plane. I much appreciate references to the use cases that can benefit from such extensions.

Regards,

Greg

On Mon, Nov 29, 2021 at 6:26 PM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Greg:

 

Best Regards

Aijun Wang

China Telecom

From: Greg Mirsky <[email-masked] <mailto:[email-masked]> > 
Sent: Tuesday, November 30, 2021 10:18 AM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: Gyan Mishra <[email-masked] <mailto:[email-masked]> >; Robert Raszuk <[email-masked] <mailto:[email-masked]> >; lsr <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] BFD aspects

Hi Aijun,

Regards,

Greg

Best Regards

Aijun Wang

China Telecom

 

Robert 

Hi Greg,

Agreed. 

Thx a lot,
R.

-- 

Gyan Mishra

M 301 502-1347

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Nov 2021 19:08:53 -0800

Hi Gyan,
thank you for pointing out the possible confusion I've caused by not being
clear about which option of using the multi-hop BFD I propose to advance
and support with auto-configuration. It is PE-PE, not the PE-RR option
(using Robert's original email). I see the multi-hop BFD between PEs as the
natural solution to the problem of achieving faster service (overlay)
convergence.
What do you think?

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Nov 2021 19:10:40 -0800

Hi Aijun,
what is the guaranteed failure detection time for the IGP-based solution?

Regards,
Greg

On Mon, Nov 29, 2021 at 7:07 PM Aijun Wang <[email-masked]>
wrote:

> Hi, Greg:
>
>
>
> Even the BFD auto-configuration extensions has been standardized and
> implemented, won’t the network be filled with the detect packets, instead
> of the user packets?
>
> For PUA/PULSE solution, the mentioned LSA will only be emerged when the
> node status change from “UP” to “DOWN”, but the BFD packet will be sent
> continuously when these PEs are active.
>
> Which one is efficient?
>
>
>
> *Sent:* Tuesday, November 30, 2021 10:47 AM
> *Cc:* lsr <[email-masked]>; Gyan Mishra <[email-masked]>; Robert
> Raszuk <[email-masked]>

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 30 Nov 2021 11:38:10 +0800

Hi, Greg:

I understand that BFD can get the guaranteed failure detection time than other protocol that depends on the size of the network.

What we want to emphasize is that the balance of deployment/operation overhead and the efficiency of the proposed solutions.

For your questions, I think we can still get the millisecond failure detection time via the IGP itself(Far faster than the BGP hello timer for BGP use case; and also benefit for the tunnel services that has no hello timer).

The actual time should certainly be verified later in simulation environment or in real network deployment.

Best Regards

Aijun Wang

China Telecom

Sent: Tuesday, November 30, 2021 11:11 AM

Hi Aijun,

Regards,

Greg

On Mon, Nov 29, 2021 at 7:07 PM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Greg:

Which one is efficient?

Best Regards

Aijun Wang

China Telecom

Cc: lsr <[email-masked] <mailto:[email-masked]> >; Gyan Mishra <[email-masked] <mailto:[email-masked]> >; Robert Raszuk <[email-masked] <mailto:[email-masked]> >

Hi Aijun,

Regards,

Greg

Hi, Greg:

 

Best Regards

Aijun Wang

China Telecom

Hi Aijun,

Regards,

Greg

Best Regards

Aijun Wang

China Telecom

 

Robert 

Hi Greg,

Agreed. 

Thx a lot,
R.

-- 

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 29 Nov 2021 23:02:22 -0500

Tony

On Mon, Nov 29, 2021 at 9:09 PM Tony Li <[email-masked]> wrote:

> 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 the prefixes of interest and asks the IGP
> vendor to support advertising reachability to the tagged prefixes in
> addition to the summary (even though they are covered by summary).
> You’re intentionally breaking summarization and advertising liveness.  You
> can claim that it’s just reachability, but it’s not.  If it were
> reachability, then you’d be ok with a static prefix assignment.
>

Gyan> This is a nice link that gives the historical definition of
liveliness from an IT perspective.

https://liveness.com/#free

When you think of liveliness you think of BFD data path bidirectional
liveliness detection or PM in-situ OAM telemetry.  In this case with
PUA/PULSE is routing information and it’s the LPM component prefixes we are
tracking reachability of those specific prefixes.  So it’s at the LPM
prefix level that we are tracking of events.  What may have caused
confusion is talk about remote PE down tracking but all that we are
tracking is not the liveliness of the PE but the actual LPM loopback of the
PE which is the next hop for the service overlay routes.  Hope this helps.

Many Thanks!

> You may recall back in the ‘90s that we did dynamic advertisement and
> withdrawl in BGP.  That quickly got frowned on because of the resulting
> churn.  No different here.
>
>
> What we propose is that if a customer wants to use summaries, they should
> feel free to do so. But if they want faster detection of loss of
> reachability to (some) destinations covered by the summary, there is a new
> advertisement which provides this which avoids the ambiguities mentioned
> above.
> Again, the IGP isn’t acquiring new information – it has always known this
> information – it just hasn’t had a way to advertise this in the presence of
> summaries.
>
>
>
> You’re propagating new information out of the area. And doing so at the
> wrong time.  I would MUCH rather just leak the prefixes when things are
> working than add stress in failure modes.
>
>
> And, the use of tagging to identify the prefixes which may be advertised
> using the new mechanism is one way to deal with scale issues.
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Nov 2021 20:07:54 -0800

Hi Aijun,
thank you for clarifying your goal. I have missed asking another question:

What is the required failure detection time?

For example, a 10 ms detection guarantee is required for local protection.
And that results in a 3.3 ms interval between the fault detection packets
(e.g., CCM or BFD). As I understand it, IGP is likely to rely on single-hop
BFD detection. Hence, 10 ms before PE's neighbor discovers the failure.
Then the IGP processes will start acting. Thus, I don't see how IGP can
guarantee anything less than 10 ms. Would you agree?

Regards,
Greg

On Mon, Nov 29, 2021 at 7:38 PM Aijun Wang <[email-masked]>
wrote:

> Hi, Greg:
>
>
>
> I understand that BFD can get the guaranteed failure detection time than
> other protocol that depends on the size of the network.
>
> What we want to emphasize is that the balance of deployment/operation
> overhead and the efficiency of the proposed solutions.
>
> For your questions, I think we can still get the millisecond failure
> detection time via the IGP itself(Far faster than the BGP hello timer for
> BGP use case; and also benefit for the tunnel services that has no hello
> timer).
>
> The actual time should certainly be verified later in simulation
> environment or in real network deployment.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *Sent:* Tuesday, November 30, 2021 11:11 AM

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 29 Nov 2021 23:19:06 -0500

Tony

On Mon, Nov 29, 2021 at 11:02 PM Gyan Mishra <[email-masked]> wrote:

>> You’re intentionally breaking summarization and advertising liveness.
>> You can claim that it’s just reachability, but it’s not.  If it were
Gyan> Sorry I meant to use the word “continuity” - When you think of
liveliness  you think of BFD data path bidirectional “continuity” detection
or PM in-situ OAM telemetry.

*Gyan Mishra*

*M 301 502-1347*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 30 Nov 2021 05:51:30 +0000

Tony –

I am not convinced we are going to converge.
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 now less optimistic about that being achievable.
Still, a few responses inline.

From: Tony Li <[email-masked]> On Behalf Of Tony Li
Sent: Monday, November 29, 2021 6:09 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Hannes Gredler <[email-masked]>; Aijun Wang <[email-masked]>; Robert Raszuk <[email-masked]>; lsr <[email-masked]>; Shraddha Hegde <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Les,

IMHO, no.

[LES:] Your response mystifies me. I do not know how “static prefix assignment” is relevant. I wasn’t proposing “dynamic prefix assignment”.
I was just trying to illustrate that prefixes covered by the summary could be advertised using existing IGP advertisements even when the summary is being advertised.
It is still reachability. The determination of when to advertise the prefix and when not to is still based upon whether the ABR has a path to the prefix based on latest SPF calculation.

You choose to rename such an advertisement as “liveness” rather than “reachability” for no reason that I can see. It then allows you claim an “architectural violation” – but this to me is a meaningless distraction.
I was hoping to get rid of this distraction – but no such luck I see.

[LES:] This wasn’t the point of the example. I wasn’t promoting the example as desirable deployment choice. I was only illustrating that it is the change in reachability(sic) that is the event. With current IGP advertisements we would (of course) stop advertising reachability when we do not have a path to a given prefix. The new advertisements propose to advertise the loss of reachability to destinations which are covered by a summary. That has advantages over a withdrawal (the absence of an advertisement).

If you want to say that an operator should only have two choices:
a)Advertise a summary or
b)Advertise all reachable prefixes covered by a summary

I understand your POV even if I do not agree with it.
But please do not obfuscate things by claiming a reachability advertisement is now something else when it is triggered by the same event i.e., a change in the reachability to a given destination.

[LES:] This is one of many possible tools to address scaling issues. (I have previously suggested others) Clearly this is only of benefit if, in a given deployment, the number of prefixes for which loss of reachability notifications is desired is modest and/or if used in conjunction w other tools.
Please do not twist my words.

   Les

Tony

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 30 Nov 2021 14:49:12 +0800

Hi, Greg:

I agree with you that BFD has good performance than other failure detection mechanism, but we should also consider the scalability of the solutions.

And, can the 10ms be guaranteed for multi-hop BFD in any network? I think there is also the number of BFD sessions limit on each device.

Best Regards

Aijun Wang

China Telecom

Sent: Tuesday, November 30, 2021 12:08 PM

Hi Aijun,

For example, a 10 ms detection guarantee is required for local protection. And that results in a 3.3 ms interval between the fault detection packets (e.g., CCM or BFD). As I understand it, IGP is likely to rely on single-hop BFD detection. Hence, 10 ms before PE's neighbor discovers the failure. Then the IGP processes will start acting. Thus, I don't see how IGP can guarantee anything less than 10 ms. Would you agree?

Regards,

Greg

On Mon, Nov 29, 2021 at 7:38 PM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Greg:

Best Regards

Aijun Wang

China Telecom

Hi Aijun,

Regards,

Greg

Hi, Greg:

Which one is efficient?

Best Regards

Aijun Wang

China Telecom

Hi Aijun,

Regards,

Greg

Hi, Greg:

 

Best Regards

Aijun Wang

China Telecom

Hi Aijun,

Regards,

Greg

Best Regards

Aijun Wang

China Telecom

 

Robert 

Hi Greg,

Agreed. 

Thx a lot,
R.

-- 

Gyan Mishra

M 301 502-1347

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 30 Nov 2021 15:22:21 +0800

Hi, Tony:

I agree with Les, that PUA/PULSE is one kind of tools to address the scaling issue.

One responses for your following comments:

“You’re propagating new information out of the area. And doing so at the wrong time.  I would MUCH rather just leak the prefixes when things are working than add stress in failure modes.”

I think the above statement should be the followings:

  We are propagating the same information out of the area (as Les said, just tag the prefixes), And doing so at the right time (when the node can’t provide the service). Such information is useful for the PE node(for BGP overlay service) and P nodes(for tunnels service), It can relieves the nodes from service interruption stress in failure modes.

And, we have compared several possible solutions(BGP based, or BFD based), isn’t the IGP based most efficient?

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, November 30, 2021 1:52 PM
To: Tony Li <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Aijun Wang <[email-masked]>; Shraddha Hegde <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Tony –

From: Tony Li <[email-masked] <mailto:[email-masked]> > On Behalf Of Tony Li
Sent: Monday, November 29, 2021 6:09 PM
To: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> >
Cc: Hannes Gredler <[email-masked] <mailto:[email-masked]> >; Aijun Wang <[email-masked] <mailto:[email-masked]> >; Robert Raszuk <[email-masked] <mailto:[email-masked]> >; lsr <[email-masked] <mailto:[email-masked]> >; Shraddha Hegde <[email-masked] <mailto:[email-masked]> >; Peter Psenak (ppsenak) <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] BGP vs PUA/PULSE

Les,

 

IMHO, no.

 

 

a)Advertise a summary or

 

 

 

 

 

   Les

Tony

---

From: Peter Psenak <[email-masked]>
Date: Tue, 30 Nov 2021 09:40:25 +0100

Robert,

> proposed an alternative).

LSPs have their age today. One can generate LSP with the lifetime of 1 
min. Protocol already allows that. So you are "not ok" with what 
protocol allows already. I'm fine if that's your position, but making 
that an argument against the proposal is not correct IMHO.

> P and PE routers which do not need it.

Today in all MPLS networks host routes from all areas are "spread" 
everywhere including all P and PE routers, that's how LS protocols 
distribute data, we have no other way to do that in LS IGPs.

Summarization with what we propose reduces the "spread" significantly. 
And we cam easily address the "mass failures", so we will never generate 
as many pulses as we have host routes today. If you still don't like it, 
fine, but arguing that the existing distribution method in IGP is 
incorrect is not a valid argument IMHO.

> 
> #3 - 1 days ago you said: "The legitimate question is whether folks see 
> it as appropriate to have an IGP based solution for the problem." So 
> bringing a BGP alternative seems to be very much in line with your 
> guidance for this thread. >
> info to every IGP node. The fact that it was pushed through IETF with 
> brute force does not make it a great protocol evolution. Maybe now it is 
> time to close that gate ?

same as (2).

thanks,
Peter
> 
> Kind regards,
> Robert
> 
> 
>     [LES:] BGP-LS only advertises what the IGPs themselves advertise. ____
> 
>     In this case, both IGP proposals involve ephemeral advertisements -
>     so even if we were to define BGP-LS support for these new
>     advertisements - they wouldn't persist long enough to be reflected
>     in BGP-LS.____
> 
>     So, I really don’t know why we are discussing BGP-LS in the context
>     of this thread.____
> 
>     (This seems to be one example of what Acee correctly identified as
>     this discussion going "off track".)____
> 
> 
>     discussion. That is a work in progress. 😊____
> 
>     However, when you say IGPs are (exclusively?) for topology discovery
>     - it seems to suggest that IGP shouldn’t be advertising prefix
>     reachability at all. Hopefully, that is not what you intend.____
> 
>     __ __
> 
>     architectural violation in the IGP proposals.____
> 
>     __ __
> 
>     It is OK for IGPs to advertise all prefixes covered by a summary
>     (i.e., do not summarize).____
> 
>     It is OK for IGPs to advertise multiple summaries (e.g., multiple
>     /24s instead of a single /16).____
> 
>     It is even OK for IGPs to advertise some prefixes covered by a
>     summary along with the summary (don’t know if any implementations do
>     this - but they could).____
> 
>     None of this is an "architectural violation".____
> 
>     __ __
> 
>     But advertising a summary and signaling the loss of reachability to
>     a specific prefix covered by the summary is seen by some as an
>     architectural violation.____
> 
>     Sorry, I still don't understand this argument.____
> 
>     __ __
> 
>     properties (more on that below). You can question the effectiveness
>     of ephemeral advertisements.____
> 
>     These kinds of objections/concerns I can easily understand - even if
>     we don’t agree on their significance.____
> 
>     But claiming that "IGPs are not supposed to do this"??____
> 
>     Not grokking this.____
> 
>     __ __
> 
>     suggesting a new form of advertisement to signal some information
>     already known to the IGP, but which is currently not advertised (in
>     some deployments) by the configuration of summaries.____
> 
>     [LES:] The questions of scale (as I have previously commented) are
>     very legitimate - and more has to be specified before an IGP
>     solution would be considered ready for deployment. But there are
>     tools easily applicable to address this (rate limiting, embedded
>     summarization, perhaps others).
> 
>     The more significant point is to focus on the goal - which in this
>     usage is improved convergence time.____
> 
>     When the network is largely stable, convergence improvements can be
>     achieved w/o risk.____
> 
>     unlikely to provide improved convergence - which is why the IGPs
>     today shift the focus from convergence to stability by slowing down
>     the rate of updates sent and SPFs performed. This is STILL true even
>     in the fast convergence/FRR era.____
> 
>     I see no reason why the same tools should not be used in this case.____
> 
>     __ __
> 
>         Les
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 30 Nov 2021 10:11:24 +0100

Greg,

Thank you so much for your input to this discussion. As you can see it is
not easy to convince some folks :)

I just want to clarify one thing in respect to using multihop BFD between
RR and PE. There is nothing about data plane path detection with that
suggestion. Basically BFD is used here as a better ping. No more no less.

Few points:

#1 - Yes, if my control plane RR-PE network fails and the normal data plane
to PE is still up I will have a false positive. Solution: Use more than one
RR.

#2 - Yes BFD process liveness or not on PE does not guarantee service
liveness of the PE - that is always true as BFD does not check real service
data plane processing anyway

#3 - If my network to PE fails but RR-PE works fine PE will be considered
alive. Network down detection is not the goal for discussing PUA/PULSE.

Cheers,
R.

On Tue, Nov 30, 2021 at 5:08 AM Greg Mirsky <[email-masked]> wrote:

>> implemented, won’t the network be filled with the detect packets,
>> instead of the user packets?
>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 30 Nov 2021 10:29:01 +0100

Les,

*I was just trying to illustrate that prefixes covered by the summary could
> be advertised using existing IGP advertisements even when the summary is
> being advertised. **It is still reachability. The determination of when
> to advertise the prefix and when not to is still based upon whether the ABR
> has a path to the prefix based on latest SPF calculation.*
>
>
>
> *You choose to rename such an advertisement as “liveness” rather than
> “reachability” for no reason that I can see. It then allows you claim an
> “architectural violation” – but this to me is a meaningless distraction. **I
> was hoping to get rid of this distraction – but no such luck I see.*
>

You are correct that from ABR it may look like atomic reachability.

But if you look at the bigger picture what triggers this reachability is
liveness detection between P and PE routers.

And I guess what really matters is not how we call it - what matters is
what truly triggers our protocol actions.

*[LES:] This wasn’t the point of the example. I wasn’t promoting the
> example as desirable deployment choice. I was only illustrating that it is
> the change in reachability(sic) that is the event. With current IGP
> advertisements we would (of course) stop advertising reachability when we
> do not have a path to a given prefix. The new advertisements propose to
> advertise the loss of reachability to destinations which are covered by a
> summary. That has advantages over a withdrawal (the absence of an
> advertisement).*
>

Perhaps. But it also has huge complexity on the clients (src PEs) which now
need to bend to use this info. Something which is not in RIB disappears. I
recall when you worked on RIB architecture one of the basic primitives was
to always communicate protocol to protocol via RIB. Here we are talking
about some not so elegant shortcuts. And not only in respect to protocols.
Also touching FIB.

It is perhaps the vendor's secret sauce how you use this new info. But by
all means this is not what is today well known operational monitoring
practice.

That is why the ephemeral nature of the proposed advertisements is IMO its
disadvantage.

Thank you,
R.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 30 Nov 2021 10:48:19 +0100

Robert,

On 30/11/2021 10:29, Robert Raszuk wrote:
> Les,
> 
>     */I was just trying to illustrate that prefixes covered by the
>     summary could be advertised using existing IGP advertisements even
>     when the summary is being advertised. /**/It is still reachability.
>     The determination of when to advertise the prefix and when not to is
>     still based upon whether the ABR has a path to the prefix based on
>     latest SPF calculation./*
> 
>     */__ __/*
> 
>     */You choose to rename such an advertisement as “liveness” rather
>     than “reachability” for no reason that I can see. It then allows you
>     claim an “architectural violation” – but this to me is a meaningless
>     distraction. /**/I was hoping to get rid of this distraction – but
>     no such luck I see./*
> 
> 
>     */[LES:] This wasn’t the point of the example. I wasn’t promoting
>     the example as desirable deployment choice. I was only illustrating
>     that it is the change in reachability(sic) that is the event. With
>     current IGP advertisements we would (of course) stop advertising
>     reachability when we do not have a path to a given prefix. The new
>     advertisements propose to advertise the loss of reachability to
>     destinations which are covered by a summary. That has advantages
>     over a withdrawal (the absence of an advertisement)./*
> 
> 
> Perhaps. But it also has huge complexity on the clients (src PEs) which 
> now need to bend to use this info. Something which is not in RIB 
> disappears. I recall when you worked on RIB architecture one of the 
> basic primitives was to always communicate protocol to protocol via RIB. 
> Here we are talking about some not so elegant shortcuts. And not only in 
> respect to protocols. Also touching FIB.

we have done the prototype. The changes to consume the pulse and trigger 
the BGP PIC were very small and simple.

> 
> It is perhaps the vendor's secret sauce how you use this new info. But 
> by all means this is not what is today well known operational monitoring 
> practice.

that does not make it wrong, does it?

thanks,
Peter

> 
> That is why the ephemeral nature of the proposed advertisements is IMO 
> its disadvantage.
> 
> Thank you,
> R.
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 30 Nov 2021 12:40:32 +0100

Hey Peter,

> min. Protocol already allows that.

That's a pretty clever comparison indeed. I had a feeling it will come up
here and here you go :)

But I am afraid this is not comparing apple to apples.

In LSPs or LSA flooding you have a bunch of mechanisms to make sure the
information stays fresh
and does not time out. And the default refresh in ISIS if I recall was
something like 15 minutes ?

> distribute data, we have no other way to do that in LS IGPs.

Can't you run OSPF over GRE ? For ISIS Henk had proposal not so long ago to
run it over TCP too.
https://datatracker.ietf.org/doc/html/draft-hsmit-lsr-isis-flooding-over-tcp-00

Seems like a perfect fit !

Thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 30 Nov 2021 13:15:04 +0100

Hi Robert,

On 30/11/2021 12:40, Robert Raszuk wrote:
> That's a pretty clever comparison indeed. I had a feeling it will come 
> up here and here you go :)
> 

yes, default refresh is 900 for the default lifetime of 1200 sec. Most 
people change both to much larger values.

If I send the LSP with the lifetime of 1 min, there will never be any 
refresh of it. It will last 1 min and then will be purged and removed 
from the database. The only difference with the Pulse LSP is that it is 
not purged to avoid additional flooding.

> Can't you run OSPF over GRE ? For ISIS Henk had proposal not so long ago 
> to run it over TCP too.

you can run anything over GRE, including IGPs, and you don't need TCP 
transport for that. I don't see the relevance here. Are you suggesting 
to create GRE tunnels to all PEs that need the pulses? Nah, that would 
be an ugly requirement.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 30 Nov 2021 13:26:46 +0100

> to create GRE tunnels to all PEs that need the pulses? Nah, that would

Well I am not talking about PE-PE anything here. I am talking about
interested PEs setting such directed IGP sessions to ABRs who have the
information. And that can be just your local area ABRs if those will in
turn create similar sessions to "other side" area0 ABRs - endorsing
hierarchical design. Or it can be target area ABRs too. After all, the
number of ABRs in any network is usually not big.

Now obviously it would be pretty stupid to request anyone to do it by
confguration (regardless if this would be manual or automated). However,
injecting info indicating that capability of ABR in a given area and
allowing to simply apply encapsulation from PE to ABR with zero cfg seems
to be pretty trivial to accomplish.

And the reason I mentioned TCP was to avoid such encap.

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 30 Nov 2021 14:09:36 +0100

Hi,

The current PUA/PULSE discussion is aiming for letting the ingress PEs know
about egress PE failures. Alternatives to IGP domian wide flooding has been
discussed on other threads.

But I would like to bring to your attention a different point.

Imagine I am an ingress PE and have N paths for multi homed service to two
or more egress PEs.

>From pure operational POV my services and customers would be much more
efficient if I not only know if the remote egress PEs are up or down, but
also how busy those egress PEs are. Maybe one is at 90% fabric or queuing
utilization for the last 1h while guy next to it is just 5% of the same
metric as no one is selecting him as service best path.

Of course I see everyone (including myself) jumping that while very useful
this is not the role of IGP to communicate such data around. Well yes you
are right.

But the point is that if we want to build a bit more efficient and
intelligent WAN networks (just like SDWAN has done so already) we need such
additional information to be distributed irrespective of the underlay
routing.

And if we all agree with that then PUA/PULSE fit very nicely there too !

And if we continue to try to solve little point fixes/elements without
looking end to end especially without holistic view on what network role is
the outcome will be rather poor

Cheers,
Robert

---

From: Tony Li <[email-masked]>
Date: Tue, 30 Nov 2021 08:13:46 -0800

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 now less opt…

I think that we have achieved clarity. :-)

> [LES:] Your response mystifies me. I do not know how “static prefix assignment” is relevant. I wasn’t proposing “dynamic prefix assignment”.

Ok, would you be happier with ’static prefix advertisement’?

> It is still reachability. The determination of when to advertise the prefix and when not to is still based upon whether the ABR has a path to the prefix based on latest SPF calculation.

That smells much more like liveness.  This is one disagreement.

> I was hoping to get rid of this distraction – but no such luck I see.

There’s very good reason. We make address assignments to areas so that we have a mapping from prefixes to topology. We make this a static mapping so that we don’t have to deal with continual flap. If a host within the prefix is up, then it is reachabie within that portion of the topology. That static property is what we call ‘reachability’.

> [LES:] This wasn’t the point of the example.

It is the point of our disagreement.

> I wasn’t promoting the example as desirable deployment choice. I was only illustrating that it is the change in reachability(sic) that is the event. With current IGP advertisements we would (of course) stop advertising reachability when we do not have a path to a given prefix. The new advertisements propose to advertise the loss of reachability to destinations which are covered by a summary. That has advantages over a withdrawal (the absence of an advertisement).

While that is still distasteful for scalability reasons, that would be preferable to injecting additional information at failure time. What advantages does that have?

> But please do not obfuscate things by claiming a reachability advertisement is now something else when it is triggered by the same event i.e., a change in the reachability to a given destination.

I would not say that.  I think that the choices are simpler:
a) Advertise a summary.
b) Don’t bother with hierarchy.

> Please do not twist my words.

I’m not trying to twist them, I’m trying to understand them. Tagging is not, in and of itself, a limitation. Harsh experience with previous scalability issues has taught me that what we think of as ‘modest’ becomes the customer’s version of ‘unlimited’. If there are other mechanisms, other than some arbitrary limit, they haven’t been discussed.

We’re proposing new mechanisms. We need to understand how they will be used in the field and we know that they will be abused in the worst ways possible. My concern is never about 1 or 2 additional prefixes. My concern is that it becomes tens of thousands and expectations that they propagated in 10ms even with a mass failure.

Our job is to ensure that the worst possible conditions still work. I’m not yet convinced and I don’t think we should be solving this in the IGP.

Tony

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 30 Nov 2021 08:31:09 -0800

Hi Robert,
thank you for your kind words and the discussion. Please find my notes
in-lined below and tagged GIM2>>.

Regards,
Greg

On Tue, Nov 30, 2021 at 1:11 AM Robert Raszuk <[email-masked]> wrote:

> #1 - Yes, if my control plane RR-PE network fails and the normal data
> plane to PE is still up I will have a false positive. Solution: Use more
> than one RR.
>
GIM2>> Now we have to reconcile states reported by RRs. Doable but adds
complexity.

> data plane processing anyway
GIM2>> Agree,

> alive. Network down detection is not the goal for discussing PUA/PULSE.
GIM2>> Thank you for the clarification. Though I wonder how such separation
benefits network operation.

>> For example, a 10 ms detection guarantee is required for local
>> protection. And that results in a 3.3 ms interval between the fault
>> detection packets (e.g., CCM or BFD). As I understand it, IGP is likely to
>> rely on single-hop BFD detection. Hence, 10 ms before PE's neighbor
>> discovers the failure. Then the IGP processes will start acting. Thus, I
>> don't see how IGP can guarantee anything less than 10 ms. Would you agree?
>>
>> Regards,
>> Greg
>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 30 Nov 2021 18:09:45 +0100

Hi Greg,

GIM2>> Now we have to reconcile states reported by RRs.

Not really. That "reconciliation" is native and automatic. No need to do
anything. If you are hearing updates from two RRs you only consider it DOWN
when both RRs withdraw the very path. Otherwise it is all UP.

> GIM2>> Thank you for the clarification. Though I wonder how such
> separation benefits network operation.
>

Well that can happen if you really use separate data plane for your control
channels from RRs. Honestly I have not seen much deployments which would
use such model.

Many thx,
R.

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 30 Nov 2021 20:14:55 +0100

hi les,

please see inline.

On Mon, Nov 29, 2021 at 10:39:17PM +0000, Les Ginsberg (ginsberg) wrote:
|    Hannes -
| 
|     
| 
|    Thanx for bringing a new voice into the discussion.
| 
|    Please see inline.
| 
|     
| 
|    > -----Original Message-----
| 
|    > From: Hannes Gredler <[email-masked]>
| 
|    > Sent: Monday, November 29, 2021 1:27 AM
| 
|    > To: Aijun Wang <[email-masked]>
| 
|    > Cc: 'Robert Raszuk' <[email-masked]>; 'lsr' <[email-masked]>; Les
|    Ginsberg
| 
|    > (ginsberg) <[email-masked]>; 'Tony Li' <[email-masked]>; 'Shraddha
| 
|    > Hegde' <[email-masked]>; Peter Psenak (ppsenak)
| 
|    > <[email-masked]>
| 
|    > Subject: Re: [Lsr] BGP vs PUA/PULSE
| 
|    >
| 
|    > On Mon, Nov 29, 2021 at 09:42:57AM +0800, Aijun Wang wrote:
| 
|    >
| 
|    > [ ... ]
| 
|    >
| 
|    > |    Option 3: The “DOWN” detection on ABR is same as PUA/PULSE, the
| 
|    > different
| 
|    > |    is how to propagate such “DOWN” information. Considering we have
| 
|    > observed
| 
|    > |    that all P/PE router in other areas may be interested such
|    information,
| 
|    > |    your proposal will require every P/PE router run BGP-LS, which is
|    not the
| 
|    > |    aimed deploy scenarios for BGP-LS.
| 
|    >
| 
|    > HG> BGP-LS has been conceived to solve the very problem of providing
| 
|    > visibility of other
| 
|    > area's link state. I fail to see what is out of scope here.
| 
|    >
| 
|    [LES:] BGP-LS only advertises what the IGPs themselves advertise.

HG> That is an implementation choice; the protocol allows multiple sources of information.
https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml#protocol-ids
And even standalone implementations are fine as the LSVR WG suggests.

|    In this case, both IGP proposals involve ephemeral advertisements - so
|    even if we were to define BGP-LS support for these new advertisements -
|    they wouldn't persist long enough to be reflected in BGP-LS.

HG> you could model the liveliness tracker as a "source protocol" and advertise the state of your endpoint.

|    So, I really don’t know why we are discussing BGP-LS in the context of
|    this thread.

HG> because some people think it's a bad a idea to put this corner-case app in the very core of our networks.

|    (This seems to be one example of what Acee correctly identified as this
|    discussion going "off track".)

HG> please do not derail the discussion. It is well within the mandate of LSR to discuss solution space and have a healthy discussion
about the scalingaspects of a proposal. If the WG has concerns on the scaling properties and brings up alternatives to make a given
use-case work that is IMO fine and we may just use some airtime for that. After all it's link-state routing, right ?

| 
|     
| 
|    > |    Then, if IGP has such capabilities, why bother BGP? What is the
|    benefit?
| 
|    >
| 
|    > HG> simply put: seperation of concerns. Agreed consensus is to mostly
|    use
| 
|    > the
| 
|    > IGP for topology discovery and put the bulk of carrying reachability
| 
|    > information
| 
|    > into BGP which gives us:
| 
|    >
| 
|    [LES:] I am not convinced either side can claim "consensus" in this
|    discussion. That is a work in progress. 😊

HG> by consensus i meant that the BGP/IGP split is common practise of building large scale networks.

|    However, when you say IGPs are (exclusively?) for topology discovery - it
|    seems to suggest that IGP shouldn’t be advertising prefix reachability at
|    all. Hopefully, that is not what you intend.

HG> did not say that. of course we need minimal IP reachability for bootstrapping the iBGP transport mesh.
    but we certainly do not use the IGP for carrying bulk routes at (Internet) scale.
 
|    One of the points that still baffles me is the assertion of an
|    architectural violation in the IGP proposals.
| 

HG> did not say that.

| 
|    It is OK for IGPs to advertise all prefixes covered by a summary (i.e., do
|    not summarize).
| 
|    It is OK for IGPs to advertise multiple summaries (e.g., multiple /24s
|    instead of a single /16).
| 
|    It is even OK for IGPs to advertise some prefixes covered by a summary
|    along with the summary (don’t know if any implementations do this - but
|    they could).
| 
|    None of this is an "architectural violation".
| 

HG> Again - Don't think its an architectual violation - I just think in it's current state
it has a lot of havoc potential under load.
 
|    But advertising a summary and signaling the loss of reachability to a
|    specific prefix covered by the summary is seen by some as an architectural
|    violation.
| 
|    Sorry, I still don't understand this argument.
|
|     
| 
|    You can not like the approach. You can be concerned about scaling
|    properties (more on that below). You can question the effectiveness of
|    ephemeral advertisements.
| 
|    These kinds of objections/concerns I can easily understand - even if we
|    don’t agree on their significance.
| 
|    But claiming that "IGPs are not supposed to do this"??
| 
|    Not grokking this.
| 
|     
| 
|    We have not added any new information to the IGP itself. We are only
|    suggesting a new form of advertisement to signal some information already
|    known to the IGP, but which is currently not advertised (in some
|    deployments) by the configuration of summaries.
| 
|     
| 
|     
| 
|    > 1) flow-control capabilities (=by virtue of TCP) and
| 
|    > 2) furthermore operators can scale and isolate the distribution vehicle
|    for a
| 
|    > given AFI/SAFI service
| 
|    >    using a dedicated RR infrastructure which does not mess with your
|    bread
| 
|    > and butter service
| 
|    >    infra.
| 
|    >
| 
|    > IMO it is not a good idea to put (negative) reachability information
|    back into
| 
|    > the IGP as you
| 
|    > would loose this "seperation of concerns" aspect and potentially
|    de-stabilize
| 
|    > your topology discovery
| 
|    > tool and hence *all* your bread-and-butter services.
| 
|    >
| 
|    [LES:] The questions of scale (as I have previously commented) are very
|    legitimate - and more has to be specified before an IGP solution would be
|    considered ready for deployment. But there are tools easily applicable to
|    address this (rate limiting, embedded summarization, perhaps others).
| 
|    The more significant point is to focus on the goal - which in this usage
|    is improved convergence time.
| 
|    When the network is largely stable, convergence improvements can be
|    achieved w/o risk.

HG> Ok. To me scaling under load is *the* issue.
The question is what happens if the network gets unstable and your vanilla LSPs
have to compete for I/O and CPU resources with your "negative updates". Can you see
situations where this resource contention has destabilizing potential ?

|    When widespread failures occur, real time signaling of any type is
|    unlikely to provide improved convergence - which is why the IGPs today
|    shift the focus from convergence to stability by slowing down the rate of
|    updates sent and SPFs performed. This is STILL true even in the fast
|    convergence/FRR era.
| 
|    I see no reason why the same tools should not be used in this case.

HG> well when the fun starts - and 1000s of LSPs fly like bullets, good luck pacing that ...

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 30 Nov 2021 20:22:25 +0100

hi peter,

Just curious: Do you have an idea how to make short-lived LSPs compatible with the problem stated in
https://datatracker.ietf.org/doc/html/rfc7987

Would like to hear your thoughts on that.

thanks,

/hannes

On Tue, Nov 30, 2021 at 01:15:04PM +0100, Peter Psenak wrote:
| Hi Robert,
| 
| On 30/11/2021 12:40, Robert Raszuk wrote:
| > Hey Peter,
| > 
| >      > #1 - I am not ok with the ephemeral nature of the advertisements. (I
| >      > proposed an alternative).
| > 
| >     LSPs have their age today. One can generate LSP with the lifetime of 1
| >     min. Protocol already allows that.
| > 
| > 
| > That's a pretty clever comparison indeed. I had a feeling it will come
| > up here and here you go :)
| > 
| > But I am afraid this is not comparing apple to apples.
| > 
| > In LSPs or LSA flooding you have a bunch of mechanisms to make sure the
| > information stays fresh
| > and does not time out. And the default refresh in ISIS if I recall was
| > something like 15 minutes ?
| 
| yes, default refresh is 900 for the default lifetime of 1200 sec. Most
| people change both to much larger values.
| 
| If I send the LSP with the lifetime of 1 min, there will never be any
| refresh of it. It will last 1 min and then will be purged and removed from
| the database. The only difference with the Pulse LSP is that it is not
| purged to avoid additional flooding.
| 
| 
| > 
| >     Today in all MPLS networks host routes from all areas are "spread"
| >     everywhere including all P and PE routers, that's how LS protocols
| >     distribute data, we have no other way to do that in LS IGPs.
| > 
| > 
| > Can't you run OSPF over GRE ? For ISIS Henk had proposal not so long ago
| > to run it over TCP too.
| > https://datatracker.ietf.org/doc/html/draft-hsmit-lsr-isis-flooding-over-tcp-00
| 
| you can run anything over GRE, including IGPs, and you don't need TCP
| transport for that. I don't see the relevance here. Are you suggesting to
| create GRE tunnels to all PEs that need the pulses? Nah, that would be an
| ugly requirement.
| 
| thanks,
| Peter
| 
| 
| > 
| > Seems like a perfect fit !
| > 
| > Thx,
| > R.
|

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 30 Nov 2021 22:15:57 +0000

Hannes -

Inline.

> Sent: Tuesday, November 30, 2021 11:15 AM
> Cc: Aijun Wang <[email-masked]>; 'Robert Raszuk'
> <[email-masked]>; 'lsr' <[email-masked]>; 'Tony Li' <[email-masked]>;
> 'Shraddha Hegde' <[email-masked]>; Peter Psenak (ppsenak)
> <[email-masked]>
[LES:] Yes - I thought you might bring that up. 😊
If you want to use BGP-LS to advertise things on its own, that's fine and - as you point out - even supported by RFC 7752.
But it isn’t part of the LSR WG discussion where we are discussing possible IGP solutions.

> in the very core of our networks.
[LES:] Again, if you want to propose BGP-LS as a possible solution, feel free to do so. I believe IDR would be the right WG for that discussion.

> HG> please do not derail the discussion. It is well within the mandate of LSR
> to discuss solution space and have a healthy discussion
> about the scalingaspects of a proposal. If the WG has concerns on the scaling
> properties and brings up alternatives to make a given
> use-case work that is IMO fine and we may just use some airtime for that.
> After all it's link-state routing, right ?
> 
> |
> |
> |

[LES:] No one is proposing that.
WE are proposing to signal loss of reachability to prefixes that are already being learned by the IGPs.

> |    architectural violation in the IGP proposals.
[LES:] That was in response to earlier comments from other folks. I used your post as an opportunity to discuss that further.
Apologies for unintentionally implying that you had said this.

> situations where this resource contention has destabilizing potential ?
[LES:] We have acknowledged the potential for destabilization and are committed to addressing it.
We have also highlighted that the problem to be solved isn’t how to converge faster when a network melts down in a significant way. It is how to converge faster when there are modest topology changes in an otherwise stable network.
Some folks think if you can't deal with the meltdown that the solution isn’t worth doing - but I think this overlooks when improved convergence can actually be achieved and when it can’t.

But "doing no harm" - absolutely agree with that goal.

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 30 Nov 2021 22:19:01 +0000

Hannes -

Please see https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-4.1

The new Pulse LSPs don't have remaining lifetime - quite intentionally.
They are only retained long enough to support flooding.

But, you remind me that we need to specify how the checksum is calculated. Will do that in the next revision.

Thanx.

    Les

> Sent: Tuesday, November 30, 2021 11:22 AM
> To: Peter Psenak (ppsenak) <[email-masked]>
> Cc: Robert Raszuk <[email-masked]>; Les Ginsberg (ginsberg)
> <[email-masked]>; Aijun Wang <[email-masked]>; lsr
> <[email-masked]>; Tony Li <[email-masked]>; Shraddha Hegde
> <[email-masked]>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 30 Nov 2021 21:12:31 -0500

Hi Robert

On Tue, Nov 30, 2021 at 12:09 PM Robert Raszuk <[email-masked]> wrote:

> Well that can happen if you really use separate data plane for your
> control channels from RRs. Honestly I have not seen much deployments which
> would use such model.
>

   Gyan> My verbiage used in describing this may have been confusing but
what Greg mentioned related to false positive and negative shed some light
on this topic.  So it’s basically the forwarding plane path PE to PE
between any pair of ingress or egress PEs from a design perspective should
never have an RR in the path as the RR hardware is not as robust for high
speed forwarding plane traffic as a PE or P.  Thus the RR from a
topological POV sits to the side in each POP so it’s outside of the direct
PE to PE path forwarding plane for customer traffic.  For this reason the
RR to PE peering path as it’s not the same as the PE to PE path it may
result in false positive or negative.  I am not sure that can be fixed as
that is inherent to any RR design.

*Gyan Mishra*

*M 301 502-1347*