Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

[Edward Crabbe <[e-mail]>]

Yep, agree with MUST usage for 'the global internet", but not for arbitrary
ebgp peers, per Nick's mail.


On Thu, Dec 20, 2012 at 4:01 PM, Susan Hares <[e-mail]> wrote:

> Edward:****
>
> ** **
>
> +1 – that Certainly Acquisitions and ASN mergers will cause multiple
> private ASNs. ****
>
> ** **
>
> The draft’s text says :****
>
> ** **
>
> “ Private Use ASNs must be removed from the AS_Path before being
> advertised to the global Internet.”  ****
>
> ** **
>
> The question is not whether it goes out of a single Private ASN, but
> whether it cross the global Internet.  For example, if several private DCs
> band together to have a private exchange beyond the reaches of the global
> Internet, I have no reason to specify what happens with private ASN behind
> in those private party exchanges. ****
>
> ** **
>
> How do certain Acquisition and ASN mergers cause private ASN to cross the
> global Internet?  And why are these private AS not being hidden by a public
> AS or AS Confederation. ****
>
> ** **
>
> Sue ****
>
> ** **
>
> *From:* Edward Crabbe [mailto:[e-mail]]
> *Sent:* Thursday, December 20, 2012 6:34 PM
> *To:* Nick Hilliard
> *Cc:* Jon Mitchell; idr wg; Susan Hares
>
> *Subject:* Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00****
>
> ** **
>
> +1****
>
> ** **
>
> Acquisitions, ASN merges etc may all involve use of private ASN space
> between consenting parties.  I think this is a SHOULD.  ****
>
> ** **
>
> On Thu, Dec 20, 2012 at 3:02 PM, Nick Hilliard <[e-mail]> wrote:***
> *
>
> On 20/12/2012 22:38, Jon Mitchell wrote:
> > I'm comfortable making the change to a capital MUST for this sentence
> > and adding the appropriate reference to RFC 2119 as necessary.  I'm just
> > not comfortable telling operators how to perform that action as there
> > are a number of options to do so, which was my point to David (and he
> > seemed to be ok with).  I will make the changes as necessary to the
> > abstract where this statement exists as well.****
>
> If it's of interest, rfc 6666 ran into much the same issue recently with
> the issue of leaking the rtbh prefix to ebgp peers.  We decided on SHOULD
> rather than MUST because there probably were situations where there might
> be valid operational reasons for leaking the prefix to a peer. I would
> think the same arguments hold for a private ASN range.
>
> http://tools.ietf.org/html/rfc6666#section-5
>
> Nick****
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr****
>
> ** **
>