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 protected]<mailto:[email protected]>> Date: Friday, January 30, 2015 at 3:50 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: AD review and progressing draft-ietf-sidr-as-migration-02 Resent-To: <[email protected]<mailto:[email protected]>>, "George, Wes" <[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/sidr
