Subject: Re: [sidr] AD review and progressing draft-ietf-sidr-as-migration-02

From: "George, Wes" <[email-masked]>
Date: Mon, 2 Feb 2015 13:38:53 -0500

Alia – thanks for the review. Consider this ACK for all comments except the ones below, inline with WG]
I have a –03 draft in the edit buffer, and will publish once the below is resolved.

Thanks,

Wes

From: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 30, 2015 at 3:50 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: AD review and progressing draft-ietf-sidr-as-migration-02
Resent-To: <[email-masked]<mailto:[email-masked]>>, "George, Wes" <[email-masked]<mailto:[email-masked]>>

a) Language around draft-ietf-idr-as-migration is more tentative than is appropriate
when that draft and this are going to be RFCs.  Please clean that up.

WG] other than removing the first paragraph of section 4 (done), and fixing the intro (removed de facto), were there other places that this needs to be addressed?

b) In Sec 3.1, it says

"If the route now shows up as originating
   from AS64500, any downstream peers' validation check will fail unless
   a ROA is *also* available for AS64500 as the origin ASN, meaning that
   there will be overlapping ROAs until all routers originating prefixes
   from AS64510 are migrated to AS64500."

I think the second AS64500 should be AS64510.

WG] no. This is saying that a ROA already exists for 64510, but needs to exist for 64500. The distinction the second half of that section is making is that in addition to generating a ROA for 65400 for any prefixes originated by the router being moved, because of replace-AS, you may have to generate ROAs for 65400 for routes that are originating on routers still in 65410. If that explanation is any clearer, I can try to edit the text to reflect this.

e) In draft-ietf-idr-as-migration, the case of handling AS migration in iBGP sessions is also covered.  I assume that because it is iBGP sessions, there is no work to be done for BGPsec.  Could you please add a quick obvious statement to that effect?

WG] hmm. This solution was originally written before the iBGP stuff was added, and it didn't occur to me that it may need to be discussed here. Pitfalls of two largely parallel docs, I guess.
The iBGP AS migration discussed is basically just listening for open on either ASN, but otherwise treats the session as iBGP even if the ASN is not the same as the globally-configured one. Thus there are two ASNs involved, and this is mainly the same as AS migration with eBGP, in that the migrating router would need to have a pcount=0 from old ASN to New in order to hide that path in routes that are signed to the old ASN from downstream eBGP peers. The wrinkle is that instead of the migration point being on the edge router between its eBGP peers and its iBGP peers, the migration point is now one router upstream, between two iBGP peers (i.e. The router in the old ASN doesn't necessarily know to mask its global ASN with pcount=0, and so the router that is at the actual border between the two ASNs will have to do the pcount=0 trick to the "iBGP" updates it receives. I'll need to add some text in 5.3 to cover this case. Good catch.

________________________________
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: Tue, 3 Feb 2015 15:30:46 -0500

update: I added the following text at the end of section 5.3 to cover Alia's question about iBGP AS migration. Let me know whether this is acceptable:

Additionally, section 4 of draft-ietf-idr-as-migration discusses methods in which AS migrations can be completed for iBGP peers such that a session between two routers will be treated as iBGP even if the neighbor ASN is not the same ASN on each peer's global configuration. As far as BGPSec is concerned, this requires the same procedure as when the routers migrating are applying AS migration knobs to eBGP peers, but the router functioning as the "ASBR" between old and new ASN is different. In eBGP, the router being migrated has direct eBGP sessions to the old ASN and signs from old ASN to new with pCount=0 before passing the update along to additional routers in its global (new) ASN. In iBGP, the router being migrated is receiving updates (that may have originated either from eBGP neighbors or other iBGP neighbors) from its downstream neighbors in the old ASN, and MUST sign those updates from old ASN to new with pCount=0 before sending them on to other peers.

Thanks,

Wes

From: <George>, "George, Wes" <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 2, 2015 at 1:38 PM
To: Alia Atlas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: AD review and progressing draft-ietf-sidr-as-migration-02
Resent-To: <[email-masked]<mailto:[email-masked]>>, "George, Wes" <[email-masked]<mailto:[email-masked]>>

Thanks,

Wes

b) In Sec 3.1, it says

---

From: "George, Wes" <[email-masked]>
Date: Wed, 4 Feb 2015 14:24:01 -0500

I went ahead and pushed a revision that covers Alia's and Keyur's reviews.

Thanks,

Wes

Date: Tuesday, February 3, 2015 at 3:30 PM

Thanks,

Wes

Thanks,

Wes

b) In Sec 3.1, it says

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Feb 2015 17:15:48 +0100

has the wg really looked at 5.2 and 5.3 with respect to how the ibgp
hacks affect the bgpsec spec?

randy

---

From: "George, Wes" <[email-masked]>
Date: Sat, 7 Feb 2015 09:34:17 -0500

I posed some questions about this in my WGLC review of bgpsec spec, but
haven't heard anything back. Current schedule has this being evaluated by
IESG prior to our next meeting. If we need to discuss during the meeting
in Dallas, we could certainly delay processing of the document. It has a
normative block on the bgpsec spec, so it's not like it's getting
published right away anyway.

Thanks,

Wes

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 7 Feb 2015 13:03:03 -0500

sounds like a good topic for the mic/front/preso in dallas... to me at least.

On Sat, Feb 7, 2015 at 9:34 AM, George, Wes <[email-masked]> wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Alia Atlas <[email-masked]>
Date: Mon, 9 Feb 2015 13:31:10 -0500

Hi Wes,

In-line with [Alia]

On Mon, Feb 2, 2015 at 1:38 PM, George, Wes <[email-masked]>
wrote:

>    From: Alia Atlas <[email-masked]>
> To: "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> Resent-To: <[email-masked]>, "George, Wes" <[email-masked]>
>
>  WG] other than removing the first paragraph of section 4 (done), and
> fixing the intro (removed de facto), were there other places that this
> needs to be addressed?
>

[Alia] That sounds about right.

>  WG] no. This is saying that a ROA already exists for 64510, but needs to
> exist for 64500. The distinction the second half of that section is making
> is that in addition to generating a ROA for 65400 for any prefixes
> originated by the router being moved, because of replace-AS, you may have
> to generate ROAs for 65400 for routes that are originating on routers still
> in 65410. If that explanation is any clearer, I can try to edit the text to
> reflect this.
>

[Alia] Yes, if you could clarify it a bit that'd help.

>  WG] hmm. This solution was originally written before the iBGP stuff was
> added, and it didn't occur to me that it may need to be discussed here.
> Pitfalls of two largely parallel docs, I guess.
> The iBGP AS migration discussed is basically just listening for open on
> either ASN, but otherwise treats the session as iBGP even if the ASN is not
> the same as the globally-configured one. Thus there are two ASNs involved,
> and this is mainly the same as AS migration with eBGP, in that the
> migrating router would need to have a pcount=0 from old ASN to New in order
> to hide that path in routes that are signed to the old ASN from downstream
> eBGP peers. The wrinkle is that instead of the migration point being on the
> edge router between its eBGP peers and its iBGP peers, the migration point
> is now one router upstream, between two iBGP peers (i.e. The router in the
> old ASN doesn't necessarily know to mask its global ASN with pcount=0, and
> so the router that is at the actual border between the two ASNs will have
> to do the pcount=0 trick to the "iBGP" updates it receives. I'll need to
> add some text in 5.3 to cover this case. Good catch.
>

[Alia] Thanks - looking forward to it.

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: Mon, 9 Feb 2015 13:35:59 -0500

I've passed the draft back to the WG.  When the necessary conversation and
WGLC has occurred again,
I'll be happy to progress it quickly.

Thanks,
Alia