Hi Russ,
> Doesn't this also impact 2 octet to 4 octet transition?
I thought about the same but I concluded that it does not. Due to
inherent day one design of BGP_SEC_PATH which supports 4 octet AS you
may carry it there as opposed to carry it AS4_PATH attribute.
> IMHO, this is a huge problem --much larger than we might imagine at
> this particular moment in time.
I think that the overall assumption is that we will fall back to non-sec
where ever and for whatever reason needed. With this in mind I am amazed
to see proponents of BGP Sec not caring about it as the end result will
be marginal to non BGP Sec deployment result.
For example IBGP speakers will not likely to get upgraded to BGPSec in
years to come. In traditional ISP this will immediately result in
downgrade. When you use RR you are a bit better as only RR needs to be
upgraded, but still this is light years for Internet wide deployment. As
example I know global SP networks which use full mesh.
I am therefor proposing SIDR overlay as smooth gradual introduction of
BGP SEC on subset of prefixes yet with full benefits of full blown BGP
Sec deployment. Maybe just for easy transition ... Of course this
requires Internet wide encapsulation so those allergic to it will not
like it :).
Best,
R.
- Extensibility to include new segment types. In principle this is a fairly
serious omission, but one can argue that new segment types can't be introduced
in practice, since existing implementations will treat them as fatal errors.
Doesn't this also impact 2 octet to 4 octet transition?
IMHO, this is a huge problem --much larger than we might imagine at this
particular moment in time.
Russ
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
