More inline Thanks,
Wes From: "Alvaro Retana (aretana)" <[email protected]<mailto:[email protected]>> Date: Thursday, April 9, 2015 at 2:57 PM To: "George, Wes" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: Review of draft-ietf-sidr-as-migration rfc2119 says, about the keywords: "MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm”. While I completely agree that the transition shouldn’t take forever, the use that you’re proposing doesn’t have anything to do with interoperability, nor will taking longer than expected/usual actually causes harm from the specification point of view. Yes, the operator will have to deal with a cumbersome configuration/deployment, but the knobs in this case are specified "to keep the additional complexity during the transition period to a minimum”. To all this, how would you even determine if someone was not adhering to the recommendation? Do you measure the time in days, weeks, months, years? I’m sure that the transition timeframe is very dependent on the network/deployment/operations and probably many other things I haven’t even thought about. WG] well, I'll be honest, the philosophy behind 2119 words isn't a hill I'm willing to die on. If it is for you, that's fine and I'll change it, but I've read plenty of IETF documents that are pretty liberal in their interpretation of harmful as justification for using normative words – it isn't limited simply to the protocol and unless we start explicitly prohibiting 2119 language outside of protocol specs, you're going to have this argument with a lot of people I think. As for enforcement, this isn't tied to an elapsed time, and I don't even really understand what enforcement means in this context – how does IETF enforce anything, especially outside of protocol interop? I’m not sure if you’re agreeing with me or if you’re further justifying the use. WG] justifying. The section we’re talking about reads: 3.2.1. Outbound announcements (PE-->CE) When PE1 is moved from AS64510 to AS64500, it will be provisioned with the appropriate keys for AS64500 to allow it to forward-sign routes using AS64500. However, there is currently no guidance in the BGPSec protocol specification on whether or not the forward-signed ASN value MUST match the configured "remote-as" to validate properly. That is, if CE1's BGP session is configured as "remote-as 64510", the presence of "local-as 64510" on PE1 will ensure that there is no ASN mismatch on the BGP session itself, but if CE1 receives updates from its remote neighbor (PE1) forward-signed from AS64500, there is no guidance as to whether the BGPSec validator on CE1 still consider those valid by default. RFC4271 [RFC4271] section 6.3 mentions this match between the ASN of the peer and the AS_PATH data, but it is listed as an optional validation, rather than a requirement. Assuming that this mismatch will be allowed by vendor implementations and using it as a means to solve this migration case is likely to be Problematic. Sounds to me that you want BGPSec to say that the values MUST match, is that correct? WG] No. In that section, I'm still reviewing the problem and options to solve the problem. The key is in the last sentence of what you quoted above. In other words, in theory you might be able to get away with the first AS in the AS_PATH deviating from the configured remote_AS on some liberal implementations, but it's probably not valid to assume that all implementations will make this work, because the spec doesn't provide normative guidance saying that it MUST. 1. 5.3 "While this is not prohibited by BGPSec [I-D.ietf-sidr-bgpsec-protocol], routers that receive updates from iBGP neighbors MUST NOT reject updates with new (valid) BGPSec attributes..” Does this represent an update to BGPSec? Are you implying that the iBGP receiver should check the validity of the attributes? I know that at this point it is a little weird to update a draft (not an RFC), but the process should take care of the appropriate references. [Maybe the update is not needed based on the discussion in the WG today.] WG] what this is saying is that BGPSec is currently silent on this, and making an update to clarify what the behavior needs to be. As to whether the updates need to be validated in iBGP, I'm not explicitly requiring that, as I think it's really more of an implementation detail. Ok, so it is an update to BGPSec. This is important because the header should say so and I would like to see a section that summarizes the updates. WG] we'll have to see how this settles out once the next rev of the BGPSec protocol draft is done to harmonize text between the two documents. I think the normative text is pretty self-explanatory about what it's updating in the base BGPSec spec, because it only exists in sections 4 and 5, but if I find places where I should be more explicit, I will try. As far as the iBGP validation, I think the word “valid” is what was throwing me off. You mean valid as in well formed, etc. WG] yes, I can probably clarify that. ________________________________ 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 [email protected] https://www.ietf.org/mailman/listinfo/sidr
