Hi Wes, In-line with [Alia]
On Mon, Feb 2, 2015 at 1:38 PM, George, Wes <wesley.geo...@twcable.com> wrote: > 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> > Date: Friday, January 30, 2015 at 3:50 PM > To: "draft-ietf-sidr-as-migrat...@tools.ietf.org" < > draft-ietf-sidr-as-migrat...@tools.ietf.org>, "sidr@ietf.org" < > sidr@ietf.org> > Subject: AD review and progressing draft-ietf-sidr-as-migration-02 > Resent-To: <sa...@tislabs.com>, "George, Wes" <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? > [Alia] That sounds about right. > 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. > [Alia] Yes, if you could clarify it a bit that'd help. > > 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. > [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. >
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
