IETF Logo Mail Archive

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

"Pradosh Mohapatra (pmohapat)" <pmohapat@cisco.com> Wed, 05 December 2012 21:55 UTC

Return-Path: <pmohapat@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C0C21F8CED for <idr@ietfa.amsl.com>; Wed, 5 Dec 2012 13:55:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEJw8yTEibaP for <idr@ietfa.amsl.com>; Wed, 5 Dec 2012 13:55:57 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8AD21F8CA4 for <idr@ietf.org>; Wed, 5 Dec 2012 13:55:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2204; q=dns/txt; s=iport; t=1354744557; x=1355954157; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=c/dZs95ktJ/2wrSluk/75g1A4wWGcESz4nIGuutj4A4=; b=hR7mmt2PxCc5XUN3VszWnlXDPooZcUe6GmF1EkrB9SCYagGhLKC5L1Pg G7YHuuCRqqgA95ninK9JlqUXto7upA2y6xhxrb7QlxisS3SLI+RmIwx2t fJ5xTQq4tasITt9VKxqszrqCxESXn3gkD1L2AiVeQjF9FwocTSHWIU8QC 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAIfBv1CtJXG//2dsb2JhbABEviQWc4IeAQEBBDo/EgEIGAoLCUIlAgQOBQiICMJZjDcoZoJSYQOmSoJygWU8
X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="149618672"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 05 Dec 2012 21:55:56 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB5LtusB001449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Dec 2012 21:55:56 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.110]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 15:55:55 -0600
From: "Pradosh Mohapatra (pmohapat)" <pmohapat@cisco.com>
To: Robert Raszuk <robert@raszuk.net>
Thread-Topic: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00
Thread-Index: AQHNza+ASu61tTboPkC+faw5xeSRvpgBaZKAgAADxACACXARAIAANteAgAAJCgD//4ltAIAAh+YA//97EYA=
Date: Wed, 05 Dec 2012 21:55:55 +0000
Message-ID: <C6C16AE3B7961044B04A1BCEC6E2F93603D12AAF@xmb-rcd-x14.cisco.com>
In-Reply-To: <CA+b+ERnYnYJtDw_BEKwrb-Q_dFzv8XUrN4wC0Bjk+CQJ9PQcNg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.5.121010
x-originating-ip: [10.155.33.251]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <38CA880C5781C54284E35F5FB9AE11EB@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org" <idr@ietf.org>, Jay Borkenhagen <jayb@braeburn.org>, Tony Tauber <ttauber@1-4-5.net>
Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Dec 2012 21:55:58 -0000

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" <robert@raszuk.net> 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)
>><pmohapat@cisco.com> 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
>>

v2.31.3 | Report a Bug | By Email | System Status