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

From: altonlo <[email-masked]>
Date: Thu, 28 Jul 2011 08:17:53 -0700

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

---

From: Pedro Marques <[email-masked]>
Date: Thu, 28 Jul 2011 20:54:39 -0700

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.

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 <[email-masked]> wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: altonlo <[email-masked]>
Date: Fri, 29 Jul 2011 06:15:41 -0700

Hi Pedro,

Thanks for your reviews and comments.  Please see inline response.

Cheers,
-alton

> advertised by existing production software ?

The communities value is the following:

0xFFFF0002    ROUTE_FILTER_TRANSLATED_v4    [draft-l3vpn-legacy-rtc]
0xFFFF0003    ROUTE_FILTER_v4    [draft-l3vpn-legacy-rtc]
0xFFFF0004    ROUTE_FILTER_TRANSLATED_v6    [draft-l3vpn-legacy-rtc]
0xFFFF0005    ROUTE_FILTER_v6    [draft-l3vpn-legacy-rtc]

The existing production software in IOS and IOS-XR can be used without any
software upgrade.

> configuration, making this of doubtful operational value.

You've made a very good point and the configuration needs to planned.  This
scheme is not meant to replace RFC4684.  Instead, it offers the SP operators
a different migration path to RFC4684.

The "extra" configuration should be a one-to-one mapping to the VPN
membership (matching route-target value) on the legacy PE.  One suggestion
is to generate this configuration whenever a new VRF is provision in the
legacy PE.  We would like to hear feedback from the workgroup also.

> seems to be just a competing encoding for RFC4684.

Software upgrade is not required on the legacy PE
> believe the document should be written as such and compare itself with

This is a very good feedback.  We will add your suggestion in next version.

---

From: "UTTARO, JAMES (ATTSI)" <[email-masked]>
Date: Fri, 29 Jul 2011 14:11:54 +0000

Comments IN-Line..

Jim Uttaro

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

Alton,

[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>]

regards,
  Pedro.

---

From: Pedro Marques <[email-masked]>
Date: Fri, 29 Jul 2011 09:58:49 -0700

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.

---

From: "UTTARO, JAMES (ATTSI)" <[email-masked]>
Date: Fri, 29 Jul 2011 17:17:47 +0000

Pedro,

Back in the day ;) I had considered creating policy on the RR. The downside is that now a customer provisioning event turns into a network/RR provisioning event.. Without getting to far into it, our iBGP topology is for the most part static, we do not touch RRs in response to VPNs being provisioned on PEs. I made that as a conscious decision as to ensure as much stability in the iBGP topology as possible.. The danger of tweaking the RRs is that they are central and a mis-config there can create a major/catastrophic failure.. I would rather have issue localized to the PEs.

The notion is to augment the OSS provisioning so that VRF addition will also trigger a policy update for legacy RT.. To your point OSS is difficult and PE Upgrades are difficult also.. But the latter requires maintenance windows ( These are quite valuable ), scheduling with customers to notify them of an outage, vendor development, testing/cert etc... all on legacy equipment. It seems more prudent to use our resources in a more strategic manner.

Jim Uttaro	

-----Original Message-----
From: Pedro Marques [mailto:[email-masked]] 
Sent: Friday, July 29, 2011 12:59 PM
To: UTTARO, JAMES (ATTSI)
Cc: altonlo; Keyur Patel; [email-masked]
Subject: Re: [Idr] draft-l3vpn-legacy-rtc-00.txt

Jim,

  Pedro.

---

From: Pedro Marques <[email-masked]>
Date: Fri, 29 Jul 2011 14:43:16 -0700

Jim,
I wonder if it would it be helpful to have a section in the draft that
describes the OSS functionality required for it to be practical from
an operational perspective ?

Thank you for taking the time to answer my questions.

  Pedro.