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

From: Gyan Mishra <[email-masked]>
Date: Mon, 8 Mar 2021 18:57:40 -0500

Acee.

Please ask the two questions you raised about the PUA draft so we can
address your concerns.

If anyone else has any other outstanding questions or concerns we would
like to address as well and resolve.

Once all questions and  concerns are satisfied we would like to ask for WG
adoption.

Kind Regards

Gyan
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Tony Li <[email-masked]>
Date: Mon, 8 Mar 2021 16:03:24 -0800

Gyan,

If I understand the purpose of this draft, the point is to punch a hole in a summary so that traffic is redirected via an alternate, working path.

Rather than punch a hole, why not rely on existing technology? Have the valid path advertise the more specific. This will attract the traffic.

Tony

> On Mar 8, 2021, at 3:57 PM, Gyan Mishra <[email-masked]> wrote:
> 
> 
> Acee. 
> 
> Please ask the two questions you raised about the PUA draft so we can address your concerns.
> 
> If anyone else has any other outstanding questions or concerns we would like to address as well and resolve.
> 
> Once all questions and  concerns are satisfied we would like to ask for WG adoption.
> 
> Kind Regards 
> 
> Gyan
> -- 
> Gyan Mishra
> Network Solutions Architect 
> M 301 502-1347
> 13101 Columbia Pike 
> Silver Spring, MD
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Aijun Wang <[email-masked]>
Date: Tue, 9 Mar 2021 08:19:08 +0800

Hi, Tony:

There are two scenarios as introduced by Gyan: one is the node failure(Scenario 1), and another is the link failure(Scenario 2).

For scenario 1, also when all ABRs can’t reach the specified address, it is not efficient to advertise all of other detail prefixes when only one prefix or some prefixes are missing. The ABRs  tell exactly the specified failure prefixes via PUA message is reasonable.

For scenarios 2, because the specified prefixes can be accessed via another ABR, then we can let this ABR to advertise the details prefixes information for the specified address, which behavior is similar with RIFT, as also mentioned in the presentation materials.

Aijun Wang
China Telecom

> On Mar 9, 2021, at 08:03, Tony Li <[email-masked]> wrote:
> 
> 
> 
> Gyan,
>

---

From: Tony Li <[email-masked]>
Date: Mon, 8 Mar 2021 16:22:14 -0800

Hi Aijun,
> For scenario 1, also when all ABRs can’t reach the specified address, it is not efficient to advertise all of other detail prefixes when only one prefix or some prefixes are missing. The ABRs  tell…

If no ABR can reach the address, then there is no point in advertising anything.  The traffic is going to black hole.

> For scenarios 2, because the specified prefixes can be accessed via another ABR, then we can let this ABR to advertise the details prefixes information for the specified address, which behavior is…

Agreed.

So, why do we need to punch a hole?

Tony

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 9 Mar 2021 00:36:58 +0000

Speaking as a WG member:

Hi Gyan,

The first question is how do you know which prefixes within the summary range to protect? Are these configured? Is this half-assed best-effort protection where you protect prefixes within the range that you’ve installed recently? Just how does this work? It is clearly not specified in the draft.

The second comment is that using the prefix-originator TLV is a terrible choice of encoding. Note that if there is any router in the domain that doesn’t support the extension, you’ll actually attract traffic towards the ABR blackholing it.

Further, I think your example is a bit contrived. I’d hope that an OSPF area with “thousands” of summarized PE addresses wouldn’t be portioned by a single failure as in figure 1 in the draft and your slides. I also that the option of a backbone tunnel between the ABRs was removed from the draft since it diminished the requirement for this functionality.

Thanks,
Acee

From: Gyan Mishra <[email-masked]>
Date: Monday, March 8, 2021 at 6:57 PM
To: Acee Lindem <[email-masked]>, Aijun Wang <[email-masked]>, draft-wang-lsr-prefix-unreachable-annoucement <[email-masked]>, lsr <[email-masked]>
Subject: https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Acee.

Kind Regards

Gyan
--

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

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 8 Mar 2021 19:51:52 -0500

Hi Tony

On Mon, Mar 8, 2021 at 7:22 PM Tony Li <[email-masked]> wrote:

>
> Hi Aijun,
> >
> > There are two scenarios as introduced by Gyan: one is the node
> failure(Scenario 1), and another is the link failure(Scenario 2).
> >
> > For scenario 1, also when all ABRs can’t reach the specified address, it
> is not efficient to advertise all of other detail prefixes when only one
> prefix or some prefixes are missing. The ABRs  tell exactly the specified
> failure prefixes via PUA message is reasonable.
>
>
> If no ABR can reach the address, then there is no point in advertising
> anything.  The traffic is going to black hole.

>
>
>
> > For scenarios 2, because the specified prefixes can be accessed via
> another ABR, then we can let this ABR to advertise the details prefixes
> information for the specified address, which behavior is similar with RIFT,
> as also mentioned in the presentation materials.
>
>
> Agreed.
>

   Gyan> The goal of the solution is to be able to take advantage of
summarizing LPM match using MPLS LDP inter-area LSP extension of VPN
overlay next hop attribute /32 host route so that in larger domains with
1000s of PEs that domain wide flooding of host routes can be eliminated per
RFC 5302 impacts of domain wide flooding. The prefix is the egress PE next
hop attribute for VPN overlay component prefix that becomes unreachable due
to a link or node failure.  All BGP next hop attributes for VPN overlay are
being summarized so LPM summary FEC binding must be used to route the
traffic.  As all the BGP next hop attribute for vpn overlay are summarized
as is the goal to mitigate domain wide host route flooding, the next hop
attribute host routes component prefixes cannot be advertised.  That is the
problem we are trying to solve with PUA signaling of the component prefix
being down using the prefix originator Sub TLV RFC 7794 setting to null0
and flooding using Normal procedures  to force control plane convergence to
alternate egress PE next hop for the LSP to properly re-route.

*Gyan Mishra*

---

From: Aijun Wang <[email-masked]>
Date: Tue, 9 Mar 2021 08:55:09 +0800

Hi, Tony:

Aijun Wang
China Telecom

> On Mar 9, 2021, at 08:22, Tony Li <[email-masked]> wrote:
> 
> 
> Hi Aijun,
>> 

[WAJ] We just want to avoid such silent discard behavior, especially for the scenario that there is BGP session run on such failure prefix. 
The other side of BGP peer can quickly remove the BGP session when it receives such PUA message which tell it the other peer is down now. Other BGP peer protection procedures can then take effects on.
The immediate notification of the failure prefix can certainly accelerate the switchover of BGP control plane and also the service traffic that such BGP session carries.

>> For scenarios 2, because the specified prefixes can be accessed via another ABR, then we can let this ABR to advertise the details prefixes information for the specified address, which behavior is…

[WAJ] Even for this scenario, the advertisement of the detail prefixes is trigger also via the PUA message from other ABR.

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 8 Mar 2021 20:10:55 -0500

On Mon, Mar 8, 2021 at 7:37 PM Acee Lindem (acee) <[email-masked]> wrote:

> Speaking as a WG member:
>
>
>
> Hi Gyan,
>
>
>
> The first question is how do you know which prefixes within the summary
> range to protect? Are these configured? Is this half-assed best-effort
> protection where you protect prefixes within the range that you’ve
> installed recently? Just how does this work? It is clearly not specified in
> the draft.
>
>  Gyan>  All prefixes within the summary range are protected see section 4.
>

   [RFC7794] and [I-D.ietf-lsr-ospf-prefix-originator
<https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05#ref-I-D.ietf-lsr-ospf-prefix-originator>]
draft both define
   one sub-tlv to announce the originator information of the one prefix
   from a specified node.  This draft utilizes such TLV for both OSPF
   and ISIS to signal the negative prefix in the perspective PUA when a
   link or node goes down.

   ABR detects link or node down and floods PUA negative prefix
   advertisement along with the summary advertisement according to the
   prefix-originator specification.  The ABR or ISIS L1-L2 border node
   has the responsibility to add the prefix originator information when
   it receives the Router LSA from other routers in the same area or
   level.

When the ABR or ISIS L1-L2 border node generates the summary
   advertisement based on component prefixes, the ABR will announce one
   new summary LSA or LSP which includes the information about this down
   prefix, with the prefix originator set to NULL.  The number of PUAs
   is equivalent to the number of links down or nodes down.  The LSA or
   LSP will be propagated with standard flooding procedures.

   If the nodes in the area receive the PUA flood from all of its ABR
   routers, they will start BGP convergence process if there exist BGP
   session on this PUA prefix.  The PUA creates a forced fail over
   action to initiate immediate control plane convergence switchover to
   alternate egress PE.  Without the PUA forced convergence the down
   prefix will yield black hole routing resulting in loss of
   connectivity.

   When only some of the ABRs can't reach the failure node/link, as that
   described in Section 3.2
<https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05#section-3.2>,
the ABR th.at can reach the PUA prefix
   should advertise one specific route to this PUA prefix.  The internal
   routers within another area can then bypass the ABRs that can't reach
   the PUA prefix, to reach the PUA prefix.

The second comment is that using the prefix-originator TLV is a terrible
> choice of encoding. Note that if there is any router in the domain that
> doesn’t support the extension, you’ll actually attract traffic towards the
> ABR blackholing it.
>
>  Gyan> I will work with the authors to see if their is any alternative PUA
> process to signal and detect the failure in case prefix originator TLV is
> not supported.
>
> Further, I think your example is a bit contrived. I’d hope that an OSPF
> area with “thousands” of summarized PE addresses wouldn’t be portioned by a
> single failure as in figure 1 in the draft and your slides. I also that the
> option of a backbone tunnel between the ABRs was removed from the draft
> since it diminished the requirement for this functionality.
>
>  Gyan> This is a real world Metro access edge example as the impact is
> customers that have LSP built to the down egress PE that has not failed
> over.  In this scenario their is a Primary and Backup PE per Metro edge
> which is typical for an operator.
>

The workaround used today is to flood all /32 next hop prefixes and not
> take advantage of summarization.  This draft makes RFC 5283 inter area FEC
> binding now viable for operators.
>

>
> Thanks,
> Acee
>
>
>
> *From: *Gyan Mishra <[email-masked]>
> *Date: *Monday, March 8, 2021 at 6:57 PM
> *To: *Acee Lindem <[email-masked]>, Aijun Wang <[email-masked]>,
> draft-wang-lsr-prefix-unreachable-annoucement <
> [email-masked]>, lsr <[email-masked]
> >
> *Subject: *
> https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05
>
>
>
>
>
> Acee.
>
>
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> *Silver Spring, MD
>
>
>
-- 

*Gyan Mishra*

---

From: Aijun Wang <[email-masked]>
Date: Tue, 9 Mar 2021 09:13:49 +0800

Hi, Acee:

Let me state my considerations for your questions.

Aijun Wang
China Telecom

> On Mar 9, 2021, at 08:37, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
> Speaking as a WG member:
>  
> Hi Gyan,
>  

[WAJ] Currently, we consider PUA is one generic notification for the failure prefixes. The ABR can detect the failure prefixes within its attached areas.
There will only two kinds of nodes will react on the PUA message:
One is the receiving side that run BGP session on such failure prefixes(accelerate the BGP switchover procedures), the other is the other ABRs(advertising the detail prefixes if it can reach the prefixes that notified by the receiving PUA)

> The second comment is that using the prefix-originator TLV is a terrible choice of encoding. Note that if there is any router in the domain that doesn’t support the extension, you’ll actually attra…

[WAJ] No. if such router doesn’t support the extension, it will not advertise the PUA message, nor will it act on such message.
>  
> Further, I think your example is a bit contrived. I’d hope that an OSPF area with “thousands” of summarized PE addresses wouldn’t be portioned by a single failure as in figure 1 in the draft and your slides.
> I also that the option of a backbone tunnel between the ABRs was removed from the draft since it diminished the requirement for this functionality.
[WAJ]Tunnel should only be used in some extreme scenarios. For example, when all ABRs can’t advertise the PUA or detail reachable prefixes. We can discuss this later.

---

From: Tony Li <[email-masked]>
Date: Mon, 8 Mar 2021 19:11:57 -0800

Hi Aijun,

> [WAJ] We just want to avoid such silent discard behavior, especially for the scenario that there is BGP session run on such failure prefix. 

Stuffing things in the IGP seems like a poor way of determining that there’s a BGP failure.  Wouldn’t BFD be a more appropriate way of determining the loss of connectivity?  Or aggressive BGP keepalive timers?

> The immediate notification of the failure prefix can certainly accelerate the switchover of BGP control plane and also the service traffic that such BGP session carries.

The IGP is a very poor way of delivering service liveness information.

> [WAJ] Even for this scenario, the advertisement of the detail prefixes is trigger also via the PUA message from other ABR.

That seems 100% unnecessary as the longer prefix will attract the traffic in the way that you want.

Tony

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 9 Mar 2021 12:06:34 +0800

Hi, Tony:

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Tony Li
Sent: Tuesday, March 9, 2021 11:12 AM
To: Aijun Wang <[email-masked]>
Cc: lsr <[email-masked]>; draft-wang-lsr-prefix-unreachable-annoucement <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Aijun Wang <[email-masked]>; Gyan Mishra <[email-masked]>
Subject: Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Hi Aijun,

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

[WAJ] why? 

That seems 100% unnecessary as the longer prefix will attract the traffic in the way that you want.
[WAJ] If the ABR advertises such detail prefix, it will certainly attract the traffic. But here the PUA message is just to trigger the ABR to advertise such detail prefix, or else, such ABR will still advertise the summary address.

Tony

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 8 Mar 2021 23:22:51 -0500

Hi Tony

Thank your for your comments.

Responses in-line

Kind Regards

On Mon, Mar 8, 2021 at 11:06 PM Aijun Wang <[email-masked]>
wrote:

> Cc: lsr <[email-masked]>; draft-wang-lsr-prefix-unreachable-annoucement <
> [email-masked]>; Acee Lindem
> (acee) <[email-masked]>; Aijun Wang <[email-masked]>; Gyan
> Mishra <[email-masked]>
> Subject: Re: [Lsr]
> > [WAJ] We just want to avoid such silent discard behavior, especially for
> the scenario that there is BGP session run on such failure prefix.
>
> Stuffing things in the IGP seems like a poor way of determining that
> there’s a BGP failure.  Wouldn’t BFD be a more appropriate way of
> determining the loss of connectivity?  Or aggressive BGP keepalive timers?
> [WAJ] For BFD, you need to configure between each pair of them to track
> the connectivity.  For BGP keeplive times, the duration is too long.

    Gyan> In previous threads BFD multi hop has been mentioned to track IGP
liveliness but that gets way overly complicated especially with large
domains and not viable.

>
>
> > The other side of BGP peer can quickly remove the BGP session when it
> receives such PUA message which tell it the other peer is down now. Other
> BGP peer protection procedures can then take effects on.
> > The immediate notification of the failure prefix can certainly
> accelerate the switchover of BGP control plane and also the service traffic
> that such BGP session carries.
>
>

    Gyan> As we are trying to signal the IGP to trigger the control plane
convergence, the flooding machinery in the IGP already exists well as the
prefix originator sub TLV from the link or node failure.  IGP seems to be
the perfect mechanism for the control plane signaling switchover.

> > [WAJ] Even for this scenario, the advertisement of the detail prefixes
> is trigger also via the PUA message from other ABR.
>
>
> [WAJ] If the ABR advertises such detail prefix, it will certainly attract
> the traffic. But here the PUA message is just to trigger the ABR to
> advertise such detail prefix, or else, such ABR will still advertise the
> summary address.

      Gyan>As I mentioned advertising flooding of the longer prefix defeats
the purpose of summarization. In order to do what you are stating you have
to remove the summarization and go back to domain wide flooding which
completely defeats the goal of the draft which is to make host route
summarization viable for operators.  We know the prefix that went down and
that is why with the PUA negative advertisement we can easily flood a null0
to block the control plane from installing the route.  We don’t have any
prior knowledge of the alternate for the egress PE bgp next hop attribute
for the customer VPN overlay.  So the only way to accomplish what you are
asking is not do any summarization and flood al host routes.  Of course  as
I stated defeats the purpose of the draft.

*Gyan Mishra*

---

From: Tony Li <[email-masked]>
Date: Mon, 8 Mar 2021 20:32:21 -0800

Hi Aijun,

> [WAJ] For BFD, you need to configure between each pair of them to track the connectivity.  For BGP keeplive times, the duration is too long.

You have to configure BGP on both sides too.

Most implementations do allow you to change the timers.

> The IGP is a very poor way of delivering service liveness information.

Because it’s not a service (un)availability protocol. It’s a reachability and path computation function.  That is it’s role in the architecture.  Asking it to do something else is a violation of the architecture.

Routing protocols are not transport protocols. Or dump trucks. Or service advertisement protocols.

> [WAJ] If the ABR advertises such detail prefix, it will certainly attract the traffic. But here the PUA message is just to trigger the ABR to advertise such detail prefix, or else, such ABR will st…

You don’t need the PUA message. The ABR can see the loss of topology and can realize that it’s the best path to the prefix and can then advertise the explicit longer prefix in addition to the normal summary.

Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 8 Mar 2021 20:39:31 -0800

Hi Gyan,

>     Gyan> In previous threads BFD multi hop has been mentioned to track IGP liveliness but that gets way overly complicated especially with large domains and not viable.

This is not tracking IGP liveness, this is to track BGP endpoint liveness.

Here in 2021, we seem to have (finally) discovered that we can automate our management plane. This ameliorates a great deal of complexity.

>     Gyan> As we are trying to signal the IGP to trigger the control plane convergence, the flooding machinery in the IGP already exists well as the prefix originator sub TLV from the link or node failure.  IGP seems to be the perfect mechanism for the control plane signaling switchover.

You’re trying to fix a problem in the overlay by morphing the underlay.  How can that seem like a good idea?

>       Gyan>As I mentioned advertising flooding of the longer prefix defeats the purpose of summarization.

PUA also defeats summarization.  If you really insist on faster convergence and not building a sufficiently redundant topology, then yes, your area will partition and you will have to pay the price of additional state for your longer prefixes.

> In order to do what you are stating you have to remove the summarization and go back to domain wide flooding

No, I’m suggesting you maintain the summary and ALSO advertise the longer prefix that you feel is essential to reroute immediately.

> which completely defeats the goal of the draft which is to make host route summarization viable for operators.  We know the prefix that went down and that is why with the PUA negative advertisement we can easily flood a null0 to block the control plane from installing the route. 

So you can also advertise the more specific from the connected ABR…

> We don’t have any prior knowledge of the alternate for the egress PE bgp next hop attribute for the customer VPN overlay.  So the only way to accomplish what you are asking is not do any summarization and flood al host routes.  Of course  as I stated defeats the purpose of the draft.

Please read again.

Tony

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 9 Mar 2021 00:17:45 -0500

Hi Tony,

On Mon, Mar 8, 2021 at 11:39 PM Tony Li <[email-masked]> wrote:

>
> Hi Gyan,
>
> >     Gyan> In previous threads BFD multi hop has been mentioned to track
> IGP liveliness but that gets way overly complicated especially with large
> domains and not viable.
>
>

   Gyan> Agreed BGP endpoint liveliness recursive next hop - BGP callback
to IGP - Next hop tracking ..

>
> Here in 2021, we seem to have (finally) discovered that we can automate
> our management plane. This ameliorates a great deal of complexity.
>

   Gyan> Ok.  How do you propose to automate?

>
>
> >     Gyan> As we are trying to signal the IGP to trigger the control
> plane convergence, the flooding machinery in the IGP already exists well as
> the prefix originator sub TLV from the link or node failure.  IGP seems to
> be the perfect mechanism for the control plane signaling switchover.
>
>

    Gyan> I mention overlay but it’s really the underlay as the BGP next
hop is in the global table recursive route to IGP.

> PUA also defeats summarization.  If you really insist on faster
> convergence and not building a sufficiently redundant topology, then yes,
> your area will partition and you will have to pay the price of additional
> state for your longer prefixes.
>

    Gyan> We are talking a typical Metro Edge use case with a pair of PEs
which is redundant.  The issue is not redundancy.  The issue is when
summarization is used  as the component prefixes BGP next hop recursive to
the IGP are now hidden and with MPLS RFC 5283 inter area LSP use case the
failover is broken.  It’s not just faster convergence it’s any convergence
as the traffic black hole dead ends on the ABR cannot build the LSP to the
egress PE.  Please see the diagram in the slide deck it details this
special use case.

> No, I’m suggesting you maintain the summary and ALSO advertise the longer
> prefix that you feel is essential to reroute immediately.

    Gyan> ok understood.  How would you know or figure out the logic on the
ABR to find what the backup egress PE next hop to advertise the LSP.  This
is a unique data plane failure condition with RFC 5283 inter area LSP
extension where this problem statement occurs.

>
>
>
> > which completely defeats the goal of the draft which is to make host
> route summarization viable for operators.  We know the prefix that went
> down and that is why with the PUA negative advertisement we can easily
> flood a null0 to block the control plane from installing the route.
>
>

   Gyan> As this is MPLS exact match FEC host route you would have to flood
the single next hop          loopback let’s say if it’s one backup PE for
simplicity

> throughout the domain so that LDP downstream unsolicited can allocate the
> labels downstream from destination downstream to source upstream, and then
> in reverse forward direction of the LSP unidirectional path is established
> and the traffic is now forwarded to FEC binding label switched to egress PE
> to now domain wide flooded exact match host route.  You cannot use the
> summary route on the ABR as that LPM FEC binding is only supported if using
> RFC 5283.  You cannot go half way you either have to use domain wide
> flooding or use the RFC 5283 inter area LSP LPM match.
>
>
> > We don’t have any prior knowledge of the alternate for the egress PE bgp
> next hop attribute for the customer VPN overlay.  So the only way to
> accomplish what you are asking is not do any summarization and flood al
> host routes.  Of course  as I stated defeats the purpose of the draft.
>
>
> Please read again.
>
> Tony
>
> --

*Gyan Mishra*

---

From: Aijun Wang <[email-masked]>
Date: Tue, 9 Mar 2021 14:47:52 +0800

Hi, Tony:

Aijun Wang
China Telecom

> On Mar 9, 2021, at 12:32, Tony Li <[email-masked]> wrote:
> 
> 
> Hi Aijun,
> 

[WAJ] Aim is the BGP process acts upon the PUA message automatically.

> Most implementations do allow you to change the timers.

[WAJ] it is not efficient as the event trigger mechanism. It is the same comparison between Poll and Push/Notify mechanism.

> Routing protocols are not transport protocols. Or dump trucks. Or service advertisement protocols.

[WAJ]Here I think you can consider the ABR router advertises the wrong summary information and should correct itself via the PUA message. Action on the PUA message is the following optimize treatments.

> You don’t need the PUA message. The ABR can see the loss of topology and can realize that it’s the best path to the prefix and can then advertise the explicit longer prefix in addition to the norma…

[WAJ] The advertise of the details prefixes only occurs when some of the ABRs can reach the prefixes, but some can’t reaches.
If there is no PUA message, how can one ABR knows other ABRs can’t reach the prefixes? It can only know whether itself can reach or not.
Or else, you should require the ABR run SPF on behalf of other ABRs?

---

From: Peter Psenak <[email-masked]>
Date: Tue, 9 Mar 2021 09:55:10 +0100

Tony,

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

that would defeat the purpose of the summarization.

thanks,
Peter

> 
> Tony
> 
> 
>> On Mar 8, 2021, at 3:57 PM, Gyan Mishra <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>> Acee.
>>
>> If anyone else has any other outstanding questions or concerns we 
>> would like to address as well and resolve.
>>
>> /Network Solutions A//rchitect /
>> /M 301 502-1347
>> 13101 Columbia Pike
>> /Silver Spring, MD
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 9 Mar 2021 11:47:37 +0100

> You’re trying to fix a problem in the overlay by morphing the underlay.
How can that seem like a good idea?

I think this really nails this discussion.

We have discussed this before and while the concept of signalling
unreachability does seem useful such signalling should be done where it
belongs.

Here clearly we are talking about faster connectivity restoration for
overlay services so it naturally belongs in overlay.

It could be a bit misleading as this is today underlay which propagates
reachability of PEs and overlay relies on it. And to scale, summarization
is used hence in the underlay, failing remote PEs remain reachable. That
however in spite of many efforts in lots of networks are really not the
practical problem as those networks still relay on exact match of IGP to
LDP FEC when MPLS is used. So removal of /32 can and does happen.

In the same time BGP can pretty quickly (milliseconds) remove affected
service routes (or rather paths) hence connectivity can be restored to
redundantly connected endpoints in sub second. Such removal can be in a
form of atomic withdraw (or readvertisement), removal of recursive routes
(next hop going down) or withdraw of few RD/64 prefixes.

I am not convinced and I have not seen any evidence that if we put this
into IGP it will be any faster across areas or domains (case of
redistribution over ASBRs to and from IGP to BGP). One thing for sure - it
will be much more complex to troubleshoot.

Thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 9 Mar 2021 11:55:58 +0100

Robert,

On 09/03/2021 11:47, Robert Raszuk wrote:
>  > You’re trying to fix a problem in the overlay by morphing the 
> underlay.  How can that seem like a good idea?
> 
> reachability of PEs and overlay relies on it. And to scale, 
> summarization is used hence in the underlay, failing remote PEs remain 
> reachable. That however in spite of many efforts in lots of networks are 
> really not the practical problem as those networks still relay on exact 
> match of IGP to LDP FEC when MPLS is used. So removal of /32 can and 
> does happen.

think SRv6, forget /32 or /128 removal. Think summarization.

I'm not necessary advocating the solution proposed in this particular 
draft, but the problem is valid. We need fast detection of the PE loss.

And forget BFD, does not scale with 10k PEs.

thanks,
Peter

> form of atomic withdraw (or readvertisement), removal of recursive 
> routes (next hop going down) or withdraw of few RD/64 prefixes.
> 
> redistribution over ASBRs to and from IGP to BGP). One thing for sure - 
> it will be much more complex to troubleshoot.
> 
> Thx,
> R.
> 
> On Tue, Mar 9, 2021 at 5:39 AM Tony Li <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     Hi Gyan,
> 
>      >     Gyan> In previous threads BFD multi hop has been mentioned to
>     track IGP liveliness but that gets way overly complicated especially
>     with large domains and not viable.
> 
> 
>     Here in 2021, we seem to have (finally) discovered that we can
>     automate our management plane. This ameliorates a great deal of
>     complexity.
> 
> 
>      >     Gyan> As we are trying to signal the IGP to trigger the
>     control plane convergence, the flooding machinery in the IGP already
>     exists well as the prefix originator sub TLV from the link or node
>     failure.  IGP seems to be the perfect mechanism for the control
>     plane signaling switchover.
> 
> 
>     You’re trying to fix a problem in the overlay by morphing the
>     underlay.  How can that seem like a good idea?
> 
> 
>      >       Gyan>As I mentioned advertising flooding of the longer
>     prefix defeats the purpose of summarization.
> 
> 
>     convergence and not building a sufficiently redundant topology, then
>     yes, your area will partition and you will have to pay the price of
>     additional state for your longer prefixes.
> 
> 
>      > In order to do what you are stating you have to remove the
>     summarization and go back to domain wide flooding
> 
> 
>     No, I’m suggesting you maintain the summary and ALSO advertise the
>     longer prefix that you feel is essential to reroute immediately.
> 
> 
>      > which completely defeats the goal of the draft which is to make
>     host route summarization viable for operators.  We know the prefix
>     that went down and that is why with the PUA negative advertisement
>     we can easily flood a null0 to block the control plane from
>     installing the route.
> 
> 
>      > We don’t have any prior knowledge of the alternate for the egress
>     PE bgp next hop attribute for the customer VPN overlay.  So the only
>     way to accomplish what you are asking is not do any summarization
>     and flood al host routes.  Of course  as I stated defeats the
>     purpose of the draft.
> 
> 
>     Please read again.
> 
>     Tony
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 9 Mar 2021 12:02:55 +0100

Hey Peter,

Well ok so let's forget about LDP - cool !

So IGP sends summary around and that is all what is needed.

So the question why not propage information that PE went down in service
signalling - today mainly BGP.

>   And forget BFD, does not scale with 10k PEs.

You missed the point. No one is proposing full mesh of BFD sessions between
all PEs. I hope so at least.

PE is connected to RRs so you need as many BFD sessions as RR to PE BGP
sessions. Once that session is brought down RR has all it needs to trigger
a message (withdraw or implicit withdraw) to remove the broken service
routes in a scalable way.

Thx,
R.

PS. Yes we still need to start support signalling of unreachability in BGP
itself when BGP is used for underlay but this is a bit different use case
and outside of scope of LSR

---

From: Peter Psenak <[email-masked]>
Date: Tue, 9 Mar 2021 12:12:55 +0100

Hi Robert,

> signalling - today mainly BGP.

because BGP signalling is prefix based and as a result slow.

> You missed the point. No one is proposing full mesh of BFD sessions 
> between all PEs. I hope so at least.
> 
> sessions. 

that can be still too many.
In addition you may have a hierarchical RR, which would still involve 
BGP signalling.

Once that session is brought down RR has all it needs to
> trigger a message (withdraw or implicit withdraw) to remove the 
> broken service routes in a scalable way.

that is the whole point, you need something that is prefix independent.

thanks,
Peter

> 
> Thx,
> R.
> 
> PS. Yes we still need to start support signalling of unreachability in 
> BGP itself when BGP is used for underlay but this is a bit different use 
> case and outside of scope of LSR
> 
> 
> On Tue, Mar 9, 2021 at 11:55 AM Peter Psenak <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Robert,
> 
>      >  > You’re trying to fix a problem in the overlay by morphing the
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >
>      >     Hi Gyan,
>      >
>      >      >     Gyan> In previous threads BFD multi hop has been
>     mentioned to
>      >      >     Gyan> As we are trying to signal the IGP to trigger the
>      >      >       Gyan>As I mentioned advertising flooding of the longer
>      >      > In order to do what you are stating you have to remove the
>      >      > which completely defeats the goal of the draft which is to
>     make
>      >      > We don’t have any prior knowledge of the alternate for the
>     egress
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 9 Mar 2021 12:12:39 +0100

I know it's not fashionable (yet) but put multipoint BFD on BIER & run 2
subdomains and you got 10K. Add subdomains to taste which will also allow
to partition it across chips easily. Yepp, needs silicon that will sustain
reasonable rates but you have a pretty good darn' solution. IGP gives you
reachability for BIER already, you got minimal replication and you can tune
your timers to heart's delight.

Sticking stuff in IGP (to second Tony #1) is very satisfying, especially
since some of that could work some time @ no load on IGP. All those "let's
add a million things to IGP" only catches you when you realize in serious
outage your IGP is busy figuring out/flooding junk rather than getting you
basic connectivity. Yes, good implementation technique and careful design
of protocol can help (e.g. take ISIS extensions that allow you for a large
LSP space where you know what priority things are that need to go out/come
in/compute, here is sympathize with the new idea of separate instance for
"junk hauling" BTW ;-) but mashing overlay into underlay of your most time
sensitive and delicate piece of network control to use it as overlay
signalling protocol does not have a promising history. Confounding the
whole thing on top with adding a route type as signalling means is a bit
injury on top of insult or vice versa

-- tony

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 9 Mar 2021 12:20:06 +0100

> In addition you may have a hierarchical RR, which would still involve

Last time I measured time it takes to propage withdraw via good RR was
single milliseconds.

> because BGP signalling is prefix based and as a result slow.
+
> that is the whole point, you need something that is prefix independent.

BGP can be easily setup in prefix independent way today.

Example 1:

If session to PE1 goes down, withdraw all RDs received from such PE.

Example 2:

Use IGP recursion - Use RFC3107 to construct your interarea LSPs. If PE
goes down withdraw it. IGP can still signal summary no issue as no inet.3
route.

Best,
R.

On Tue, Mar 9, 2021 at 12:12 PM Peter Psenak <[email-masked]> wrote:

> >      >     This is not tracking IGP liveness, this is to track BGP
> endpoint
> >      >     liveness.
> >      >

---

From: Peter Psenak <[email-masked]>
Date: Tue, 9 Mar 2021 12:37:27 +0100

Robert,

> If session to PE1 goes down, withdraw all RDs received from such PE.

still dependent on RDs and BGP specific. We want app independent way of 
signaling the reachability loss. At the end that's what IGPs do without 
a presence of summarization.

Again, I'm not advocating the solution proposed in 
draft-wang-lsr-prefix-unreachable-annoucement. I'm just saying the 
problem seems valid  and IGP based solution is not an unreasonable thing 
to consider if a reasonable one can be found.

> Use IGP recursion - Use RFC3107 to construct your interarea LSPs. If PE 

there is no LSP in SRv6.

Peter

> goes down withdraw it. IGP can still signal summary no issue as no 
> inet.3 route.
> 
> Best,
> R.
> 
> 
> On Tue, Mar 9, 2021 at 12:12 PM Peter Psenak <[email-masked] 
>      >  >   And forget BFD, does not scale with 10k PEs.
>      >
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Robert,
>      >
>      >      >  > You’re trying to fix a problem in the overlay by
>     morphing the
>      >      > underlay.  How can that seem like a good idea?
>      >      >
>      >      > I think this really nails this discussion.
>      >      >
>      >      > We have discussed this before and while the concept of
>     signalling
>      >      > unreachability does seem useful such signalling should be done
>      >     where it
>      >      > belongs.
>      >      >
>      >      > Here clearly we are talking about faster connectivity
>     restoration
>      >     for
>      >      > overlay services so it naturally belongs in overlay.
>      >      >
>      >      > It could be a bit misleading as this is today underlay which
>      >     propagates
>      >      > reachability of PEs and overlay relies on it. And to scale,
>      >      > summarization is used hence in the underlay, failing
>     remote PEs
>      >     remain
>      >      > reachable. That however in spite of many efforts in lots of
>      >     networks are
>      >      > really not the practical problem as those networks still
>     relay on
>      >     exact
>      >      > match of IGP to LDP FEC when MPLS is used. So removal of
>     /32 can and
>      >      > does happen.
>      >
>      >      >
>      >      > In the same time BGP can pretty quickly (milliseconds)
>      >     remove affected
>      >      > service routes (or rather paths) hence connectivity can be
>      >     restored to
>      >      > redundantly connected endpoints in sub second. Such
>     removal can
>      >     be in a
>      >      > form of atomic withdraw (or readvertisement), removal of
>     recursive
>      >      > routes (next hop going down) or withdraw of few RD/64
>     prefixes.
>      >      >
>      >      > I am not convinced and I have not seen any evidence that if we
>      >     put this
>      >      > into IGP it will be any faster across areas or domains
>     (case of
>      >      > redistribution over ASBRs to and from IGP to BGP). One
>     thing for
>      >     sure -
>      >      > it will be much more complex to troubleshoot.
>      >      >
>      >      > Thx,
>      >      > R.
>      >      >
>      >      > On Tue, Mar 9, 2021 at 5:39 AM Tony Li <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >      >
>      >      >
>      >      >     Hi Gyan,
>      >      >
>      >      >      >     Gyan> In previous threads BFD multi hop has been
>      >     mentioned to
>      >      >     track IGP liveliness but that gets way overly complicated
>      >     especially
>      >      >     with large domains and not viable.
>      >      >
>      >      >
>      >      >     This is not tracking IGP liveness, this is to track
>     BGP endpoint
>      >      >     liveness.
>      >      >
>      >      >     Here in 2021, we seem to have (finally) discovered
>     that we can
>      >      >     automate our management plane. This ameliorates a
>     great deal of
>      >      >     complexity.
>      >      >
>      >      >
>      >      >      >     Gyan> As we are trying to signal the IGP to
>     trigger the
>      >      >     control plane convergence, the flooding machinery in
>     the IGP
>      >     already
>      >      >     exists well as the prefix originator sub TLV from the
>     link or
>      >     node
>      >      >     failure.  IGP seems to be the perfect mechanism for
>     the control
>      >      >     plane signaling switchover.
>      >      >
>      >      >
>      >      >     underlay.  How can that seem like a good idea?
>      >      >
>      >      >
>      >      >      >       Gyan>As I mentioned advertising flooding of
>     the longer
>      >      >     prefix defeats the purpose of summarization.
>      >      >
>      >      >
>      >      >     PUA also defeats summarization.  If you really insist
>     on faster
>      >      >     convergence and not building a sufficiently redundant
>      >     topology, then
>      >      >     yes, your area will partition and you will have to pay the
>      >     price of
>      >      >     additional state for your longer prefixes.
>      >      >
>      >      >
>      >      >      > In order to do what you are stating you have to
>     remove the
>      >      >     summarization and go back to domain wide flooding
>      >      >
>      >      >
>      >      >     No, I’m suggesting you maintain the summary and ALSO
>      >     advertise the
>      >      >     longer prefix that you feel is essential to reroute
>     immediately.
>      >      >
>      >      >
>      >      >      > which completely defeats the goal of the draft
>     which is to
>      >     make
>      >      >     host route summarization viable for operators.  We
>     know the
>      >     prefix
>      >      >     that went down and that is why with the PUA negative
>      >     advertisement
>      >      >     we can easily flood a null0 to block the control plane
>     from
>      >      >     installing the route.
>      >      >
>      >      >
>      >      >     So you can also advertise the more specific from the
>      >     connected ABR…
>      >      >
>      >      >
>      >      >      > We don’t have any prior knowledge of the alternate
>     for the
>      >     egress
>      >      >     PE bgp next hop attribute for the customer VPN
>     overlay.  So
>      >     the only
>      >      >     way to accomplish what you are asking is not do any
>     summarization
>      >      >     and flood al host routes.  Of course  as I stated
>     defeats the
>      >      >     purpose of the draft.
>      >      >
>      >      >
>      >      >     Please read again.
>      >      >
>      >      >     Tony
>      >      >
>      >      >     _______________________________________________
>      >      >     Lsr mailing list
>      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      > https://www.ietf.org/mailman/listinfo/lsr
>      >      >
>      >
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 9 Mar 2021 19:30:27 +0100

Hi Peter,

> still dependent on RDs and BGP specific.

To me this does sound like a feature ... to you I think it was rather
pejorative.

> We want app independent way of

Here you go. I suppose you just drafted the first use case for OSPF
Transport Instance.

I suppose you just run new ISIS or OSPF Instance and flood info about PE
down events to all other instance nodes (hopefully just PEs and no Ps as
such plane would be OTT one).  Still you will be flooding this to 100s of
PEs which may never need this information at all which I think is the main
issue here. Such bad news IMHO should be distributed on a pub/sub basis
only. First you subscribe then you get updates ... not get everything then
keep junk till it get's removed or expires.

Many thx,
Robert

---

From: Peter Psenak <[email-masked]>
Date: Wed, 10 Mar 2021 09:10:47 +0100

Robert,

> To me this does sound like a feature ... to you I think it was rather 

not sure I understand your point with "pejorative"...

There are other ways to provide services outside of BGP - think GRE, 
IPsec, etc. The solution should cover them all.

> Here you go. I suppose you just drafted the first use case for OSPF 

you said it, not me.

> such plane would be OTT one).  Still you will be flooding this to 100s 
> of PEs which may never need this information at all which I think is the 
> main issue here. Such bad news IMHO should be distributed on a pub/sub 
> basis only. First you subscribe then you get updates ... not get 
> everything then keep junk till it get's removed or expires.

with MPLS loopback address of all PEs is advertised everywhere. So you 
keep the state when the remote PE loopback is up and you get a state 
withdrawal when the remote PE loopback goes down.

In Srv6, with summarization we can reduced the amount of UP state to 
minimum. But suddenly the DOWN event distribution is considered 
problematic. Not sure I follow.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 10 Mar 2021 11:29:05 +0100

Peter,

> But suddenly the DOWN event distribution is considered

In routing and IP reachability we use p2mp distribution and flooding as it
is required to provide any to any connectivity.

Such spray model no longer fits services where not every endpoint
participates in all services.

So my point is that just because you have transport ready we should not
continue to announce neither good nor bad news in spray fashion for
services.

Sure it works, but it is hardly a good design and sound architecture.

It happened to BGP as the convenience of already having TCP sessions
between nodes was so great that we loaded loads of stuff to go along basic
routing reachability.

And now it seems time came to do the same with IGPs :).

I think unless we stop and define a real pub-sub messaging protocol (like
FB does with open-R)  we will continue this.

And to me it is like building a tower from the cards ... the higher you go
the more likely your entire tower is to collapse.

Cheers,
R.

PS.

> with MPLS loopback address of all PEs is advertised everywhere.

Is this a feature or a day one design bug later fixed by RFC5283 ?

---

From: Peter Psenak <[email-masked]>
Date: Wed, 10 Mar 2021 11:40:01 +0100

Robert,

On 10/03/2021 11:29, Robert Raszuk wrote:
> In routing and IP reachability we use p2mp distribution and flooding as 
> it is required to provide any to any connectivity.
> 
> between nodes was so great that we loaded loads of stuff to go along 
> basic routing reachability.
> 
> I think unless we stop and define a real pub-sub messaging protocol 
> (like FB does with open-R)  we will continue this.

you are of course free to do that. Here we are at the LSR WG.

thanks,
Peter

> 
> And to me it is like building a tower from the cards ... the higher you 
> go the more likely your entire tower is to collapse.
> 
> Cheers,
> R.
> 
> PS.
> 
> On Wed, Mar 10, 2021 at 9:10 AM Peter Psenak <[email-masked] 
>      >      > Example 1:
>      >      > If session to PE1 goes down, withdraw all RDs received
>     from such PE.
>      >

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 10 Mar 2021 11:40:52 +0100

? Last time I looked @ it (and it's been a while) Open-R had nothing of
that sort, it was basically KV playing LSDB (innovative and clever in
itself). You think Kafka here? Which in turn needs underlying IGP however
and is nothing but BGP problems in new clothes having looked @ their
internal architecture and where it's goiing a while ago.

-- tony

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 10 Mar 2021 12:51:58 +0100

>  You think Kafka here?

Nope ... I meant ZeroMQ message bus as underlaying pub-sub transport for
service related info.

Thx,
R.,

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 10 Mar 2021 12:57:55 +0100

same thing. if you want go multiple hops ZeroMQ you need forwarding
already. And if you go one hop it really doesn't matter, it's just FOSE
(flooding over something else ;-)

-- tony

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 11 Mar 2021 16:00:14 +0000

Hi Gyan,

I guess you didn’t understand my first PUA question. See inline.

From: Gyan Mishra <[email-masked]>
Date: Monday, March 8, 2021 at 8:11 PM
To: Acee Lindem <[email-masked]>
Cc: Aijun Wang <[email-masked]>, draft-wang-lsr-prefix-unreachable-annoucement <[email-masked]>, lsr <[email-masked]>
Subject: Re: https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

On Mon, Mar 8, 2021 at 7:37 PM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Speaking as a WG member:

Hi Gyan,

   [RFC7794] and [I-D.ietf-lsr-ospf-prefix-originator<https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05#ref-I-D.ietf-lsr-ospf-prefix-originator>] draft both define

   link or node goes down.

   level.

Acee> So, the ABR will only know about missing prefixes that it has recently received? What if the prefix is already missing when the ABR establishes adjacencies on the path to the PE? What if the prefix is being permanently taken out of service – then this negative advertisement will persist permanently. What if there is an unintentional advertisement in the summary range and it is withdrawn? How do you decide whether or not to protect a prefix with in the range?

   connectivity.

   described in Section 3.2<https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05#section-3.2>, the ABR th.at<http://th.at> can reach the PUA prefix

The second comment is that using the prefix-originator TLV is a terrible choice of encoding. Note that if there is any router in the domain that doesn’t support the extension, you’ll actually attract traffic towards the ABR blackholing it.
 Gyan> I will work with the authors to see if their is any alternative PUA process to signal and detect the failure in case prefix originator TLV is not supported.
Acee> Note that in the case of OSPFv3, the prefix originator TLV is a Sub-TLV of the Inter-Area Prefix TLV advertised in the E-Inter-Area-Prefix-LSA. If there are any OSPFv3 routers in the domain that don’t support this functionality and receive traffic for the protected prefix, they will actually route it towards the blackhole.

Further, I think your example is a bit contrived. I’d hope that an OSPF area with “thousands” of summarized PE addresses wouldn’t be portioned by a single failure as in figure 1 in the draft and your slides. I also that the option of a backbone tunnel between the ABRs was removed from the draft since it diminished the requirement for this functionality.
 Gyan> This is a real world Metro access edge example as the impact is customers that have LSP built to the down egress PE that has not failed over.  In this scenario their is a Primary and Backup PE per Metro edge which is typical for an operator.

The workaround used today is to flood all /32 next hop prefixes and not take advantage of summarization.  This draft makes RFC 5283 inter area FEC binding now viable for operators.
Acee> Or add a reliable intra-area link between your ABRs. Or, as a backup, a tunnel through the backbone area (as was previously in the draft).
Thanks,
Acee

Thanks,
Acee

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 8, 2021 at 6:57 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Aijun Wang <[email-masked]<mailto:[email-masked]>>, draft-wang-lsr-prefix-unreachable-annoucement <[email-masked]<mailto:[email-masked]>>, lsr <[email-masked]<mailto:[email-masked]>>
Subject: https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Acee.

Kind Regards

Gyan
--

Error! Filename not specified.<http://www.verizon.com/>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
Silver Spring, MD

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 11 Mar 2021 18:16:07 +0000

I agree problem is valid for networks that use summarization and leaking for inter-domain connectivity.
However, I don't think the solution space has to be in IGP.
There are various different ways the problem could be solved. 
A network could deploy egress protection [RFC 8679] or anycast based egress protection
[draft-hegde-rtgwg-egress-protection-sr-networks] which will ensure packets aren't dropped
Due to remote PE node failure. This mechanism is faster compared to other possible
Solutions  because if addresses failure  at the PLR and provides protection.

Rgds
Shraddha

Juniper Business Use Only

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Peter Psenak
Sent: Tuesday, March 9, 2021 5:07 PM
To: Robert Raszuk <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Aijun Wang <[email-masked]>; Aijun Wang <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>; Acee Lindem (acee) <[email-masked]>; draft-wang-lsr-prefix-unreachable-annoucement <[email-masked]>
Subject: Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[External Email. Be cautious of content]

Robert,

On 09/03/2021 12:20, Robert Raszuk wrote:
>
>  > In addition you may have a hierarchical RR, which would still 
> involve  > BGP signalling.
>

still dependent on RDs and BGP specific. We want app independent way of signaling the reachability loss. At the end that's what IGPs do without a presence of summarization.

Again, I'm not advocating the solution proposed in draft-wang-lsr-prefix-unreachable-annoucement. I'm just saying the problem seems valid  and IGP based solution is not an unreasonable thing to consider if a reasonable one can be found.

there is no LSP in SRv6.

Peter

>      >      > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!QNHPABFYBen6qbmt6hiQ4B3EwShSGUz40c2NFKvGTCyozXP3LpTpWT2562wntcNw$
>      >      >
>      >
>

_______________________________________________
Lsr mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!QNHPABFYBen6qbmt6hiQ4B3EwShSGUz40c2NFKvGTCyozXP3LpTpWT2562wntcNw$

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 11 Mar 2021 11:29:59 -0500

Hi Acee

Thank you for your comments.

Answers in-line.

Thank you

Gyan

On Thu, Mar 11, 2021 at 11:01 AM Acee Lindem (acee) <[email-masked]> wrote:

> *Date: *Monday, March 8, 2021 at 8:11 PM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *Aijun Wang <[email-masked]>,
> *Subject: *Re:
>    [RFC7794] and [I-D.ietf-lsr-ospf-prefix-originator <https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05#ref-I-D.ietf-lsr-ospf-prefix-originator>] draft both define
>
>  Gyan>  In section 6 of the draft under implementation considerations we have a MAA (Max Address Announcement) threshold value that is configurable.
>
>     1.  If the number of unreachable prefixes is less than MAA, the ABR
>
>    should advertise the summary address and the PUA.
>
>    2.  If the number of reachable address is less than MAA, the ABR
>    should advertise the detail reachable address only.
>
>    3.  If the number of reachable prefixes and unreachable prefixes
>    exceed MAA, then advertise the summary address with MAX metric.
>
>
       If a prefix is already missing when the ABR establishes adjacency on
the path the prefix is not in the lsdb and so a PUA would not be sent for a
prefix that is unknown to the ABR.  Any traffic sent to that bgp next hop
would still be impacted as this is an adjacency forming timing issue.  We
will have investigated this issue with the authors and are thinking of
maybe a delay timer after the adjacency is formed as to when the PUA
mechanism becomes activated that we can add to the considerations section.

>    described in Section 3.2 <https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05#section-3.2>, the ABR th.at can reach the PUA prefix
>
> Acee> Note that in the case of OSPFv3, the prefix originator TLV is a
> Sub-TLV of the Inter-Area Prefix TLV advertised in the
> E-Inter-Area-Prefix-LSA. If there are any OSPFv3 routers in the domain that
> don’t support this functionality and receive traffic for the protected
> prefix, they will actually route it towards the blackhole.
>
>         Gyan>> If the OSPFv3 router does not support the prefix originator
TLV is a Sub-TLV of the Inter-Area Prefix TLV advertised in the
E-Inter-Area-Prefix-LSA then it would use the summary address advertised by
the ABR and black hole as the control plane would not converge to not use
the summary on that non supporting OSPFv3 router.  Agreed.  That support
dependency we will add to the considerations section 6.

> Acee> Or add a reliable intra-area link between your ABRs. Or, as a
> backup, a tunnel through the backbone area (as was previously in the draft).
>
>         Gyan>  The issue is not redundancy.  The issue is when
summarization is used  as the component prefixes BGP next hop recursive to
the IGP are now hidden and with MPLS RFC 5283 inter area LSP use case, the
failover is broken.  It’s not just faster convergence it’s any convergence
as the traffic black hole dead ends on the ABR and cannot build the LSP to
the egress PE.  Please see the diagram below in the slide deck it details
this special use case. The LSP ends up dead ending  black hole on the ABR
once the FEC LPM goes away for the next hop when the PE has a link or node
failure.

Thanks,
> *Error! Filename not specified.* <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>

-- 

*Gyan Mishra*

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 11 Mar 2021 19:48:00 +0000

Hi Gyan,

I think we are starting to communicate but there are still some problems.

Date: Thursday, March 11, 2021 at 1:27 PM

Hi Acee

Answers in-line.

Thank you

Gyan

On Thu, Mar 11, 2021 at 11:01 AM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 8, 2021 at 8:11 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Aijun Wang <[email-masked]<mailto:[email-masked]>>, draft-wang-lsr-prefix-unreachable-annoucement <[email-masked]<mailto:[email-masked]>>, lsr <[email-masked]<mailto:[email-masked]>>
Subject: Re: https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Hi Gyan,

   link or node goes down.

   level.

       If a prefix is already missing when the ABR establishes adjacency on the path the prefix is not in the lsdb and so a PUA would not be sent for a prefix that is unknown to the ABR.  Any traffic sent to that bgp next hop would still be impacted as this is an adjacency forming timing issue.  We will have investigated this issue with the authors and are thinking of maybe a delay timer after the adjacency is formed as to when the PUA mechanism becomes activated that we can add to the considerations section.

So once an intra-area prefix within the range is reachable, you’ll maintain semi-permanent state that it is going to be protected by the PUA mechanism? Prior to that, it will not be protected? That is what you are implying. All these details need to be specified.

   connectivity.

The second comment is that using the prefix-originator TLV is a terrible choice of encoding. Note that if there is any router in the domain that doesn’t support the extension, you’ll actually attract traffic towards the ABR blackholing it.
 Gyan> I will work with the authors to see if their is any alternative PUA process to signal and detect the failure in case prefix originator TLV is not supported.
Acee> Note that in the case of OSPFv3, the prefix originator TLV is a Sub-TLV of the Inter-Area Prefix TLV advertised in the E-Inter-Area-Prefix-LSA. If there are any OSPFv3 routers in the domain that don’t support this functionality and receive traffic for the protected prefix, they will actually route it towards the blackhole.
        Gyan>> If the OSPFv3 router does not support the prefix originator TLV is a Sub-TLV of the Inter-Area Prefix TLV advertised in the E-Inter-Area-Prefix-LSA then it would use the summary address advertised by the ABR and black hole as the control plane would not converge to not use the summary on that non supporting OSPFv3 router.  Agreed.  That support dependency we will add to the considerations section 6.

It is worse than that. For OSPFv3 routers that don’t support this extension, the E-Inter-Area-LSA will attract blackhole traffic since it will be rightly treated as a reachable more-specific advertisement.

The workaround used today is to flood all /32 next hop prefixes and not take advantage of summarization.  This draft makes RFC 5283 inter area FEC binding now viable for operators.
Acee> Or add a reliable intra-area link between your ABRs. Or, as a backup, a tunnel through the backbone area (as was previously in the draft).
        Gyan>  The issue is not redundancy.  The issue is when summarization is used  as the component prefixes BGP next hop recursive to the IGP are now hidden and with MPLS RFC 5283 inter area LSP use case, the failover is broken.  It’s not just faster convergence it’s any convergence as the traffic black hole dead ends on the ABR and cannot build the LSP to the egress PE.  Please see the diagram below in the slide deck it details this special use case. The LSP ends up dead ending  black hole on the ABR once the FEC LPM goes away for the next hop when the PE has a link or node failure.

I don’t why the ABR couldn’t stitch the LSPs through a different path as long as that path is part of the non-backbone area. I simply suggested providing more redundancy in your non-backbone area. Though not shown in your picture 😉 I see no reason why it wouldn’t work.

Thanks,
Acee

Thanks,
Acee

Thanks,
Acee

Acee.

Kind Regards

Gyan
--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 12 Mar 2021 11:50:15 +0800

Hi, Shraddha:

I think Anycast protection mechanism is valid but it requires the deployment of anycast address for each multi-home pair services("The number of anycast loopbacks on a given node will be equal to the number of such {primary, protector} pairs a node belongs to."), and another thing is that they are applying only the SR-based service network.

Peter has mentioned some other scenarios(mainly tunnel services) at https://mailarchive.ietf.org/arch/msg/lsr/lz0FeTvu8OsYIYAJ83eYspmH7B8/
PUA messages can be used to trigger the tunnel switchover, besides the egress node/link protection.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Shraddha Hegde
Sent: Friday, March 12, 2021 2:16 AM
To: Peter Psenak <ppsenak=[email-masked]>; Robert Raszuk <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Aijun Wang <[email-masked]>; Aijun Wang <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>; Acee Lindem (acee) <[email-masked]>; draft-wang-lsr-prefix-unreachable-annoucement <[email-masked]>
Subject: Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

I agree problem is valid for networks that use summarization and leaking for inter-domain connectivity.
However, I don't think the solution space has to be in IGP.
There are various different ways the problem could be solved. 
A network could deploy egress protection [RFC 8679] or anycast based egress protection [draft-hegde-rtgwg-egress-protection-sr-networks] which will ensure packets aren't dropped Due to remote PE node failure. This mechanism is faster compared to other possible Solutions  because if addresses failure  at the PLR and provides protection.

Rgds
Shraddha

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Peter Psenak
Sent: Tuesday, March 9, 2021 5:07 PM
To: Robert Raszuk <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Aijun Wang <[email-masked]>; Aijun Wang <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>; Acee Lindem (acee) <[email-masked]>; draft-wang-lsr-prefix-unreachable-annoucement <[email-masked]>
Subject: Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Robert,

there is no LSP in SRv6.

Peter

>      >      > Here clearly we are talking about faster connectivity
>     restoration
>      >     for
>      >      > summarization is used hence in the underlay, failing
>     remote PEs
>      >     remain
>      >      > really not the practical problem as those networks still
>     relay on
>      >     exact
>      >      > redundantly connected endpoints in sub second. Such
>     removal can
>      >     be in a
>      >      > redistribution over ASBRs to and from IGP to BGP). One
>     thing for
>      >     sure -
>      >      > <mailto:[email-masked] <mailto:[email-masked]>
>      >      >     This is not tracking IGP liveness, this is to track
>     BGP endpoint
>      >      >     liveness.
>      >      >
>      >      >     control plane convergence, the flooding machinery in
>     the IGP
>      >     already
>      >      >     exists well as the prefix originator sub TLV from the
>     link or
>      >     node
>      >      >      > which completely defeats the goal of the draft
>     which is to
>      >     make
>      >      >     host route summarization viable for operators.  We
>     know the
>      >     prefix
>      >      >      > We don’t have any prior knowledge of the alternate
>     for the
>      >     egress
>      >      >     PE bgp next hop attribute for the customer VPN
>     overlay.  So
>      >     the only

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 12 Mar 2021 12:20:29 +0800

Hi, Acee:

Thanks for your considerations for the application of PUA mechanism. Some points should be clarified based on the discussion between you and Gyan.

Please to review whether they address your concerns or not:

1.     The PUA generation should be supported by all of the ABRs when deployment. Or else, the traffic will be sucked to the unsupported ABR, which may or may not forward the traffic.

When other non-ABR nodes support the PUA message, they can take some actions based on this message(service switchover etc.). 

If they don’t support, nothing will happen, only the problems described in this draft is not solved(service traffic is sent to blackhole or via one non-optimize path).

2.     The ABRs should only monitor the absence of prefixes within the summary range. Currently, we do not consider to explicitly configure the protected prefixes, but I think to configures them on the ABRs may reduce some unnecessary PUA messages. Will consider such approach in next update.

3.     For prefixes that not existing after the ABRs startup, ABR will not send the PUA messages for them. Because there will be no services can run on such non-exist addresses.

4.     Theoretically, the PUA messages should be advertised once or for a short configurable period, to aid the service that run on them convergence. After that, the ABR needs not advertise them again.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> 
Sent: Friday, March 12, 2021 3:48 AM
To: Gyan Mishra <[email-masked]>
Cc: Aijun Wang <[email-masked]>; draft-wang-lsr-prefix-unreachable-annoucement <[email-masked]>; lsr <[email-masked]>
Subject: Re: https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Hi Gyan, 

From: Gyan Mishra <[email-masked] <mailto:[email-masked]> >
Date: Thursday, March 11, 2021 at 1:27 PM
To: Acee Lindem <[email-masked] <mailto:[email-masked]> >
Cc: Aijun Wang <[email-masked] <mailto:[email-masked]> >, draft-wang-lsr-prefix-unreachable-annoucement <[email-masked] <mailto:[email-masked]> >, lsr <[email-masked] <mailto:[email-masked]> >
Subject: Re: https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Hi Acee

Answers in-line.

Thank you

Gyan

On Thu, Mar 11, 2021 at 11:01 AM Acee Lindem (acee) <[email-masked] <mailto:[email-masked]> > wrote:

Hi Gyan, 

From: Gyan Mishra <[email-masked] <mailto:[email-masked]> >
Date: Monday, March 8, 2021 at 8:11 PM
To: Acee Lindem <[email-masked] <mailto:[email-masked]> >
Cc: Aijun Wang <[email-masked] <mailto:[email-masked]> >, draft-wang-lsr-prefix-unreachable-annoucement <[email-masked] <mailto:[email-masked]> >, lsr <[email-masked] <mailto:[email-masked]> >
Subject: Re: https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

On Mon, Mar 8, 2021 at 7:37 PM Acee Lindem (acee) <[email-masked] <mailto:[email-masked]> > wrote:

Speaking as a WG member: 

Hi Gyan, 

   [RFC7794] and [I-D.ietf-lsr-ospf-prefix-originator <https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05#ref-I-D.ietf-lsr-ospf-prefix-originator> ] draft both define
   one sub-tlv to announce the originator information of the one prefix
   from a specified node.  This draft utilizes such TLV for both OSPF
   and ISIS to signal the negative prefix in the perspective PUA when a
   link or node goes down.

 

 

 
 
   described in Section 3.2 <https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05#section-3.2> , the ABR th.at <http://th.at>  can reach the PUA prefix

 

 

Thanks,

Acee

Thanks,
Acee

Thanks,
Acee

From: Gyan Mishra <[email-masked] <mailto:[email-masked]> >
Date: Monday, March 8, 2021 at 6:57 PM
To: Acee Lindem <[email-masked] <mailto:[email-masked]> >, Aijun Wang <[email-masked] <mailto:[email-masked]> >, draft-wang-lsr-prefix-unreachable-annoucement <[email-masked] <mailto:[email-masked]> >, lsr <[email-masked] <mailto:[email-masked]> >
Subject: https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Acee. 

Kind Regards 

Gyan

-- 

 <http://www.verizon.com/> Error! Filename not specified.

Gyan Mishra

M 301 502-1347
13101 Columbia Pike <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>  
Silver Spring, MD

-- 

 <http://www.verizon.com/> Error! Filename not specified.

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 12 Mar 2021 00:54:33 -0500

Hi Acee

On Thu, Mar 11, 2021 at 2:48 PM Acee Lindem (acee) <[email-masked]> wrote:

> *Date: *Thursday, March 11, 2021 at 1:27 PM
>        If a prefix is already missing when the ABR establishes adjacency
> on the path the prefix is not in the lsdb and so a PUA would not be sent
> for a prefix that is unknown to the ABR.  Any traffic sent to that bgp next
> hop would still be impacted as this is an adjacency forming timing issue.
> We will have investigated this issue with the authors and are thinking of
> So once an intra-area prefix within the range is reachable, you’ll
> maintain semi-permanent state that it is going to be protected by the PUA
> mechanism? Prior to that, it will not be protected? That is what you are
> implying. All these details need to be specified.
>
>  Gyan>  We will add the details mentioned to the draft.
>
>
>
>
>
>
>
> It is worse than that. For OSPFv3 routers that don’t support this
> extension, the E-Inter-Area-LSA will attract blackhole traffic since it
> will be rightly treated as a reachable more-specific advertisement.
>
> Gyan>  We will add some details surrounding the scenario with non
> supporting routers. The scope of the black hole is a limited set of routers
> being the egress PE node failure that would cause the loopback0 next hop
> attribute to become unreachable as that is the LPM FEC element binding that
> needs to be triggered to for the down FEC LPM to be removed from the LFIB
> so the new LSP can be established to the backup node.  In most cases both
> egress PEs are active with 50/50 load split so it’s a matter of getting FEC
> element for down node removed from LFIB and that is exactly what PUA
> accomplishes with the negative advertisement.  As LSP interesting traffic
> is only destined for egress FEC, and not any connected interface if the PUA
> did not happen for any connected interface that went down there would be no
> operational impact from that black hole of traffic from any node in the
> domain.  So that does reduce the impact of non supporting routers.  We
> could make it a requirement at a minimum that the software revision on all
> PEs must support the sub TLV to use this feature.  As this is the main use
> case, operators would have to upgrade to take advantage of the loopbacks
> next hop attribute summarization with RFC 5283.
>

> I don’t why the ABR couldn’t stitch the LSPs through a different path as
> long as that path is part of the non-backbone area. I simply suggested
> providing more redundancy in your non-backbone area. Though not shown in
> your picture 😉 I see no reason why it wouldn’t work.
>

Gyan> The problem is the signaling from egress PE to ABR and forcing the
ABR convergence to remove the LPM FEC binding.  That’s the problem.
Unfortunately any LSP stitching between ABRs or even TE tLDP stitch or
seamless MPLS BGP-LU overlay or any other idea won’t help as that would be
a redesign replacement of LDP.  Unfortunately MPLS maintains state, and
that is the big advantage of SRV6 even with LPM match.   SR-MPLS as it
reuses MPLS data plane would have the same issue with FEC exact match.
With RFC 5823 the FEC elements are the egress PE loopbacks are now
advertised via LDP inter area extension instead of IGP and IGP in the
backbone and ingress and egress non zero area have the summary only in
IGP.  Once the PUA is sent and flooded it triggers ingress area to converge
immediately removing FEC element loopback LPM of down node in egress area
which now LDP inter area extension updates the LFIB on egress node via the
PUA negative signaling and now the down PE FEC element is removed from the
LFIB and the backup LSP can be  built to the egress PE.  If both egress PEs
are active in most cases 50/50 load split now the 50% traffic now shifts
off the down PE to the other existing active LSP.  Without this PUA feature
the convergence using RFC 5283 convergence of LDP LFIB is very slow black
hole of traffic so operators end up using the inter area extension just for
summarization of connected interface and domain wide flood all egress PE
loopbacks as a workaround.  With this draft the summarization can now be
realized by operators for the loopbacks FEC element as well.

-- 

*Gyan Mishra*

---

From: Peter Psenak <[email-masked]>
Date: Fri, 12 Mar 2021 12:24:25 +0100

Hi Shraddha,

> Solutions  because if addresses failure  at the PLR and provides protection.

egress protection is one way of solving the problem. It has its own 
issues though - it requires the service SIDs to be in sync between 
multiple PEs which is not a trivial thing to do and maintain. Especially 
with the per CE allocation scheme and large scale on top.

Ingress PE "PIC" like convergence has proved its value and if an 
efficient IGP solution can be found to provide a similar mechanism in 
combination with the summarization, I have no doubts users would like that.

A combination of both is possible as well.

thanks,
Peter