[Idr] Re: draft-ssangli-idr-bgp-generic-metric : Kaliraj's 2nd question follow-up

[Kaliraj Vairavakkalai <[e-mail]>]

Srihari, thanks for summarising.

However there seems to be a disconnect on the conclusion in our internal thread.

>. I can clarify for the above case that an intermediate router can add AMetric if it can compute the cost to the next hop of the originating BGP router.

In the scenario below, how does C know the originator G? because nexthop-self is in play.


The suggestion I raised was about avoiding bullet 4 from the following rfc7311 text:

The AIGP attribute may be added only to routes that satisfy one of the following conditions:

   -  The route is a static route, not leading outside the AIGPadministrative domain, that is being redistributed into BGP;
   -  The route is an IGP route that is being redistributed into BGP;
   -  The route is an IBGP-learned route whose AS_PATH attribute is empty; or
   -  The route is an EBGP-learned route whose AS_PATH contains only ASes that are in the same AIGP administrative domain as the BGP speaker

If we remove bullet 4, then C will not originate Ametric for the route originated by G in below scenario.

But yes, you need to consider the history of why this bullet was added in rfc7311, and if it is safe to remove.

2cs,

Thanks
Kaliraj


Juniper Business Use Only
From: Srihari Sangli <ssangli=[e-mail]>
Date: Friday, July 26, 2024 at 1:52 PM
To: Kaliraj Vairavakkalai <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: draft-ssangli-idr-bgp-generic-metric : Kaliraj's 2nd question follow-up
[External Email. Be cautious of content]

Hi, Folks:

Kaliraj and I had a separate chat and I’m summarizing it along with answering his question. Please see below.




Juniper Business Use Only


Juniper Business Use Only
From: Kaliraj Vairavakkalai <kaliraj=[e-mail]>
Date: Wednesday, 24 July 2024 at 9:29 PM
To: Srihari Sangli <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: draft-ssangli-idr-bgp-generic-metric : Kaliraj's 2nd question follow-up
[External Email. Be cautious of content]

> The RFC7311 and the generic-metric drafts states that Originating router (router that originates the route into BGP) should add the AMetric.

Srihari, in practice the ASBR can also add it. as far as I remember the current implementation.

Srihari> Let me take the snippet from the RFC7311 and respond based on that.

RFC7311 states these rules for Originating the AIGP attribute:
“The AIGP attribute may be added only to routes that satisfy one of the following conditions:

   -  The route is a static route, not leading outside the AIGP administrative domain, that is being redistributed into BGP;
   -  The route is an IGP route that is being redistributed into BGP;
   -  The route is an IBGP-learned route whose AS_PATH attribute is empty; or
   -  The route is an EBGP-learned route whose AS_PATH contains only ASes that are in the same AIGP administrative domain as the BGP speaker.
                            A BGP speaker R MUST NOT add the AIGP attribute to any route for which R does not set itself as the next hop.”


The first 3 (static, IGP and iBGP-learned route) are pertaining to the originating domain. Your question is related to the fourth item. Please look at the following topology.


                                           ------ B ------ D ------ F
                                          |
                                A ----
                                          |
                                          ------- C ------- E ----- G

Legend:

·         A-G are routers

·         F,G in same AS, they originate the prefix

·         A, B, C, D, E are in different ASes

·         All ASes are part of AIGP common administration domain
In this scenario, let’s assume the following happens:

·         F advertises the prefix with AIGP. The AIGP gets accumulated via D, B and reaches A.

·         G advertises the prefix w/o AIGP,  E propagates w/o AIGP.

·         If C adds AIGP before advertising the route to A.
If C can find the cost to reach the next hop (distance to G), then it can add AIGP encoding the cost to G. However, if E sets itself as next hop (which is typical at ASBR boundary), and C while adding AIGP, if it adds cost to E as the AIGP cost, then e2e accumulated cost is incorrect. Assuming costs are equal across ASes, A will end up always preferring path CEG over path BDF, which is not correct.

IMO, the RFC7311 had this clause to help deployment and also is not explicit about the encoding the cost to originating router’s next hop.

The draft-ssangli-idr-bgp-generic-metric follows base guidelines of RFC7311 and adds specific procedures for AMetric. I can clarify for the above case that an intermediate router can add AMetric if it can compute the cost to the next hop of the originating BGP router.

Please let me know if this addresses your question.

Thanks.

srihari…


Juniper Business Use Only