Subject: Re: [Idr] AD review and progression of draft-ietf-idr-as-migration-03

From: "George, Wes" <[email-masked]>
Date: Thu, 5 Feb 2015 16:06:43 -0500

Alia – ack and thank you for the review. Since your comments are more minor on this draft than the SIDR one, I will wait to make those changes when I incorporate any other IETF last call comments.

re: "existing BGP security mechanisms" - I want to make sure that I'm including the specific things you had in mind. Are we just talking about BGP session authentication and/or GTSM, or is there something else that I'm forgetting?

Thanks,

Wes

From: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 30, 2015 at 2:46 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Idr <[email-masked]<mailto:[email-masked]>>
Subject: AD review and progression of draft-ietf-idr-as-migration-03
Resent-To: <[email-masked]<mailto:[email-masked]>>, "George, Wes" <[email-masked]<mailto:[email-masked]>>

I have done my standard AD review of this useful and clear draft.

First, I would recommend strengthening the security considerations
with a reference to the existing BGP security mechanisms.

Second, based on a reading of RFC 3967 and how this draft uses the AS
numbers for an example, I believe that the reference should be informative.

Please handle these issues during IETF Last Call.

I'm putting this into IETF Last Call and on the IESG telechat for Feb 19.

Thanks for the good work!
Alia

________________________________
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: Alia Atlas <[email-masked]>
Date: Wed, 18 Feb 2015 17:35:45 -0500

Hi Wes,

On Thu, Feb 5, 2015 at 4:06 PM, George, Wes <[email-masked]>
wrote:

>  Alia – ack and thank you for the review. Since your comments are more
> minor on this draft than the SIDR one, I will wait to make those changes
> when I incorporate any other IETF last call comments.
>
>  re: "existing BGP security mechanisms" - I want to make sure that I'm
> including the specific things you had in mind. Are we just talking about
> BGP session authentication and/or GTSM, or is there something else that I'm
> forgetting?
>

Just those.
An updated version also addressing IESG comments would be good.

>  Thanks,
>
>
>
> Wes
>
>
>
>
>    From: Alia Atlas <[email-masked]>
> To: "[email-masked]" <
> [email-masked]>
> Cc: Idr <[email-masked]>
> Resent-To: <[email-masked]>, "George, Wes" <[email-masked]>
>
> ------------------------------
> 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: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 19 Feb 2015 13:58:42 +0000

On 2/18/15, 5:35 PM, "Alia Atlas" <[email-masked]<mailto:[email-masked]>> wrote:

Wes:

Hi!

I’m not sure if my comments (below) made it to you — they were part of my “AD training” for the current review period. ;-)

I  know it’s too late to change the structure of the document, so feel free to ignore those comments.  However, I would really like to see something in the text about the risk of potential loops..and the references to rfc4271 updated/corrected.

Thanks!

Alvaro.

======

I found the text a little hard to read: long sentences, the paragraphs include several ideas, etc..  The language is obviously ok, just feels heavy and complex (more than it has to be).

What I think would have been nice is to describe the migration scenario and functionality independent of the existing feature names first..and then say “BTW, the cisco features that do this are xxx..for Juniper yyy, etc.”.   Talking about specific features creates expectations that further implementations will do the exact same thing (specially when config snippets are included): as in the functionality documented at the cisco site (for example).   I started thinking of this when reading 4.1, where Juniper’s ‘Internal BGP Alias’ is discussed, and then the authors wrote: "NB: Cisco doesn't have an exact equivalent to "Internal BGP Alias", but the combination of the Cisco features iBGP local-AS and dual-as provides similar functionality.”..but the operation of dual-as and the differences are not discussed.

Other comments:

  *   The Introduction is very tentative about the purpose: it wants to document de facto standards for future implementations and so that new features (BGPSec) take them into consideration..but it is not expecting all implementation to follow exactly (at least not the existing ones).  My question is: should this be Informational instead of Standard?
  *   Nit: "ISPs bill customers based on the 95th percentile of the greater of the traffic sent or received, over the course of a 1-month period, on the customer’s access circuit.”  Not needed..this may of course change, etc..  The utilization point has been made.
  *   The use case Fig 1 and2, show customers C and D..but later, when explaining the features, CE-A and CE-B are used instead.  To make it easier to follow the same names would be nice.
  *   Potential loops!  Using "local-as no-prepend replace-as” results in eliminating an ASN from the AS_PATH..in the example, the Old_ADN (64510) is eliminated.  If other routers in ISP B have not been migrated yet (very real possibility) then they may accept Updates that already went through their ASN (64510).  To be fair, the text suggests that ISP B has been migrated to the New_ASN before applying the "local-as no-prepend replace-as” config..but I think that it would be important to describe the potential risk of using this feature — either as an Operational Consideration or in the Security section.
  *   The text uses "MY ASN” to indicate the ASN number in the BGP Open Message.  However, (1) there is no reference to rfc4271 so that the reader understand what they’re talking about, and (2) the field in the Open message is called "My Autonomous System” (not MY ASN).  This shows up in 3.3 and 4.2.
  *   Also in 3.3 (and 4.2), the Error Message “BAD PEER AS” is mentioned..  Again, no reference and wrong name.  The name used in rfc4271 is "Bad Peer AS”.
  *   Other rfc4271 related nits..  The draft talks about “updates”, but the official name is “UPDATE”.  Yes, maybe OCD, but I think it is important to be clear about what is being specified.  In some cases the use is mixed: “..it MUST process the update as normal, but it MUST append the configured ASN in the AS_PATH attribute before advertising the UPDATE..”.
  *   In 3.3 (last paragraph) the authors talk about the CLI implementation..  As they wrote: “..command syntax is an implementation detail beyond the scope of this document”.  Stay out of it.
  *   Because the external features (Section 3) assumes that the AS being migrated is already using the New_ASN before using local-as, I would like to see the internal features (Section 4) be discussed first in the text.  Just to keep a logical flow..
  *   4.1: s/typically to PE devices/typically connected to PE devices