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

[Robert Raszuk <[e-mail]>]

Hello Luis,

Many thx for your answer. One follow-up question as I am really keen to 
know ...

> As a carrier, we continue to work towards improving the overall
> experience of our customers in these legacy PEs.

How does support of legacy RTC on the PE helps to improve the overall 
experience of your customers ?

If anything I would assume this helps your core infrastructure, but 
customers should never see any change in experience with or without 
legacy RTC enabled.

Best regards,
R.


> Robert, Thanks for the feedback.  I agree with your statement that
> more than likely, many carriers that are supporting "legacy" PEs
> will not be able to run "new" services on these routers.  However,
> for most carriers, provisioning of new circuits/VRFs on these legacy
> PEs continue to take place.  As a carrier, we continue to work
> towards improving the overall experience of our customers in these
> legacy PEs.
>
> As it is the case in many carrier networks, automated provisioning
> tools only have visibility to PEs and not to routers on a P or RR
> roles.  P and RR routers are considered core infrastructure which
> only a few selected groups have access to for security issues.
>
> Luis

> -----Original Message----- From: Robert Raszuk
> [mailto:[e-mail]] Sent: Thursday, November 17, 2011 7:07 PM
>  To: Tomotaki, Luis M. Cc: [e-mail] Subject: Re: [Idr] Adoption
> of draft-l3vpn-legacy-rtc-00 as IDR WG document?
>
> Luis,
>
>> - We need support for the legacy PE draft since a large number of
>> PEs in many service provider networks will never be able to
>> support RFC 4684 since the code upgrade of these legacy PEs is not
>> an option due to multiple reasons such as end-of-life scenarios or
>> costly hardware upgrades.
>
> Putting legacy RTC topic aside which is at the end of the day just
> an optimization it seems that your legacy PEs will also never be able
> to be upgraded with any other new functionality you or IETF may be
> coming with.
>
> Therefor you will not be able to run any new services on those PEs.
> And this is all because vendor XYZ decided to abandon the software
> development on a branch your and "many service providers" are using
> in production.
>
> That seems to me like much bigger issue that effectively this is
> your PE vendor to get to decide what services you are to offer on
> your PEs.
>
>> - As a representative of a large service provider, our comment is
>> that our provisioning systems are highly automated and should
>> easily be able to make the provisioning changes needed to specify
>> RT membership information on the legacy PEs during the VRF
>> configuration with no additional risk to our customer traffic. -
>> The VPNV4/VPNV6 RRs in our network are considered core
>> infrastructure devices that should NOT be exposed to daily
>> provisioning activity that the manual addition of filters to the
>> core RR would require.
>
> If the provisioning is "highly automated" I fail to see why
> provisioning in "core infrastructure" would have to be a manual
> process.
>
> Best, R.
>
>
>