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

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

Jim Uttaro

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

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

>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.

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

> On 16 Nov 2011, at 17:19, Pedro Marques wrote:
>
>> -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.
>
> 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
> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
>
>

_______________________________________________
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