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" 
<wesley.geo...@twcable.com<mailto:wesley.geo...@twcable.com>>
Date: Monday, February 2, 2015 at 1:38 PM
To: Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>, 
"draft-ietf-sidr-as-migrat...@tools.ietf.org<mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>"
 
<draft-ietf-sidr-as-migrat...@tools.ietf.org<mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>>,
 "sidr@ietf.org<mailto:sidr@ietf.org>" <sidr@ietf.org<mailto:sidr@ietf.org>>
Subject: Re: AD review and progressing draft-ietf-sidr-as-migration-02
Resent-To: <sa...@tislabs.com<mailto:sa...@tislabs.com>>, "George, Wes" 
<wesley.geo...@twcable.com<mailto:wesley.geo...@twcable.com>>

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 <akat...@gmail.com<mailto:akat...@gmail.com>>
Date: Friday, January 30, 2015 at 3:50 PM
To: 
"draft-ietf-sidr-as-migrat...@tools.ietf.org<mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>"
 
<draft-ietf-sidr-as-migrat...@tools.ietf.org<mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>>,
 "sidr@ietf.org<mailto:sidr@ietf.org>" <sidr@ietf.org<mailto:sidr@ietf.org>>
Subject: AD review and progressing draft-ietf-sidr-as-migration-02
Resent-To: <sa...@tislabs.com<mailto:sa...@tislabs.com>>, "George, Wes" 
<wesley.geo...@twcable.com<mailto:wesley.geo...@twcable.com>>

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.
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to