On 3/31/15, 2:29 PM, "George, Wes" <[email protected]<mailto:[email protected]>> wrote:
Wes: Some replies below. Thanks! Alvaro. Added SIDR, responses below inline, which of course messed up your original numbering. I haven't pushed the rev yet, as I'm waiting to make sure that I don't need to make additional changes based on the revision to the BGPSec protocol doc. . . . 1. Section 3. s/SHOULD NOT/should not We can’t use rfc2119 language to mandate the behavior of an operator; in this case related to the amount of time the transition phase lasts. I think you have made a good point about the need to not stay there forever, but have also said that the transition is not always under the control of the operator. WG] I disagree with the blanket assertion that we can't normatively mandate the behavior of an operator in the context of a standard or BCP document, and I think that the guidance is correct here – operators SHOULD NOT stay in transition indefinitely. Should rather than must because we know that there are extenuating circumstances and acknowledging that we tried to keep it simple. 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. . . . 1. 3.2.1 s/MUST/must You’re making reference to something that is not specified in another document.. WG] right, I'm observing that the behavior is not normatively specified, hence the caps. I’m not sure if you’re agreeing with me or if you’re further justifying the use. 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? If so, then I see two ways forward: 1. Work to include that “MUST” in the BGPSec draft. And then reference it here. 2. Given that the BGPSec draft deals with the base BGP spec and that here we’re talking about the new mechanism from idr-as-migration, then change the text above to explicitly say what you want to happen (“MUST match”) and then this document would be eventually marked as updating the BGPSec base spec. [We might need to consider the order of processing of the documents through the IESG so that the update makes sense.] . . . 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. 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.
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
