Re: [mpls] [mpls-tp] [PWE3] Changes to PW ACH Channel Typeallocationpolicy

["Thomas D. Nadeau" <tom.nadeau at bt.com>]

On 10/3/08 10:52 AM, "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard at att.com>
wrote:

> Hi Italo,
> 
> It is much more than a codepoint and ensuring the nodes are provisioned
> correctly - which is in itself difficult - especially in large networks.
> Here's just a partial list of additional concerns from an operator:
> - proprietary protocols perpetuate the use of vendor islands - good for
> a vendor/bad for an operator;-(
> - each protocol, proprietary or not, for an operator requires testing of
> the protocol itself, not just if it works as it should, but also
> development and testing of failure scenarios, and the negotiation with
> the vendor for fixes. And if it's proprietary, an operator is on their
> own for determining bugs, determining the correct fix, testing the fix,
> etc, etc.
> - OS development - this is probably the biggest hit on time for
> deployment and most costly (and it's not just for deployment, it
> continues for the lifetime).
> 
> Which is why we have standards. I'm sure the others can add many more
> (still on my first coffee here) and take a look back over Shane's mails.

    Nothing to add here; hits the nail right on the head.

    --Tom


> Deborah
> 
> -----Original Message-----
> From: BUSI ITALO [mailto:Italo.Busi at alcatel-lucent.it]
> Sent: Friday, October 03, 2008 3:39 AM
> To: julien.meuric at orange-ftgroup.com; BRUNGARD, DEBORAH A, ATTLABS;
> shane at castlepoint.net; BOCCI Matthew
> Cc: l2vpn at ietf.org; mpls at ietf.org; ccamp at ietf.org; pwe3 at ietf.org;
> mpls-tp at ietf.org
> Subject: RE: [mpls-tp] [mpls] [PWE3] Changes to PW ACH Channel
> Typeallocationpolicy
> 
> Julien, Tom, Shane and Deborah,
> 
> it looks like you have a common position regarding interoperability
> issues of proprietary protocols.
> 
> I can understand your issues with proprietary protocols because, by
> definition, they do not interoperate.
> 
> However please note that all proprietary protocols by default must be
> disabled and enabled if and only if it is known that all the nodes that
> need to process the proprietary packets are capable to support the
> proprietary protocol. As such you can simply never enable any
> proprietary protocol.
> 
> I fail to understand how the allocation policy of ACH codepoints for
> proprietary use can change the management issues from your point of
> view.
> 
> Italo
> 
>> -----Original Message-----
>> From: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org]
>> On Behalf Of julien.meuric at orange-ftgroup.com
>> Sent: Thursday, October 02, 2008 5:18 PM
>> To: dbrungard at att.com; shane at castlepoint.net; BOCCI Matthew
>> Cc: l2vpn at ietf.org; mpls at ietf.org; ccamp at ietf.org;
>> pwe3 at ietf.org; mpls-tp at ietf.org
>> Subject: RE: [mpls-tp] [mpls] [PWE3] Changes to PW ACH
>> Channel Typeallocationpolicy
>> 
>> Hi.
>> 
>> I must agree with Deborah and Shane.
>> 
>> Option #3 hides the complexity behind a (useless) hierarchy and is
>> clearly not desired. Option #2 would create an explicit non standard
>> range and is not what we expect from the IETF.
>> As a result, since changing the former process seems already
>> committed,
>> option #1 remains the better compromise.
>> 
>> Regards,
>> 
>> Julien
>> 
>> 
>> -----Original Message-----
>> From: mpls-tp-bounces at ietf.org [mailto:mpls-tp-bounces at ietf.org] On
>> Behalf Of BRUNGARD, DEBORAH A, ATTLABS
>> 
>> Agree- and with the strong wording that option #1 is not for
>> SDOs/Forums. Option 2 (or the 3rd option being discussed),
>> may be viewed
>> as no bottleneck for vendors on development of proprietary
>> options, but
>> for operators, it will be an interoperability nightmare.
>> Deborah  
>> 
>> -----Original Message-----
>> From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On
>> Behalf Of
>> Shane Amante
>> 
>> Matthew,
>> 
>> Speaking as an operator, (L2VPN WG co-chair hat off), I would also
>> prefer the existing mechanism that's already in place: expert review
>> and IETF consensus.  After all, there are significant benefits to
>> standards-based OAM and signaling protocols.  On the other
>> hand, some  
>> people may still have a legitimate need to do uncommon things that
>> aren't considered mainstream.  In that case, I would rather see a
>> (small) subset of codepoints allocated for expert review with
>> no IETF  
>> consensus (Option #1 below).
>> 
>> -shane
>> 
>> 
>> On Sep 30, 2008, at 10:23 AM, BOCCI Matthew wrote:
>>> The PWE3 chairs would like feedback on proposed changes to the
>>> allocation policy for the PW ACH codepoint registry. Please see the
>>> email below, and provide any feedback copying the PWE3 list.
>>> 
>>> Best regards
>>> 
>>> Matthew
>>> 
>>> -----Original Message-----
>>> From: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org]
>> On Behalf  
>>> Of
>>> BOCCI Matthew
>>> 
>>> The current IANA allocation policy for the PW associated
>> channel type
>>> registry is by IETF consensus. This policy was chosen in RFC 4385
>>> based
>>> on WG consensus that since the associated channel exists in the data
>>> path, and VCCV packets are typically processed by the control
>>> processor
>>> on many PEs, it was prudent for the IETF to maintain strict
>> control  
>>> over
>>> what types of channels were allocated and to ensure that
>> they complied
>>> to the PWE3 architecture.
>>> 
>>> However, a need has been identified to provide a more flexible
>>> approach
>>> to allocating code points for VCCV channel types. This has partly
>>> arisen
>>> from the MPLS-TP work, where MPLS would be deployed in a transport
>>> network and where a much wider range of applications for the PW
>>> associated channel is envisioned, and partialy from a
>> desire to extend
>>> the OAM capabilities for regular MPLS. We can support MPLS-TP and
>>> general MPLS apps with the current policy which requires standards
>>> action.
>>> 
>>> However we are receiving requests to allow proprietary OAM and
>>> signaling
>>> protocols to be used in transport applications, and need to
>> decide on
>>> the best way forward. We considered providing extension mechanisms
>>> within the standards track protocols, but believe that the standards
>>> track protocols would be much cleaner if the proprietary
>> protocols ran
>>> on their own ACH code points.
>>> 
>>> Note that we are talking about vendor protocols here. Other
>> SDOs would
>>> be required to publish an RFC and would only be allocated an ACH
>>> through
>>> Standards Action.
>>> 
>>> There are two ways to address the requests for proprietary
>> protocol  
>>> ACH
>>> code points:
>>> 
>>> 1) Allow a range of the associated channel type registry to be
>>> allocated
>>> through expert review. Guidelines would be provided for the expert
>>> reviewer to guide them in assessing the request, which
>> would have to  
>>> be
>>> made in the form of an internet draft, while making sure that the
>>> request is dealt with in a timely and fair manner. This policy would
>>> include hurdles with regard to security, congestion etc
>> that would be
>>> derived from those specified in the VCCV design.
>>> 
>>> 2) Allow a range of the associated channel type registry to be
>>> allocated
>>> on a first-come-first-served basis. This does not provide
>> the level of
>>> control that expert review provides, but this is balanced to some
>>> degree
>>> by the fact that the VCCV channel type is indicated in the
>> data path,
>>> and so a PE can choose to discard or rate limit VCCV packets on an
>>> unrecognised associated channel.
>>> 
>>> Any change to the ACH allocation policy would be outlined
>> in the GE- 
>>> ACH
>>> draft, which would update RFC 4385.
>>> 
>>> We would appreciate feedback on the list as to which approach the WG
>>> prefers.
>>> 
>>> Regards,
>>> 
>>> Stewart and Matthew
>>> 
>>> _______________________________________________
>>> pwe3 mailing list
>>> pwe3 at ietf.org
>>> https://www.ietf.org/mailman/listinfo/pwe3
>> 
>> _______________________________________________
>> mpls mailing list
>> mpls at ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>> _______________________________________________
>> mpls-tp mailing list
>> mpls-tp at ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls-tp
>> 
> _______________________________________________
> mpls-tp mailing list
> mpls-tp at ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls