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

["Shahram Davari" <davari at tpack.com>]

Hi Deborah,

Your concerns are valid, but irrelevant to the discussion at hand. I think it is understood that IETF wants to allow Proprietary protocols and the issue is how to allocate the code points. So there debating whether proprietary protocols are good or bad is not going to make any difference here.  

But just to give you my opinion, lots of great innovations start as proprietary and eventually if they are good they would probably find their way to standard. Juts take a look at Cisco Tag Switching. It started as proprietary but later was standardized as MPLS.

Best regards,
Shahram


-----Original Message-----
From: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: October-03-08 10:52 AM
To: BUSI ITALO
Cc: l2vpn at ietf.org; mpls at ietf.org; ccamp at ietf.org; pwe3 at ietf.org; mpls-tp at ietf.org
Subject: Re: [PWE3] [mpls-tp] [mpls] Changes to PW ACH Channel Typeallocationpolicy

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