Subject: Re: [sidr] Review of draft-ietf-sidr-as-migration

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 9 Apr 2015 18:57:11 +0000

On 3/31/15, 2:29 PM, "George, Wes" <[email-masked]<mailto:[email-masked]>> 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.

---

From: "George, Wes" <[email-masked]>
Date: Thu, 9 Apr 2015 16:13:27 -0400

More inline

Thanks,

Wes

From: "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 9, 2015 at 2:57 PM
To: "George, Wes" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Review of draft-ietf-sidr-as-migration

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?

WG] justifying.

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.

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.