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 <enc...@paloaltonetworks.com> wrote: > 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 <hayabusa...@gmail.com> wrote: > >> >> 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 <enc...@paloaltonetworks.com> >> wrote: >> >>> 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* >>>> >>>> -- >> >> >> <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* >> >> *Network Solutions A**rchitect * >> >> *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* >> >> >> >> *M 301 502-1347* >> >> -- <http://www.verizon.com/> *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
