Subject: [RTG-DIR] RtgDir Review: draft-ietf-sidr-as-migration-02

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Wed, 14 Jan 2015 23:52:42 +0000

Hello,

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-sidr-as-migration-02
Reviewer: Keyur Patel
Review Date: 14-Jan-2015
Intended Status: Standards Track

Summary:
No major issues found. Minor nits are listed below. This document is ready for publication.

Comments:
IMHO, the document is well written and easily understood.

Major Issues:
None.

Minor Issues
None.

Nits:

  1.  Section 2, General Scenario: Replace : Confederations RFC 5065 [RFC5065] are not being implemented between the ASNs with : BGP AS Confederation RFC 5065 [RFC5065] is not enabled between ASNs.
  2.  Section 2, General Scenario: For Line starting with (2nd paragraph): "In the following examples”, please list the section number where these examples are described (Section 4).
  3.  Section 3: Can we replace the reference of companies with SPs?
  4.  Section 3.1: Replace : Overlapping ROAs with multiple ROAs (its not overlapping ROAs its multiple ROAs showing different ASes owning originating prefixes)
  5.  Section 3.2.1: Isn’t the problem of increased ASPATH length explained in section 3.2.2 applicable to 3.2.1? If so can reference it in 3.2.1 as well?
  6.  Section 5.2:  Can we refer to the fact that this is the only case where an extra signing is done for before sending an update to an IBGP session?

Regards,
Keyur

---

From: "George, Wes" <[email-masked]>
Date: Thu, 22 Jan 2015 12:18:40 -0500

Keyur – Thanks for the review. Ack for most of the nits, responding to a couple inline below.

Thanks,

Wes

From: "Keyur Patel (keyupate)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 14, 2015 at 6:52 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [RTG-DIR] RtgDir Review: draft-ietf-sidr-as-migration-02
Resent-To: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "George, Wes" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>

Section 3: Can we replace the reference of companies with SPs?
WG] no, because it is equally applicable to two companies (say enterprises) that are merging their networks using AS Migration.

Section 3.2.1: Isn’t the problem of increased ASPATH length explained in section 3.2.2 applicable to 3.2.1? If so can reference it in 3.2.1 as well?
WG] It's not really applicable, because since the router has keys to sign outbound updates with either ASN, it can with one AS, the other AS, or both, depending on how it's configured, so if it's configured to replace the AS, there's no increase in the AS Path. In the opposite direction, the signing to one ASN (the old ASN) has already happened, so there's no avoiding an additional AS in the path during a migration.

Section 5.2:  Can we refer to the fact that this is the only case where an extra signing is done for before sending an update to an IBGP session?

WG] Doesn't the last sentence do this by highlighting the deviation from normal behavior? I can't say categorically that this is the only case, as at some point in the future there may be another. Best I could do is to say that "as of time of writing this is the only…" but I don't see how that adds much to what is already there. Open to discussion to the contrary, of course.

________________________________
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: "Keyur Patel (keyupate)" <[email-masked]>
Date: Thu, 22 Jan 2015 17:55:18 +0000

Hi Wes,

Thanks for the comments. My reply is inlined #Keyur

From: <George>, Wes <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 22, 2015 at 9:18 AM
To: Keyur Patel <[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]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-sidr-as-migration-02

Thanks,

Wes

#Keyur: It would be nice to maintain consistency for better readability. I suggest use either companies or Sps or something else that can represent both.

#Keyur: Ack. That makes sense.

#Keyur: The last sentence wasn’t that clear. I thought it was important as I don’t recall bgpsec signing ibgp updates (as of now in any other case). This would be a special one (as of now) :) .

Regards,
Keyur

---

From: "George, Wes" <[email-masked]>
Date: Thu, 22 Jan 2015 16:51:30 -0500

WG2] Ok, I see what you're saying now. I changed the first one to SPs as well, but added the following text at the end:
"Note: While this document primarily discusses service provider considerations, it is not solely applicable to SPs, as enterprises often migrate between ASNs using the same functionality. "

WG2] I reworded. How's this:
5.2 "When a PE router receives an update from an eBGP neighbor that is locally configured with AS-migration knobs (i.e. the opposite direction of the previous route flow), it MUST generate a signature from the old (local) ASN forward signing to the new (global) ASN with pCount=0. It is not necessary to generate the second signature from the new (global) ASN because the ASBR will generate that when it forward signs towards its eBGP peers as defined in normal BGPSec operation. Note that a signature is not normally added when a routing update is sent across an iBGP session. The requirement to sign updates in iBGP represents a change to the normal behavior for this specific AS-migration implementation only."

Wes

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Thu, 29 Jan 2015 20:07:33 +0000

Hi Wes,

Looks good to me.

Regards,
Keyur

Date: Thursday, January 22, 2015 at 1:51 PM

Wes