Subject: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?

From: John Scudder <[email-masked]>
Date: Wed, 16 Nov 2011 01:01:11 -0800

Folks,

We have received a request from the authors to adopt draft-l3vpn-legacy-rtc-00 as an IDR WG document.  Please send your comments to the list.  The deadline for comments is December 5, 2011 at noon EST.

Thanks,

--John

---

From: Ilya Varlashkin <[email-masked]>
Date: Wed, 16 Nov 2011 22:02:59 +0800

Support

/iLya

On 16 Nov 2011, at 17:01, John Scudder <[email-masked]> wrote:

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Rob Shakir <[email-masked]>
Date: Wed, 16 Nov 2011 14:34:50 +0000

> We have received a request from the authors to adopt draft-l3vpn-legacy-rtc-00 as an IDR WG document.  Please send your comments to the list.  The deadline for comments is December 5, 2011 at noon…

Hi John, IDR,

I support adopting this draft as an IDR WG document.

Kind regards,
r.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 16 Nov 2011 14:54:09 +0000

+1

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rob Shakir
Sent: Wednesday, November 16, 2011 9:35 AM
To: John Scudder
Cc: [email-masked] List
Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?

Hi John, IDR,

Kind regards,
r.

---

From: <[email-masked]>
Date: Wed, 16 Nov 2011 15:48:55 +0100

Support !

--
Stephane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de John Scudder
Envoyé : mercredi 16 novembre 2011 10:01
À : [email-masked] List
Objet : [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?

Folks,

Thanks,

--John

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, 
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law; 
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments. 
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 16 Nov 2011 17:48:40 +0100

If authors agree to provide the addition to the draft that all RRs in a 
given network should support this extension before it is enabled I 
support this draft.

However one needs to understand that this extension means new code on RR 
as well as modification to current PE provisioning script(s).

Best regards,
R.

> Folks,
>
> We have received a request from the authors to adopt
> draft-l3vpn-legacy-rtc-00 as an IDR WG document.  Please send your
> comments to the list.  The deadline for comments is December 5, 2011
> at noon EST.
>
> Thanks,
>
> --John _______________________________________________ Idr mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: Pedro Marques <[email-masked]>
Date: Wed, 16 Nov 2011 09:19:00 -0800

-1

I believe that the "legacy" is now the fact that rt-constraint is
supported by the most common implementations.

The proposed procedures for legacy PEs have a level of complexity that
seems significantly higher than qualifying a new software release.

  Pedro.

---

From: Rob Shakir <[email-masked]>
Date: Wed, 16 Nov 2011 18:20:30 +0000

> seems significantly higher than qualifying a new software release.

While this if of course a valid argument, I believe that there are some operational constraints that make this untrue. 

In an ideal world, all deployed PEs would be running current hardware, and with software trains under active development. Unfortunately, this is not always the case - and hence the requirement is more than a software qualification to support RTC. The options here are migration to new hardware platforms, which comes with significant operational costs, or put up with some operational complexity to better utilise existing assets whilst allowing network growth elsewhere, and delay expenditure. 

I realise that such non-technical requirements may fall outside of the consideration of IETF working groups - but I feel strongly that there is some trade-off to be made that sacrifices some absolute correctness to provide technologies that allow operators to meet their network's commercial requirements. 

We should (of course) consider the extent to which such compromises compromise network robustness - but I can't say that I agree that this draft upsets the complexity/benefit balance. I would be interested to hear if you do.

Kind regards,
r.

---

From: Gaurav Dawra <[email-masked]>
Date: Wed, 16 Nov 2011 13:54:17 -0500

+1 Support

Regards,

-Gaurav Dawra

On 11/16/11 9:54 AM, "UTTARO, JAMES" <[email-masked]> wrote:

>> draft-l3vpn-legacy-rtc-00 as an IDR WG document.  Please send your comments
>> to the list.  The deadline for comments is December 5, 2011 at noon EST.
> 
> Hi John, IDR,
> 

-- 
Gaurav Dawra, Software Eng.
[email-masked]  .:|:.:|:.
NSSTG                        CISCO

---

From: "Balaji Pitta Venkatachalapathy (bvenkata)" <[email-masked]>
Date: Thu, 17 Nov 2011 00:43:01 +0530

Support!!

Regards,
Balaji

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
John Scudder
Sent: Wednesday, November 16, 2011 1:01 AM
To: [email-masked] List
Subject: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?

Folks,

We have received a request from the authors to adopt
draft-l3vpn-legacy-rtc-00 as an IDR WG document.  Please send your
comments to the list.  The deadline for comments is December 5, 2011 at
noon EST.

Thanks,

--John

---

From: Ahmed Bashandy <[email-masked]>
Date: Wed, 16 Nov 2011 11:19:21 -0800

Support
Thanks

Ahmed

Ahmed

---

From: "Arjun Sreekantiah (asreekan)" <[email-masked]>
Date: Wed, 16 Nov 2011 12:08:34 -0800

Pedro,
We have heard otherwise from many of our customers looking to deploy RT-constrain.  Upgrade of all legacy PEs to support RT-constrain is not something that can be accomplished in a quick manner, this is mostly done in a incremental fashion over a long period of time. A PE upgrade can be a time consuming and elaborate process for many of the customers and the below would provide a mechanism to derive benefits on RT-constrain in the interim.

I do not think the legacy PE solution is adding a great deal of complexity. Yes, configuration steps are needed on the legacy PE to specify RT membership information, we expect this can be automated through the use of scripting tools to also specify legacy PE RTs when provisioning the VPNs.

Thanks
Arjun

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pedro Marques
Sent: Wednesday, November 16, 2011 9:19 AM
To: John Scudder
Cc: [email-masked] List
Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?

-1

  Pedro.

---

From: Pedro Marques <[email-masked]>
Date: Wed, 16 Nov 2011 14:47:19 -0800

Arjun,
Do you believe that the provisioning system support necessary to
support the PE functionality defined in this draft can be
"accomplished in a quick manner" ?

Software qualification and updates are indeed a very slow process. The
only process i'm aware of that in practice tends to prove even slower
is to develop new functionality in provisioning systems and change
operational procedures in order to support something like what is
proposed here. Thus my deep skepticism on the value of the WG adopting
this as a work item.

  Pedro.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Nov 2011 00:01:30 +0100

Hi Rob,

While I may even agree with your points reg considerations for a 
software upgrade on the PEs - which in many cases may just not be 
available due to given's vendor software release strategy - I do not 
agree that this is so hard to enhance your provisioning system to update 
the rr-group command on the RR when you are adding/deleting/modifying a 
RT on the PE given RR is serving.

And if you do that there is no need for inbound signalling like proposed 
in this draft.

Rgs,
R.

>> The proposed procedures for legacy PEs have a level of complexity
>> that seems significantly higher than qualifying a new software
>> release.
>
> While this if of course a valid argument, I believe that there are
> some operational constraints that make this untrue.
>
> In an ideal world, all deployed PEs would be running current
> hardware, and with software trains under active development.
> Unfortunately, this is not always the case - and hence the
> requirement is more than a software qualification to support RTC. The
> options here are migration to new hardware platforms, which comes
> with significant operational costs, or put up with some operational
> complexity to better utilise existing assets whilst allowing network
> growth elsewhere, and delay expenditure.
>
> I realise that such non-technical requirements may fall outside of
> the consideration of IETF working groups - but I feel strongly that
> there is some trade-off to be made that sacrifices some absolute
> correctness to provide technologies that allow operators to meet
> their network's commercial requirements.
>
> We should (of course) consider the extent to which such compromises
> compromise network robustness - but I can't say that I agree that
> this draft upsets the complexity/benefit balance. I would be
> interested to hear if you do.
>
> Kind regards, r.
>
>
> _______________________________________________ Idr mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 16 Nov 2011 20:22:38 -0500

Yes/support 

Regards,
Jeff

---

From: "Arjun Sreekantiah (asreekan)" <[email-masked]>
Date: Wed, 16 Nov 2011 18:04:45 -0800

-----Original Message-----
From: Pedro Marques [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 2:47 PM
To: Arjun Sreekantiah (asreekan)
Cc: John Scudder; [email-masked]
Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?

>"accomplished in a quick manner" ?

Pedro,
I would believe this would be less intensive to develop than the software qualification and upgrade.
It would be good to give customers the choice to adopt either approach in any event.

What we see in SP deployments today is that the RR scale is increasing rapidly and this solution will help prolong the life of legacy PE hardware until they are ready for the upgrade, by reducing the scale of routes the legacy PE deals with in its RR peering.

Arjun

  Pedro.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 17 Nov 2011 02:14:20 +0000

Pedro,

Testing, certifying and deploying a new release on a legacy platform is not warranted for the benefit that traditional RT-Constrain brings. There is also the fact that it has to be deployed on lots and lots of legacy PEs.. These legacy PEs also have to be able to support the demands of traditional RT-Constrain. This level of complexity in in of itself is daunting. Beyond the fact that we have to ask vendors to provide a new release for a legacy platform there is also the reality that doing this takes cycles away from new development we would like to do to support new features and services. RT-Constrain as envisioned is a mechanism to create what is essentially multipoint-multipoint multicast trees or better put a directed graph that contains leafs and nodes for a given VPN. This approach assumes that VPN distribution is "localized" and attempts to reduce the resources needed for a given BGP topology. In my experience this assumption has not proved to be correct. That being said RT-Constrain is quite useful for reducing the amount of state a leaf ( PE ) needs to process when a new VRF is added, soft refresh is performed or there is PE reboot. So what we need is a mechanism to solve that problem without the overhead as detailed above.. Legacy RT provides a simple mechanism to deploy a mechanism that protects the legacy PE from having to process large amounts of routing state.. It is also extensible and may act as a traditional RT-Constrain leaf.

So, without divulging our plans.. Hypothetically Legacy RT-Constrain can be deployed in an incremental fashion using existing machinery on the legacy PEs and a new release on the RRs. This is quite attractive.. 

So to address your comment directly it is much harder to certify/test/deploy a new release on possibly thousands of legacy PEs instead of 10s of RRs.. Configuration can be done in an incremental fashion for the problem we face which is protecting legacy PEs.

Thanks,
	Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pedro Marques
Sent: Wednesday, November 16, 2011 12:19 PM
To: John Scudder
Cc: [email-masked] List
Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?

-1

  Pedro.

---

From: "Arjun Sreekantiah (asreekan)" <[email-masked]>
Date: Wed, 16 Nov 2011 18:14:34 -0800

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Raszuk
Sent: Wednesday, November 16, 2011 3:02 PM
To: Rob Shakir
Cc: [email-masked] List
Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG
document?

>And if you do that there is no need for inbound signalling like
proposed 

Robert,
This would mean that every time you have to update the RT configuration
on the PE, you would also have to update  corresponding RT list
(rr-group) config on all RRs the PE is peering with. Thus the RT
configuration change in no longer restricted to the PE alone and would
not scale very well as the number of PEs on which you need to make the
change increases.

Thanks
Arjun

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Nov 2011 03:23:50 +0100

Hi Arjun,

> (rr-group) config on all RRs the PE is peering with.

Yes- on all two RRs in 99 % of VPNv4/v6 deployments.

> Thus the RT

I do not know what does not scale.

In a decent network size provisioning is automated anyway so operator 
would have a RT modification template then just perform single 
modification to RT anyway.

And it is just the template which would need to be one time enhanced to 
accommodate such additional RT insertion on the peering RRs given PE is 
a client of. I do not know why this would be difficult.

Best regards,
R.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 17 Nov 2011 02:41:09 +0000

Coupling customer provisioning and management of BGP infrastructure ( RRs ) is not workable is a large scale network. 

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Arjun Sreekantiah (asreekan)
Sent: Wednesday, November 16, 2011 9:15 PM
To: [email-masked]; Rob Shakir
Cc: [email-masked]
Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?

-----Original Message-----

Robert,

Thanks
Arjun

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Nov 2011 03:47:17 +0100

I respectfully disagree. It all depends how one builds and uses network 
management tools in any size of the network.

If in some cases such management tools are not effective perhaps it 
would be a good idea to fix them rather then propose implementation 
hacks and protocol extensions to work around them.

Best regards,
R.

> Coupling customer provisioning and management of BGP infrastructure (
> RRs ) is not workable is a large scale network.
>
> Jim Uttaro

---

From: Bhavani Parise <[email-masked]>
Date: Thu, 17 Nov 2011 00:53:30 -0800

support.

-Bhavani

---

From: <[email-masked]>
Date: Thu, 17 Nov 2011 15:56:30 +0100

Pedro,

Yes most recent code support it (only Juniper support it since years ;) ), but some legacy platforms deployed in SP networks can't run these new codes (and will never), IMHO there is a need for these PEs until decommissioning.
Moreover modifying provisionning tool to add few lines may not be a big deal.

Stephane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Pedro Marques
Envoyé : mercredi 16 novembre 2011 18:19
À : John Scudder
Cc : [email-masked] List
Objet : Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?

-1

I believe that the "legacy" is now the fact that rt-constraint is supported by the most common implementations.

The proposed procedures for legacy PEs have a level of complexity that seems significantly higher than qualifying a new software release.

  Pedro.

---

From: Pierre Francois <[email-masked]>
Date: Mon, 21 Nov 2011 09:45:22 +0100

Support.

Because I (think I) understand the practical reasons for this one.

Far from me the idea of enjoying IDR going along the path
of protocol spec changes in order to deal with an unfortunate mix of 
legacy and management issues.

Pierre.