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

[Robert Raszuk <[e-mail]>]

Pradosh,

I think mixing Internet routing with L3VPNs with DCs etc .. in this
discussion is completely not that much helpful.

Likewise if we go the path to mandate listing concerns and various
deployment scenarios the odds that this document will proceed is quite
low.

IMO this document should just reserve the new private AS space leaving
all other aspects of it's use to the autonomy and freedom of local
operators.

Rgs,
R.


> On Wed, Dec 5, 2012 at 10:55 PM, Pradosh Mohapatra (pmohapat) <[e-mail]> wrote:
>
> Robert,
>
> It may not be the same ISP (think of inter-AS VPNs).
>
> Again, as I said, I would like this to be spelled out in the document in
> more detail - what problems we envision and what the guidelines are.
>
> - Pradosh
>
>
> On 12/5/12 1:51 PM, "Robert Raszuk" <[e-mail]> wrote:
>
>>Pradosh,
>>
>>It is ISP 101 to provide BGP peer configuration by specifying peering
>>AS number.
>>
>>If ISP does it in the same time he needs to apply appropriate policy
>>reg handling or propagation of such AS.
>>
>>Simple as this.
>>
>>If you say that ISP is not aware that his old "remove-private-as" knob
>>will not remove newly defined 4 octet private AS range I think such
>>ISP should go back to class.
>>
>>Cheers,
>>R.
>>
>>> On Wed, Dec 5, 2012 at 10:45 PM, Pradosh Mohapatra (pmohapat)
>>><[e-mail]> wrote:
>>>>I think both Tony and Jay forgot that routing and reachability is not
>>>>about originator AS .. it is about prefixes they advertise.
>>>>
>>>>If peering ISP AS chooses to peer with private as or remove private as
>>>>from AS-PATH or for completeness substitute with their own it is all
>>>>ok. He takes responsibility to route data to such customer(s).
>>>>
>>>>Any subsequent removal of private as in the path also results in the
>>>>same responsibility of the provider who permits private AS for
>>>>peering.
>>>>
>>>>I am not sure why there is concern with it on the list.
>>>
>>>
>>> Not sure you understood the issue Jay was pointing to - but it is a
>>> problem worth talking about if we are serious about advancing this
>>>draft.
>>>
>>> Say an enterprise starts using ASN 4278190081. It already has a bunch of
>>> ASNs from the 16-bit private AS range and relies on the correct behavior
>>> of "remove-private-as" from the ISP. The ISP routers are not upgraded to
>>> understand 4278190081 is a private ASN. We get into all sorts of
>>> interesting scenarios based on the connectivity graph (changes in
>>>traffic
>>> pattern come to mind as I know folks compare AS_PATH length taking into
>>> account remove-private-as).
>>>
>>> The 'operational considerations' section does talk about this - but I
>>> would like it described in more detail.
>>>
>>> - Pradosh
>>>
>