Re: [Idr] draft-ietf-idr-best-external-03

[Pedro Marques <[e-mail]>]

Saikat,

On Mon, Mar 21, 2011 at 5:15 PM, Saikat Ray <[e-mail]> wrote:
> Hi Pedro:
>
> Thanks much for the response. It clears things up a lot. Could you please
> also answer the one question you missed ...
>
>   9. Suppose we have three member AS - 1, 2, 3 - in a confederation;
>      ASBRi is the Confed ASBR of member-AS i. At ASBR1, the path from
>      ASBR2 is the overall-bestpath.
>            Does the computation for "best internal" path, that ASBR1
>            sends to ASBR2, include paths from ASBR3 in its set of
>            "internal" paths?

Yes. In this scenario, when ASBR1 generates an update to ASBR2 it is
selecting the best of all its known paths that where not received from
member AS 2.

The same rule applies for route reflection. Consider the top level
iBGP mesh to be cluster-id 0; When advertising to a specific set of
peers, "best-external" selects the best route from the set of known
routes that has not been received from the same cluster-id as the
"target".

>
> I think the document should define the terms it is using more clearly.

I agree.

> Even
> terms like "AS Domain" and "RR Domain" are open to interpretations. E.g., a
> RR can have true EBGP peers. Then is it in an AS Domain or is it in an RR
> Domain? Maybe the best thing would be to have a paragraph in the appendix
> that describes the task of a given BGP speaker considering the full set of
> paths and all possible types of peers that can co-exist. E.g., a BGP speaker
> can have: (i) true EBGP peers, (ii) RR-client peers, (iii) non-client IBGP
> peers, (iv) member-AS IBGP peers, (v) non-member-AS confed EBGP peers. All
> such peers can co-exist (when the BGP speaker is both an RR and a Confed
> ASBR). If the behavior is undefined in some cases (e.g., RR+Confed ASBR
> combination), then that should be said.

The behavior is easy to define in pseudo-code:
   eligible-routes = RIB-In routes Excluding { cluster-id and
confed-as of peer }
   select the best of eligible routes.

Assuming that cluster-id of a non-client peer is 0; confed-as of non
confed eibgp peer is 0.

I agree with you. The existing text sort of mumbles it all together.

  Pedro.