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

["BUSI ITALO" <Italo.Busi at alcatel-lucent.it>]

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 mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls