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 <hayabusa...@gmail.com> wrote: > > 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 > <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=> > > 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 > > On Fri, Oct 15, 2021 at 1:21 PM Enke Chen <enc...@paloaltonetworks.com> > 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. >> >> Not sure if there is still a problem to be solved. >> >> Regards, >> >> -- Enke >> >> ---------- Forwarded message ---------- >> From: Tony Li <tony...@tony.li> >> To: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> >> Cc: Gyan Mishra <hayabusa...@gmail.com>, lsr <lsr@ietf.org> >> 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 >> Lsr@ietf.org >> 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=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* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
