Subject: [RTG-DIR] RtgDir review: draft-ietf-idr-as-migration-02

From: Thomas Morin <[email-masked]>
Date: Fri, 12 Sep 2014 11:38:39 +0200

Hello,

In the context of Routing Area QA reviews (see 
https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ), I have 
been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see ​ 
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-idr-as-migration-02 
<http://tools.ietf.org/html/draft-name-version>
Reviewer: Thomas Morin
Review Date: 2014-09-11
Intended Status: standards track

*Summary:* I have some minor concerns about this document that I think 
should be resolved before publication.

*Comments:
*

This is overall a very well written document, with a clear goal and 
concisely addressing its target goal.*
*
Although it is all about local behavior, it makes sense to make a 
standard track document that (a) can be used as a reference for 
implementors and deployers to implement this properly, and (b) keep 
track of these features in future evolutions of the protocol (as 
motivated in the Conclusion section of the document).*
*

*Major Issues:*  No major issues found

*Minor Issues:
*

A) The introduction says:

    In particular
    the ISP would have to encourage those customers to change their CE
    router configs to use the new ASN in a very short period of time,
    when the customer has no business incentive to do so.  Thus, it
    becomes critical to allow the ISP to make this process a bit more
    asymmetric, so that it could seamlessly migrate the ASN within its
    network(s), but not disturb existing customers, and allow the
    customers to gradually migrate to the ISP's new ASN at their leisure.

However, I did not understand which part of the specs would allow the 
customer to change its CE
configuration without coordinating a maintenance window with the ISP. 
Procedures in section 3, as  described, won't let the customer CE 
connect to the router with the new ASN. See, in particular in the second 
§ of section 3.3: "The speaker MUST NOT use the ASN configured globally 
within the BGP process as the value sent in MY ASN in the OPEN message. 
". It seems that the goal specified in the intro will thus not be met fully.

Two things would be possible: fixing the intro to state a slightly 
different goal, or change the procedures to let a router establish a 
session with the globally assigned new AS, even when 'local-as old-AS" 
is configured. I'm not expert enough to know if the latter would work.

B) still about the intro: it seems that this intro is focused on the 
motivation for eBGP-related features described in section 3, but silent 
on iBGP and section 4

C) in section 3, second §, there is a discussion about changing the 
AS_PATH length ; it seems to me that there is a hidden assumption on 
what interconnection exist between ISP A and ISP B prior to the 
migration ; the text says "whereas the same RIB on ISP A' would contain 
AS_PATH: 64510 64496, which is an increase in AS_PATH length from 
previously" which seems to indicate that ISP A and ISP B are peering 
with each other. If this is correct, this should be stated clearly in 
section 2, and not be a hidden assumption.

D) in section 3: " Thus, within Loc-RIB on ISP B' the AS_PATH toward 
customer C would appear as: 64510". I would have thought that the 
AS_PATH of routes learned by PE routers of ISP B in this situation (if 
local-as no-prepend is not used), would be "64496" or "64510 64496" 
rather than "64510" alone... but I could just be wrong.

E) In section 2, third paragraph:

    First, ISP B, will change the global BGP ASN used by
    a PE router, from ASN 64510 to 64500.  At this point, the router will
    no longer be able to establish eBGP sessions toward the existing CE
    devices that are attached to it and still using AS 64510.

    Second,
    ISP B will configure two separate, but related ASN migration features
    discussed in this document on all eBGP sessions toward all CE
    devices.  These features modify the AS_PATH attribute received from a
    CE device when advertising it further, and modify AS_PATH when
    transmitted toward CE devices to achieve the desired effect of not
    increasing the length of the AS_PATH.

This high level description of the procedures in 3 is I think missing a 
description of the fact that, among the features of step 2 there is also 
a feature, not related to fixing the as path, that aims at allowing BGP 
sessions to be established using ASN 64510.
I would suggest rewriting the last sentence as:

    These features allow the establishment of sessions with the legacy ASN 64510,
    modify the AS_PATH attribute received from a CE device when advertising it further,
    and modify AS_PATH when transmitted toward CE devices to achieve the desired effect of not
    increasing the length of the AS_PATH.

F) section 3.1: it would be worth mentioning it explicitly, at the end 
of the first paragraph, that alone, this change results in an 
interruption of service

G) the naming given to ASs and routers along the document**could I think 
be largely improved to make the document easier to read. I would suggest 
the following:
* In the figures 3 and 4 of section 3.1 and 3.2:  invert the figure 
left-right to have AS64499 on the left like in figures 1 and 2
* In the figures 3 and 4 of section 3.1 and 3.2, and associated text: 
instead of naming the PEs and CEs  with 1 and 2, name them with A and B 
to match the ISP they are into (PE-A,CE-A,PE-B,CE-B instead of 
PE-2,CE-2,PE-1,CE-1)
* modify figures 1 and 2 to make PE-A,CE-A,PE-B,CE-B appear on the figures
* preferring "ISP A PE routers" to  "ISP A's PE routers" to increase 
readability, or just "PE-A" or "PE-B"  which is even shorter and less 
confusing  (as an illustration section 3.2 says "Specifically, with 
'Local AS No Prepend' enabled on ISP A's PE-1, it automatically 
causes..." , but does it mean "ISP A PE-1" or "ISP A' PE-1"...? given 
that PE-1 is actually in ISP B (==ISP A'), this is probably the second 
which is true, but here incorrectly written as "ISP A's PE-1"...)
* section 3.1 mentions ISP B' ("within Loc-RIB on ISP B' the AS_PATH 
toward...") , but what ISP B' can only be guessed, you may want to 
define it in section 2(the set of routers in ISP B after the AS migration)

H) section 3.2 says "Instead, only the historical (or legacy) AS will be 
prepended in the outbound BGP UPDATE toward customer's network, 
restoring the AS_PATH length to what it what was before AS Migration 
occurred." ; I would suggest adding ", as configured with the 'Local AS' 
feature described in section 3.1,"   before "will be prepended"

I) I know the 'PE'/'CE' terminology to be widely used in the context of 
BPG-based VPNs, but, unless it is also widely used for non-VPN use 
cases, I would think that defining these terms would make sense (I don't 
know these terms to be widely used outside VPN use cases, but well, they 
might be in which case nothing is needed)

J) the last § of section 3.1 looks to me as very much redundant to what 
is said in the rest of the section

K) section 4.1  "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."  -- This sentence would be 
better-placed in section 10, IMO.

L) section 4.1, itemized list, item 4: a reference to section 3 would be 
nice

M) section 10: it would be interesting to indicate, for each vendor, 
what are the feature names corresponding to what is described in 
sections 3.1, 3.2 and 4

*Nits:*

- In the abstract: s/feaures/features/
- In the abstract: the title would be more readable without "(AS)"; 
introducing this acronym, along with "ASN" can be done for instance in 
the introduction
- in 3.1:  "ISP B needs to do this without coordinating the change of 
its ASN with all of its eBGP peers, simultaneously."  is not very easy 
to read (maybe "ISP B needs to be able to do this without coordinating a 
simultaneous change... peers" would be better?)
- in 3.1: "Within the context of ISP B's PE router, The second effect 
..."  -> s/The/the/

Best,

-Thomas

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Sep 2014 10:43:52 -0400

> motivated in the Conclusion section of the document).*

My personal concern about making this a proposed standard is several of
these mechanisms are not fully implemented even across the surveyed vendors.
In many cases, there are differing implementations that serve similar needs
but are slightly different to accommodate the implementation.  This is
despite the fact that, from a vendor standpoint, the features are internally
mature.  If there were strong motivations to move to a specific other-vendor
transitional mechanism, it likely would have been done by now.

To some extent, a proposed standard suggests that a given mechanism should
be implemented.  The current informational status says "this is what has
been done".

-- Jeff

---

From: "George, Wes" <[email-masked]>
Date: Mon, 15 Sep 2014 11:02:13 -0400

>be implemented.  The current informational status says "this is what has

WG] I've struggled with this problem throughout the writing of this draft.
As I noted in Toronto, there was significant discussion among a couple of
my offline reviewers about the terminology used, since some of it is
specific to one vendor vs another. I believe the document captures what
would be necessary for a *new* implementation. While not all existing
implementations may have implemented all of the features exactly as
described here, if one were implementing from scratch, it may be easier to
use this as a baseline instead of trying to copy or reverse-engineer a
vendor-specfic implementation.
I'm open to adding some additional text to make it clear that this is
simply documenting a reference implementation that can be used for new
implementations, but that it does not imply a requirement to modify
existing implementations to harmonize them with this standard.
The document does say in more than one place that interoperability is not
a requirement because the features are all locally significant, but if you
have a suggestion for text to make this clearer, I'm happy to incorporate
it.
The only other thing I can think of here would be to have a more in-depth
comparison between the different vendor implementations, but I don't see
the point in doing that since I'm already pointing to the vendor
documentation, and comparing implementations doesn't seem appropriate for
a document like this.

Thanks,

Wes

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: "George, Wes" <[email-masked]>
Date: Mon, 15 Sep 2014 12:44:36 -0400

Thanks for the thorough review. My responses below inline.

>configuration without coordinating a maintenance window with the ISP.

WG] well, that is not exactly what the above says. The idea was to make a
distinction between a globally coordinated window between all customers on
the router (symmetric change) vs being able to coordinate individually
(asymmetric). I do see your point though, and I can make it more explicit.

>is configured. I'm not expert enough to know if the latter would work.

WG] I'd refer you to section 4.2, which allows a more flexible
configuration that can establish a session using either old or new ASN.
While it's discussed in the iBGP section, the text does note that this
could be done whether in iBGP or eBGP.

>motivation for eBGP-related features described in section 3, but silent
WG] In my mind, eBGP is the primary motivator for this draft due to the
external coordination/AS-path lengthening problems. iBGP is a happy upshot
to the functionality, so I didn't see the need to add that in the intro.
I'll make a pass through to see if I can fix this with a minimal addition.

>section 2, and not be a hidden assumption.

WG] ack, need to make it clear what we mean by "previously"

>rather than "64510" alone... but I could just be wrong.

WG] This is describing the AS_PATH pre-migration, and then showing what
happens during migration. I think I can clarify.

>    increasing the length of the AS_PATH.

WG] ack
>of the first paragraph, that alone, this change results in an

WG] ack
>left-right to have AS64499 on the left like in figures 1 and 2
WG] I understand the parallelism/symmetry that you're suggesting, but
flipping the ASNs would require rewriting a substantial amount of the
example. I think you're suggesting mirror image, which would leave the
example text unchanged, but assumes that everyone is ok with the arrows
pointing right to left in fig 3, and then left to right in fig 4, as well
as PE2/CE2 showing on the left, PE1/CE1 on the right in both, which is
sort of backward from western convention and confusing for a different
reason. I think I'm going to offend a different set of aesthetics with
either one, and I'm not sure it makes a great deal of difference in the
readability of the figures. Open for further discussion.

>* modify figures 1 and 2 to make PE-A,CE-A,PE-B,CE-B appear on the figures

WG] I don't think that this would be helpful since you're not consistently
dealing with ISP A or B during the migration, but rather A', which is an
amalgam of all of ISP A and the part of ISP B that has been subsumed by
ISP A. I think using A or B would confuse things, since in post-migration
what you end up with is 2 PEs in the same ISP.

>which is true, but here incorrectly written as "ISP A's PE-1"...)
WG] good point. I'll make a pass through to eliminate the use of
possessive (A's) when I'm also talking about ISP A prime (A') to reduce
the confusion.

>define it in section 2(the set of routers in ISP B after the AS migration)

WG] that's an editing error, originally the sentence was "ISP B's..."
(possessive) and the apostrophe appears to have been left behind when the
sentence was reworded to eliminate the possessive.

>feature described in section 3.1,"   before "will be prepended"
WG] ack
>might be in which case nothing is needed)
WG] I can certainly explode the acronym on first use (in section 2) but
the use of those terms isn't intended to invoke any special VPN functions,
merely to represent the difference between the provider's router (Provider
Edge) and the customer's (Customer Edge). Is there an alternate set of
terms that would be more appropriate?

>is said in the rest of the section
WG] I consider this ("As a result...") part of the example and text
supporting the figure, so I think it should probably stay there. I do see
the repetition with the earlier paragraph (beginning with "As stated
previously...") so I think actually I should pull the "As stated
previously" paragraph instead. I got some offline feedback that this draft
is wordy, so I will try to make an editing pass with this in mind once
I've incorporated the other feedback.

>better-placed in section 10, IMO.
WG] this is called out here for clarification because in many of the
examples, cisco terminology and CLI are used, but could not be used here.

>L) section 4.1, itemized list, item 4: a reference to section 3 would be
WG] ack
>what are the feature names corresponding to what is described in
WG] interesting perhaps, but unless the WG really believes it's necessary,
I don't think that's something I want to undertake here, since IMO it adds
little to the objective of the draft (documenting the feature so that it
could be implemented by someone that doesn't have an implementation
already, and formalizing it as a part of BGP so the feature doesn't get
broken by future changes to BGP). The vendors are of course free to either
write their own documentation mapping things to this document, or to
provide text for me to add here ;-)

>- in 3.1: "Within the context of ISP B's PE router, The second effect
WG] ack

Thanks,

Wes George

---

From: Thomas Morin <[email-masked]>
Date: Tue, 16 Sep 2014 11:12:47 +0200

Hi George,

> Thanks for the thorough review. My responses below inline.

Comments below.
(skipping stuff that is ok already)

> could be done whether in iBGP or eBGP.

Well, referring me, in this email, to section 4.2 won't improve the 
document itself. :)

This question of avoiding any coordinated maintenance window between two 
eBGP peers is I think important enough to deserve being explicitly 
addressed as a target in the intro, and with a solution mentioned in 
section 3 (which could say, at the right place: "At this step, to let 
CEs still configured with the legacy ASN establish sessions, the PE can 
be configured to enable the 'Internal BGP Alias' function described in 
section 4.2").

> happens during migration. I think I can clarify.

(Note that given the position in the text, the context of this quoted 
does *not* seem to be pre-migration, but rather during migration.)

> readability of the figures. Open for further discussion.

If I may insist: having left and right inverted between fig 1/2 and fig 
3/4 is (a) really confusing at first, (b) independent of any 
left-to-right convention, and (c) bogus for every reasonable sense of 
aesthetics.  Inverting left-to-right in fig.1 and fig.2 would just 
consist in changing 8 chars total, and would fix that.

(changing the direction of arrows in 3.1 and 3.2 would be IMHO an 
acceptable alternative: I don't think there's anything backward wrt. to 
any western convention in that)

> what you end up with is 2 PEs in the same ISP.

Having to refer to the figure, while reading the text, to find out which 
of PE1/PE2 was in ISP B/ISP A was a significant overhead for me.

If it is written clearly that PE-A/PE-B are respectively PEs that were 
before migration in ISP A/ISP-B, I think the confusion with respect to 
the ISP A' notation will go away.

> possessive (A's) when I'm also talking about ISP A prime (A') to reduce

I think you should remove the possessive "'s" in all occurrences .

> terms that would be more appropriate?

I guess the right term would be ASBR, but that is symmetric, and not a 
helpful terminology for your examples.

Expanding on first use, and explaining that you re-use terminology from 
RFC4364 by convenience would I think be good enough.

> I've incorporated the other feedback.

Yes, these sections are very wordy; the document will be better if you 
can avoid repeats.

> examples, cisco terminology and CLI are used, but could not be used here.

If I read correctly, section 3 uses a Cisco feature name "local-as" and 
section 4 a Juniper feature name. However, Section 2 says "The examples 
cited below use Cisco IOS CLI for ease of illustration purposes only.".

You could sort this out by saying, section 2 "The examples cited below 
use specfic vendors CLI feature names for ease of illustration purposes 
only (Cisco IOS in Section 3, Juniper JunOS in Section 4)".  And then 
move the "NB" note in section 10... ?

> provide text for me to add here ;-)

Ok, fair enough.

-Thomas