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

[Srihari Sangli <[e-mail]>]

Kaliraj,

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

Srihari> That’s why I said that the above statement applies *if* it can compute the cost to the next hop. Like you say, if ASBR sets itself as next hop, then this clause is not applicable and hence C MUST not add AMetric. This is what I said I’ll clarify in the next rev of the draft.


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.


Srihari> Let us ask the IDR community the operators.

In the section 3.4.1 of RFC7311, it allows a router to add AIGP attribute to an EBGP-learned route whose AS_PATH contains only ASes that are in the same AIGP administrative domain as the current BGP speaker.

Does anybody know under what conditions this is allowed ?

srihari…


Juniper Business Use Only


Juniper Business Use Only