On Apr 9, 2012, at 2:50 PM, Robert Raszuk wrote:

> Hi,
> 
>> And intradomain BGP speakers do not use bgpsec (ebgp sessions only).
> 
> I do not understand. How a BGP Update will transit via an AS where each 
> router is a real BGP speaker and where as some proposed BGP mandatory AS_PATH 
> attribute is not present ?


I must admit I'm having a hard time parsing the question. I'll take a stab 
though... This answer may be unrelated to what you are asking...

When an update leaves a BGPSEC speaker destined for a "legacy" speaker the 
BGPSEC bits are removed

> 
> Are you assuming each AS today is BGP Free with full mesh of MPLS/IP tunnel 
> ASBR to ASBR as transport ? Even in this case ASBRs are connected directly or 
> indirectly (RRs) via IBGP.

Nope, not assuming that at all. The devices on the edge of the AS (those that 
do eBGP) need to speak BGPSEC, and if the AS is small, they will probably be in 
a full mesh. If the AS is not small (or has planned ahead :-)) they will talk 
to a RR or be part of a confed. If they talk through a RR (or set of RRs), 
these should also speak BGPSEC. If you prefer the confed flavor of scaling, 
well, the devices on the edge of the confed are kinda like eBGP speakers, and 
inside the confed they all mesh (or talk through a RR (see previous :-)))

> 
> As you proposing to remove AS_PATH selection criteria from best path for 
> updates which come over IBGP ?

Goodness, no....


> What happens if you need to compare paths received over EBGP and IBGP on a 
> given BGP speaker ?
> 
> Many thx,
> R.
> 

P.S: Crossposting left in, as it seems like that is what was wanted, but....

> _______________________________________________
> sidr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sidr
> 

_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to