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

From: Enke Chen <[email-masked]>
Date: Fri, 15 Oct 2021 10:20:34 -0700

Hi, Folks:

As I recall, the loopbacks and their metrics need to be propagated
individually to the whole network (including leaking from Level 2 to Level
1) for the following reasons:

1) Path selection: in case there are multiple Level 2 /  Level 1 routers in
an area.
2) Export IGP metric : when the IGP metrics are exported to BGP as MED for
symmetric routing.

Not sure if there is still a problem to be solved.

Regards,

-- Enke

---------- Forwarded message ----------
From: Tony Li <[email-masked]>
To: "Les Ginsberg (ginsberg)" <[email-masked]>
Cc: Gyan Mishra <[email-masked]>, lsr <[email-masked]>
Bcc:
Date: Wed, 13 Oct 2021 22:50:33 -0700
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF
Extension for Event Notification"

Les,

If you’re advertising loopbacks that are outside of the summarized space,
then you end up with reachability and liveness.  Yes, there’s a cost in
scalability… it ain’t free.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 15 Oct 2021 19:37:31 +0200

Enke,

Not really ... unless you force it by configuration most specific route is
used to resolve your next hops.

Clearly everything works fine from your list with no loopbacks everywhere -
except summary route is used instead.

Best,
R.

On Fri, Oct 15, 2021 at 7:21 PM Enke Chen <[email-masked]>
wrote:

> 1) Path selection: in case there are multiple Level 2 /  Level 1 routers
> in an area.
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: Enke Chen <[email-masked]>
Date: Fri, 15 Oct 2021 11:25:07 -0700

Hi, Robert:

The two cases I listed for requiring the individual loopbacks were the ones
we faced at InternetMCI many years ago when we were investigating using
both L2+L1 (prior to L2 route leaking). It's not sufficiently accurate to
rely on the aggregates in these cases.

Thanks.   -- Enke

On Fri, Oct 15, 2021 at 10:37 AM Robert Raszuk <[email-masked]> wrote:

> Clearly everything works fine from your list with no loopbacks everywhere
> - except summary route is used instead.
>
> Best,
> R.
>
>
>> 2) Export IGP metric : when the IGP metrics are exported to BGP as MED
>> for symmetric routing.
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lsr&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=CyuvZoeTxWdq-MzY_N3aRC3vN5iXMJzjHo_7TP5_S2U&s=aG7aHzcn05QWfjkWdJ4f05SYrO_kHYoA6h3LccwlysQ&e=>
>>
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 15 Oct 2021 21:17:11 +0200

Hi Enke,

Yes each summarization/aggregation results in loss of some granular
information for the benefit of scaling the overall system.

The current discussion does not state that networks must use summarization
but actually assumes that one has a hierarchical underlay spanning large
geography (maybe entire planet) with lots of service edges. Maybe 1K, 10K
.. maybe more when it comes to 5G Edges.

Then recommendation to say - pls go and flood all of those with leaking /32
or /128 everywhere seems not that great.

But again I think service recovery should be done at service level as it is
today in different failure scenarios.

Thx,
R.

On Fri, Oct 15, 2021 at 8:25 PM Enke Chen <[email-masked]>
wrote:

> Hi, Robert:
>
> The two cases I listed for requiring the individual loopbacks were the
> ones we faced at InternetMCI many years ago when we were investigating
> using both L2+L1 (prior to L2 route leaking). It's not sufficiently
> accurate to rely on the aggregates in these cases.
>
> Thanks.   -- Enke
>
>
>
>
>> Not really ... unless you force it by configuration most specific route
>> is used to resolve your next hops.
>>
>>> If you’re advertising loopbacks that are outside of the summarized
>>> space, then you end up with reachability and liveness.  Yes, there’s a cost
>>> in scalability… it ain’t free.
>>>
>>> Tony

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 15 Oct 2021 19:33:27 +0000

Hi Robert,

From: Lsr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Friday, October 15, 2021 at 3:17 PM
To: Enke Chen <[email-masked]>
Cc: lsr <[email-masked]>, Tony Li <[email-masked]>
Subject: Re: [Lsr] Prefix Unreachable Announcement and IS-IS and OSPF Extension for Event Notification

Hi Enke,

Yes each summarization/aggregation results in loss of some granular information for the benefit of scaling the overall system.

The current discussion does not state that networks must use summarization but actually assumes that one has a hierarchical underlay spanning large geography (maybe entire planet) with lots of service edges. Maybe 1K, 10K .. maybe more when it comes to 5G Edges.

10K loopbacks advertised as summaries should be nothing for a will-tuned OSPF implementation. Most implementations (at least the ones I’ve worked on) support overlapping range configuration so you can have more specific summaries that are advertised. A nice additional configuration tool would be to have a range which would not result in a summary but routes falling in the range would just be advertised rather than aggregated. This would ease the configuration overhead as long network administrators had the forethought to put these loopback into a subset of the prefixes allocated to a given area.

Thanks,
Acee

Then recommendation to say - pls go and flood all of those with leaking /32 or /128 everywhere seems not that great.

But again I think service recovery should be done at service level as it is today in different failure scenarios.

Thx,
R.

On Fri, Oct 15, 2021 at 8:25 PM Enke Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Robert:

The two cases I listed for requiring the individual loopbacks were the ones we faced at InternetMCI many years ago when we were investigating using both L2+L1 (prior to L2 route leaking). It's not sufficiently accurate to rely on the aggregates in these cases.

Thanks.   -- Enke

On Fri, Oct 15, 2021 at 10:37 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Enke,

Not really ... unless you force it by configuration most specific route is used to resolve your next hops.

Clearly everything works fine from your list with no loopbacks everywhere - except summary route is used instead.

Best,
R.

On Fri, Oct 15, 2021 at 7:21 PM Enke Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Folks:

As I recall, the loopbacks and their metrics need to be propagated individually to the whole network (including leaking from Level 2 to Level 1) for the following reasons:

1) Path selection: in case there are multiple Level 2 /  Level 1 routers in an area.
2) Export IGP metric : when the IGP metrics are exported to BGP as MED for symmetric routing.

Regards,

-- Enke

---------- Forwarded message ----------
From: Tony Li <[email-masked]<mailto:[email-masked]>>
To: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Cc: Gyan Mishra <[email-masked]<mailto:[email-masked]>>, lsr <[email-masked]<mailto:[email-masked]>>
Bcc:
Date: Wed, 13 Oct 2021 22:50:33 -0700
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Les,

If you’re advertising loopbacks that are outside of the summarized space, then you end up with reachability and liveness.  Yes, there’s a cost in scalability… it ain’t free.

Tony
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lsr&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=CyuvZoeTxWdq-MzY_N3aRC3vN5iXMJzjHo_7TP5_S2U&s=aG7aHzcn05QWfjkWdJ4f05SYrO_kHYoA6h3LccwlysQ&e=>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 16 Oct 2021 12:34:59 -0400

Hi Enke

See section 5 of PUA draft use case.

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

Also see RFC 5283 LDP Inter-area extension and use of LPM matching
summarization and issue with black hole routing with RFC 5283 summarization
gap that exists when the BGP next hop attribute LPM prefixes go away do fo
PE node failover.

Also RFC 5302 ramifications of domain wide flooding of loopbacks
scalability issue for large areas and solution needed to make RFC 5283 LPM
summarization possible.

Operators don’t want to flood the loopbacks domain wide for scalability
reasons.

This issue with LPM matching as well for IP or SRv6 based networks when
component prefix goes away from node failure when summarization is utilized.

The issue with multiple multiple paths can be resolved with ECMP path
between areas with multiple level1-2 routes redundant paths so that you
don’t run into symmetry issues.  Also their are cases where symmetry is not
necessary.  Also you can use hardcoded metrics to set preferred path.  IGP
metric exported to BGP as MED does not come into play here as we are not
redistribution ISIS into BGP.  We are doing next hop self on egress PE and
it’s the PE loopback next hop attribute that is flooded.

Kind Regards

Gyan

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

*M 301 502-1347*

---

From: Enke Chen <[email-masked]>
Date: Mon, 18 Oct 2021 10:50:20 -0700

Hi, Gyan:

> IGP metric exported to BGP as MED does not come into play here as we are
not redistribution ISIS into BGP.
> We are doing next hop self on egress PE and it’s the PE loopback next hop
attribute that is flooded.

"Exporting IGP metric to BGP" (also discussed in Sect. 1.1, RFC 5302) is
different from "redistributing IGP into BGP". In Cisco IOS the feature is
configured as "set metric-type internal" in an outbound route-map.

Thanks.   -- Enke

On Sat, Oct 16, 2021 at 9:35 AM Gyan Mishra <[email-masked]> wrote:

> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dwang-2Dlsr-2Dprefix-2Dunreachable-2Dannoucement-2D07-23section-2D5&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=EP67fgSmvoUQ60_OUUqc0BJ3zy3bmRVf8DrsucnyeGk&s=juwHypuac_GTZeZhN_M7ms5blX0_6WSIt7YGOCKzJe4&e=>
>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lsr&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=EP67fgSmvoUQ60_OUUqc0BJ3zy3bmRVf8DrsucnyeGk&s=g9Thil3w---hguNz-FkPmxjLHnurnmrUFzDHaSm1jaI&e=>
>>
> --
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=EP67fgSmvoUQ60_OUUqc0BJ3zy3bmRVf8DrsucnyeGk&s=IiPSPRNx8poa0PgzIswRH-Tmd8aPbgntkDetpL9kPdc&e=>
>
> *Gyan Mishra*
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 18 Oct 2021 16:49:46 -0400

Hi Enke

Understood.  Sending IGP metric into BGP can have unwanted consequences as
MED is higher up in BGP path selection and so can cause much non
deterministic behavior.  It is better to not match internal but rather do
set metric to set higher MED on all prefix to make the path preferred.  Or
you can de-prefer the path by setting metric/med to 0.  In my experience
there are better ways such as prepending and local preference to maintain
symmetry then exporting IGP metric to BGP.

Kind Regards

Gyan
On Mon, Oct 18, 2021 at 1:50 PM Enke Chen <[email-masked]>
wrote:

> > We are doing next hop self on egress PE and it’s the PE loopback next
> hop attribute that is flooded.
>

*Gyan Mishra*

*M 301 502-1347*

---

From: Enke Chen <[email-masked]>
Date: Mon, 18 Oct 2021 13:56:56 -0700

Hi, Gyan:

I am not sure what you meant by "non-deterministic" behavior. If you
referred to dampening the IGP metric export, there is this knob "bgp
dynamic-med-interval".

If one wants symmetric routing with scale at the prefix-level, "exporting
IGP metric as MED" is the best option.

Thanks.   -- Enke

On Mon, Oct 18, 2021 at 1:50 PM Gyan Mishra <[email-masked]> wrote:

>> > IGP metric exported to BGP as MED does not come into play here as we
>> are not redistribution ISIS into BGP.
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=gtx8sc-_Jh00dX84ZuQEFj2HYti4M3KJRg7fxox4MpQ&s=omEgWRPZkDBZvAYi_C_wSKbG5YiBS-7XK703pp6uiM8&e=>
>
> *Gyan Mishra*
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 18 Oct 2021 22:30:22 -0400

Hi Enke

Because MED is non transitive it is only propagated to adjacent AS, so only
in unique situations where the  path attribute does not need to be
propagated multiple hops is MED utilized.

I was thinking of AS level  not prefix level symmetry.

So for AS level symmetry exporting IGP metric info BGP MED will yield non
deterministic results.  For AS level symmetry prepending is the best option
especially and required for path attribute transitivity.

There are many ways to achieve symmetry and it all depends on the use case
and what you are trying to accomplish.

I agree for prefix level symmetry if load balancing is desired between
multiple exit points only then is export of IGP metric as MED is desired.
The routing can become chaotic for NOC to troubleshoot as some routes may
take one exit point versus another dynamically and maybe hard for the NOC
to follow.

Kind Regards

Gyan

On Mon, Oct 18, 2021 at 4:57 PM Enke Chen <[email-masked]>
wrote:

>> Understood.  Sending IGP metric into BGP can have unwanted consequences
>> as MED is higher up in BGP path selection and so can cause much non

*Gyan Mishra*

*M 301 502-1347*