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

Jim,
Wouldn't it be simpler for the OSS to configure the list of route
targets as an outgoing filter in the RR ? Without any involvement of
the PE.
That would amount to have a manual mode to configure the route-target
filter that the RR uses towards the PE and could significantly reduce
the complexity of the software on the router side.
It seems to me that the extra step of adding the information at the PE
as VRF routes and them translating from VRF routes to route-target
filtering information could be avoided.

It is interesting to hear that OSS software development cycle is
faster than the PE software qualification cycle. Did OSS software
development cycle get just that much agile lately or is it the PE
software qual cycle that just got out of whack ?

  Pedro.

On Fri, Jul 29, 2011 at 7:11 AM, UTTARO, JAMES (ATTSI) <ju1738@att.com> wrote:
> 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
>