Re: [Idr] draft-l3vpn-legacy-rtc-00.txt

"UTTARO, JAMES (ATTSI)" <ju1738@att.com> Fri, 29 July 2011 14:12 UTC

Return-Path: <ju1738@att.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 5506521F8C0F for <idr@ietfa.amsl.com>; Fri, 29 Jul 2011 07:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 EER+dAq0x2RE for <idr@ietfa.amsl.com>; Fri, 29 Jul 2011 07:12:02 -0700 (PDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id B0D2E21F8BE1 for <idr@ietf.org>; Fri, 29 Jul 2011 07:12:02 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: ju1738@att.com
X-Msg-Ref: server-12.tower-120.messagelabs.com!1311948721!30296648!1
X-StarScan-Version: 6.2.17; banners=-,-,-
X-Originating-IP: [144.160.20.145]
Received: (qmail 24135 invoked from network); 29 Jul 2011 14:12:02 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Jul 2011 14:12:02 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p6TECQ52023992; Fri, 29 Jul 2011 10:12:27 -0400
Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p6TECLUh023866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Jul 2011 10:12:21 -0400
Received: from MISOUT7MSGUSR9P.ITServices.sbc.com ([169.254.7.28]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.01.0289.001; Fri, 29 Jul 2011 10:11:56 -0400
From: "UTTARO, JAMES (ATTSI)" <ju1738@att.com>
To: 'Pedro Marques' <pedro.r.marques@gmail.com>, altonlo <altonlo@cisco.com>
Thread-Topic: [Idr] draft-l3vpn-legacy-rtc-00.txt
Thread-Index: AcxNOYUxmjDayhFBrE+kedWY3crOTAAiz8qAAAy2BBA=
Date: Fri, 29 Jul 2011 14:11:54 +0000
Message-ID: <B17A6910EEDD1F45980687268941550F0154BD@MISOUT7MSGUSR9P.ITServices.sbc.com>
References: <CA56CBB1.2AF2E%altonlo@cisco.com> <CAMXVrt7bxL+sOwCNNfS-8XUX+hXjdx9trwaaWmFzDk7Bc-UPrA@mail.gmail.com>
In-Reply-To: <CAMXVrt7bxL+sOwCNNfS-8XUX+hXjdx9trwaaWmFzDk7Bc-UPrA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.61.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Keyur Patel <keyupate@cisco.com>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] draft-l3vpn-legacy-rtc-00.txt
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: Fri, 29 Jul 2011 14:12:03 -0000

Comments IN-Line..

Jim Uttaro

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Pedro Marques
Sent: Thursday, July 28, 2011 11:55 PM
To: altonlo
Cc: Keyur Patel; idr@ietf.org
Subject: Re: [Idr] draft-l3vpn-legacy-rtc-00.txt

Alton,
I'd like to ask for a clarification as to whether you believe that the
"Legacy PE Behavior" that is described in the draft is achievable by
configuration alone, with no software changes to the PEs in question.
For instance, can the communities that are defined in the draft be
advertised by existing production software ?

If the procedure is based on configuration alone, it seems to be a
potentially very error prone method. For instance, the RT filtering
configuration could easily get out of sync with the actually VRF
configuration, making this of doubtful operational value.
[Jim U>] The approach is to tie the "legacy" configuration with the provisioning of a new VRF.. This is straightforward and there is very little room for error if not by OSS provisioning systems.. We do not have individuals logging on and doing provisioning..Let's look at the damage that could be done.. If mis-configuration takes place then the worst is that 

a) Legacy PE gets too many routes of course this is what we are faced with today.. 
b) Legacy PE gets the routes for VRFs not configured.. This is standard behavior and the paths are dropped
c) Legacy PE does not get the paths for VRFs configured.. In this case we create a incomplete VPN tree for a given customer. We would be made aware very quickly if this occurred..

This feature is actually being demanded by Operations to deal with the large amount of routing state being sent to a legacy PE.. It is quite undesirable to have to deploy the current RT Constrain and upgrade software on all PEs to achieve our goal
[Jim U>]

If on the other hand one assumes that a software upgrade is required,
these are not longer "Legacy PEs". In the latter case this proposal
seems to be just a competing encoding for RFC4684.

I think it is perfectly valid to propose an alternate encoding but i
believe the document should be written as such and compare itself with
the previous mechanism.

regards,
  Pedro.

On Thu, Jul 28, 2011 at 8:17 AM, altonlo <altonlo@cisco.com> wrote:
> Hi,
>
> We presented the following draft (Legacy PE RT Filtering) in IETF80 Prague
> meeting.
>
> http://tools.ietf.org/html/draft-l3vpn-legacy-rtc-00
>
> And we are asking the IDR working group to accept this as a working group
> document.
>
> Thanks,
> -alton
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr