Subject: [Idr] question about draft-ietf-idr-as-migration

From: "George, Wes" <[email-masked]>
Date: Wed, 12 Mar 2014 09:40:59 -0400

During the discussion of draft-ietf-idr-as-migration at IETF 89 (http://www.ietf.org/proceedings/89/slides/slides-89-idr-5.pdf), we got some feedback on the draft from a couple of speakers that we need to incorporate in the next revision that will hopefully get us set up for a WGLC on the document.

However, on the last slide, we also posed the question about the status of the draft (PS vs info vs BCP), and whether we should change the draft to reflect a more “standardized” way of implementing these features. In other words, the current draft explains how local-as, replace-as, and bgp-alias works, and has pointers to the vendor-specfic documentation for 3 different vendors’  implementations, but it includes no RFC2119 language that could be used as a definitive guide if a new vendor wished to implement these features, so in the strictest sense, it isn’t really standardizing this feature as much as it is documenting the fact that it exists and is used. Also, while it is certainly preferable to have some consistency between vendor implementations,  implementations do not technically need to interoperate, thus making 2119 language not strictly necessary.

So the question for the WG is whether you want to see this include 2119 language instead of or in addition to the existing descriptions in 3.1, 3.2 and 4.1, and if you want 2119 language, whether or not you would rather see this as a PS document instead of informational.
We didn’t get a lot of definitive guidance from the room, so we could use some feedback on list, since respinning the doc to include 2119 language is a non-trival amount of work that we’d prefer not to do unless the WG agrees that it’s necessary, and as a WG document, it’s not simply the authors’ call to make as to how we should proceed.

Thanks,

Wes and Shane

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

________________________________
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.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Mar 2014 10:26:36 -0400

On Wed, Mar 12, 2014 at 09:40:59AM -0400, George, Wes wrote:
> So the question for the WG is whether you want to see this include 2119
> language instead of or in addition to the existing descriptions in 3.1,
> 3.2 and 4.1, and if you want 2119 language, whether or not you would
> rather see this as a PS document instead of informational.

It'd take some digging, but I've seen references before that 2119 language
in non-standard-track docs is fine.  You're defining procedure and within
that procedure (even if the draft is experimental or informational), you
need to know how it is meant to behave.

With regard to the particular position in standards, I think the defining
context would be what impact you want this to have in SIDR.  From the scope
of non-secured BGP, the details are largely opaque and still conform to the
base BGP RFCs.  What happens within a given set of cooperating autonomous
systems stays inside those ASes.

The SIDR context of these changes is effectively how such "consent" is
expressed in the security mechanism.  In the presence of signature
mechanisms, the majority of these transition mechanisms break.

If your hope is that this document sets the stage to define either:
- Procedures by which cooperating parties can manipulate the signatures in
  bgpsec
- Define circumstances under which the cooperating parties *do not sign*
  across their common boundaries

then I think you have the leverage in this document to do so.

-- Jeff

---

From: "George, Wes" <[email-masked]>
Date: Wed, 12 Mar 2014 13:07:20 -0400

>need to know how it is meant to behave.
WG] Yes, I am aware that 2119 language is often used in info/BCP docs. I
should have been clearer in the questions. I think there’s a separate
question of whether 2119 language is necessary to properly document the
behavior, and then another about whether the doc needs to be a PS or info.
The two are related, but not completely.
>mechanisms, the majority of these transition mechanisms break.

WG] Well… draft-ietf-SIDR-as-migration covers how SIDR fixes this, but the
guidance we got from SIDR was basically that the WG agrees that this is a
problem and a use that they have to design for, but that it’s difficult to
expect changes to a standard to enable unstandardized implementation
things to keep working, thus the unstandardized implementation needs to be
documented elsewhere at IETF (IDR). Hence the normative reference to
IDR-as-migration from SIDR-as-migration. So now the question is really
about how to make the this IDR document the most helpful as the place
where this is documented, instead of simply a formality to allow SIDR
folks to maintain the purity of the assertion that they’re only
engineering to support actual BGP spec-compliant implementations.

Thanks

Wes George