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

[Alia Atlas <[e-mail]>]

Hi Wes,

In-line with [Alia]

On Mon, Feb 2, 2015 at 1:38 PM, George, Wes <[e-mail]>
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 <[e-mail]>
> Date: Friday, January 30, 2015 at 3:50 PM
> To: "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>
> Subject: AD review and progressing draft-ietf-sidr-as-migration-02
> Resent-To: <[e-mail]>, "George, Wes" <[e-mail]>
>
>  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.
>