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

["George, Wes" <[e-mail]>]

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.

Thanks,

Wes

From: "Alvaro Retana (aretana)" <[e-mail]<mailto:[e-mail]>>
Date: Monday, March 23, 2015 at 11:18 AM
To: "George, Wes" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Review of draft-ietf-sidr-as-migration

Minor:

 1.  It would be nice to have some sort of road map in the Introduction.  Indicating that Section 3 presents the problem, 4 the requirements and 5 the solution itself.  Even though section 5 in in fact named ‘Solution’ it is not clear, at least not to me what the order of the document is; when reading section 3 I kept wondering to myself “what about the solution?”.

WG] isn't this what the table of contents is for? This isn't a long enough document that it really needs an "agenda slide"

 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.

 1.  3.1   The text sort of circles around a couple of scenarios and it finally settles on “a new ROA SHOULD also be created that authorizes AS64500”.  Shouldn’t it be a ‘MUST’?  In the same paragraph you make the point that the "validation check will fail unless a ROA is *also* available for AS64500”..  I’m guessing that the ‘SHOULD’ is used in case there are routes which AS64500 is not originating yet..but it is just confusing to me what exactly is intended.

WG] I changed it to MUST. Having an additional ROA isn't a big deal, and so even if those are all generated up front before migration starts for any prefixes, the right thing will happen.

 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.

 1.  Section 5.  You lost me here (end of the second paragraph): “. . .the most appropriate place to implement this is on the local PE that still has eBGP sessions associated with AS64510 (using the transition knobs detailed in the companion draft).  Since that PE has been moved to AS64500, it is not possible for it to forward-sign AS64510 with pCount=0 . . .”  You first said that the PE has sessions associated with AS64510, but then said that it had moved to AS64500, what am I missing?  Maybe you’re referring to a specific session..

WG] what I mean is that it still has peers expecting it to be 64510. Replaced "sessions associated with" with "sessions with peers expecting to peer with"

 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.

Nits:

 1.  Introduction.  Just a style preference:  get to the point faster.  Maybe something more direct like: “A method of managing an ASN migration not formally part of the BGP4 [RFC4271] protocol specification is described in [I-D.ietf-idr-as-migration].  Accordingly, it is necessary . . .”

WG] ack, some of that was a holdover from previous versions of the doc, cleaned it up

 1.  s/draft/document

WG] ack

 1.  Section 2.  s/Figure 1/Figures 1 and 2/    BTW, it would be nice (even if they’re referenced) to paste a copy of the figures.

WG] what say you, SIDR folks?

 1.  Section 3.  s/"The methods and implementation discussed in draft-ietf-idr-as-migration. . . widely used”/The functionality described in [I-D.ietf-idr-as-migration] is widely used

WG] ack

 1.  3.1  “origin validation” and “replace-as” need a reference.

WG] ACK

 1.  3.2.1 Reference for “BGPSec protocol specification”, and “remote-as”.

WG] fixed BGPSec, don't know what you'd like me to reference for remote-as.

 1.  s/AS Path/AS_PATH

WG] Generally, I used the all caps when referring specifically to the attribute, and AS Path for more generic instances meaning "a list of ASNs". If you want to point to specific areas of the text where the wrong one was used, I'll be happy to fix, but I'm not certain that globally switching to AS_PATH is the right thing to do.

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