> From: Murphy, Sandra [mailto:sandra.mur...@sparta.com] > > No, I did not mean to suggest that there was an actual ebgp session. I > think maybe I was reading the replace-as example incorrectly. I am not > sure what the AS_PATH is when it is transmitted between PE1 and PE2 and > it looked like PE1 might be adding ASNs to the AS_PATH it sent over the > ibgp session to PE2. [WEG] I think maybe the confusion comes from the fact that these commands have to interact with BGP route updates in both directions (PE-> CE and CE -> PE). In the routes that the PE receives from the CE, it has to make the change in AS in the AS_PATH so that the rest of the routers in its global ASN don't see routes with the configured local ASN in the path, but the way I think of it is that it's doing this when it receives and processes the routes from the CE before it installs them into its RIB, not when it generates the updates towards its neighbors, since this is a neighbor-specific configuration rather than a global one.
> > I think this is already a MUST in the protocol because the protocol > makes sure the AS listed are the ones that the packet came through. If > the update came from the neighbor and the first AS in the path is not > the neighbor's AS, then the validation will fail. (Unless the neighbor > has the keys to two ASs and uses an AS other than is used in the OPEN > packet. It's all about the keys.) [WEG] Understand that. I was specifically asking about the case where the PE is in possession of keys for both ASNs and therefore can choose which of the two valid ASNs to sign with. Does it fail if the signature is valid but the AS in the OPEN message is different from the one in the signature? If not, should it, or are we expecting similar behavior to the "enforce-first-AS" keyword, where by default it fails, but you can twist a knob to make it acceptable? I think this is one of those things that we have to be clear about which way we want the behavior to be, since it's a MAY in BGP. It is even more important to specify if it has to be a certain way in order to prevent security concerns in BGPSec. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
