Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel Type allocation policy

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 1 Oct 2008 21:17:22 +0530

Hi Matthew,

I would like to propose another option if it is for vendor proprietery
"Channel Type" values in the ACH header. With the number of values of
the channel type being limited and the number of vendors actually a
lot, I would think something in the lines of what the draft below
talks about may make sense:

http://tools.ietf.org/draft-ietf-isis-proprietary-tlv-00

The idea is give a channel type value, for vendor specific
implemntations and further define the structure of the next header
value for such a "channel type" to actually have a Vendor OUI value.

This will allow for unlimited innovation without affecting
interoperability, unlike the other options you have mentioned.

Thanks,
Vishwas

On 10/1/08, Shahram Davari <[email-masked]> wrote:
> Hi Mathew,
>
> I support option 2, since a terminating node that doesn't understand the
> VCCV channel type can always drop it. This would allow more innovation and
> faster time to market.
>
> Best regards,
> Shahram
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> BOCCI Matthew
> Sent: September-30-08 12:23 PM
> To: [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: [PWE3] FW: Changes to PW ACH Channel Type allocation policy
>
> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
> BOCCI Matthew
> Sent: 25 September 2008 16:36
> To: [email-masked]
> Subject: [PWE3] Changes to PW ACH Channel Type allocation policy
>
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Oct 2008 17:12:51 +0100

Vishwas

We have 65000 units of innovation, and that is without expanding into 
the next
octet which is currently reserved for expansion.

Given that we have not yet run out of UDP ports I don't think we need to 
be concerned
in that regard.

The reason that we have been very cautious in the past is because we don't
want anything that goes on in the ACH straying into the dataplane - for
example  no one using the ACH as a PID and requiring the forwarder to look
at it.

Then when we designed VCCV we had all sorts of concerns over traffic volume
and security of traffic delivered straight to the management processor.

We were very cautious when we standardized the ACH mechanism, there is a
good case for maintaining that caution until we see what people are going
to use it for.

Stewart (speaking as myself)

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 01 Oct 2008 13:21:28 -0400

Stewart,

        I agree with you %100.  It is not the time of approval that will be
the issue in the long run -- I would think an expert review assignment could
be serviced in a couple of weeks to a month (max) anyway. IMHO the real
issue is in how the assignments get implemented later, and precisely as you
say, in the data plane.  The affects here unintentional or intentional, can
be disastrous.

    --Tom (Speaking as my British alter-ego)

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 1 Oct 2008 13:52:47 -0400

I also agree on #1.

Cheers,
Andy

On Tue, Sep 30, 2008 at 3:19 PM, Shah, Himanshu <[email-masked]> wrote:
> I support proposal one - funnelling through expert review of the draft
> proposal.
> And yes turnaround must be quick...
>
> /himanshu
>
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of BOCCI Matthew
> Sent: Tuesday, September 30, 2008 12:23 PM
> Subject: [mpls-tp] FW: [PWE3] Changes to PW ACH Channel Type
> allocationpolicy
>

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 2 Oct 2008 09:00:55 +0200

I also support option 2

The requirement is to allow a vendor to implement proprietary innovative
features.

Italo

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Shahram Davari
> Sent: Wednesday, October 01, 2008 4:34 PM
> To: BOCCI Matthew; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [PWE3] FW: Changes to PW ACH Channel Type 
> allocation policy
> 
> Hi Mathew,
> 
> I support option 2, since a terminating node that doesn't 
> understand the VCCV channel type can always drop it. This 
> would allow more innovation and faster time to market.
> 
> Best regards,
> Shahram
> 
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of BOCCI Matthew
> To: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 2 Oct 2008 09:11:27 +0200

Vishwas,

I think this is a good idea

Both this proposal and option 2 (fist-come-first-served) meet the
requirements to make the ACH mechanism extensible.

The advantage of this approach is that we do not have to worry about how
many codepoints we need to allocate for proprietary extensions: we just
need one codepoint.

Italo

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vishwas Manral
> Sent: Wednesday, October 01, 2008 5:47 PM
> To: Shahram Davari
> Cc: [email-masked]; BOCCI Matthew; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel 
> Type allocationpolicy
> 
> Hi Matthew,
> 
> understand the

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 02 Oct 2008 08:10:56 +0100

Italo

How does option 1 prevent a vendor implementing proprietary innovative 
features?

Stewart

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 2 Oct 2008 12:51:27 +0530

Hi Italo,

I agree and that was my exact aim.

The other added advantage is that there are no interoperability issues
and no bottlenecks of assignments for a particular type.

Thanks,
Vishwas

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 02 Oct 2008 09:52:07 +0200

Hi Vishwas,

I support your proposal as well.

Your proposal is in fact in line with the way the vendor
specific codepoint is used in ITU-T Y.1731.

One of the objectives of the MPLS-TP JWT is to align with Y.1731
so this perfectly matches the objective.

Cheers, Huub.

=================================================
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Loa Andersson <[email-masked]>
Date: Thu, 02 Oct 2008 10:36:08 +0200

All,

I support option 1.

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                           [email-masked]
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 02 Oct 2008 08:13:06 -0400

> requirements to make the ACH mechanism extensible.

    How does the existing mechanism not meet the requirement to make an ACH
mechanism extensible?

    --Tom

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Thu, 2 Oct 2008 09:53:30 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Shane Amante
Sent: Thursday, October 02, 2008 12:02 AM
To: BOCCI Matthew
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [mpls] [PWE3] Changes to PW ACH Channel Type allocation
policy

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

---

From: <[email-masked]>
Date: Thu, 2 Oct 2008 17:18:17 +0200

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: [email-masked] [mailto:[email-masked]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS

-----Original Message-----

Matthew,

-shane

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 3 Oct 2008 09:38:47 +0200

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

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Thursday, October 02, 2008 5:18 PM
> To: [email-masked]; [email-masked]; BOCCI Matthew
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: [mpls-tp] [mpls] [PWE3] Changes to PW ACH 
> Channel Typeallocationpolicy
> 
> Hi.
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf  
> > Of
> > BOCCI Matthew
> >
> > on many PEs, it was prudent for the IETF to maintain strict 
> control  
> > over
> > There are two ways to address the requests for proprietary 
> protocol  
> > ACH
> > code points:
> >
> > reviewer to guide them in assessing the request, which 
> would have to  
> > be
> > Any change to the ACH allocation policy would be outlined 
> in the GE- 
> > ACH

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 3 Oct 2008 09:56:27 +0200

Stewart,

as far as I can understand from RFC 4446, a vendor can be prevented
implementing proprietary innovative features by simply disapproving its
codepoint request.

Italo

> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: Thursday, October 02, 2008 9:11 AM
> To: BUSI ITALO
> Cc: Shahram Davari; BOCCI Matthew; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [mpls] [PWE3] FW: Changes to PW ACH Channel Type 
> allocation policy
> 
> BUSI ITALO wrote:
> > I also support option 2
> >

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 3 Oct 2008 09:57:47 +0200

See my reply to the same question made by Stewart

Italo

> From: Thomas D. Nadeau [mailto:[email-masked]] 
> Sent: Thursday, October 02, 2008 2:13 PM
> To: BUSI ITALO; Vishwas Manral; Shahram Davari
> >> On Behalf Of
> >> On Behalf Of
> >> control over
> >> protocol ACH
> >> would have to be
> >> in the GE-ACH

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 03 Oct 2008 09:08:39 +0100

Clearly the expert can decline, otherwise there would be no point in then
bing in the process.

However it is expected that they behave reasonably and within the policy
guidelines stated in the RFC, and in the event that you disagree with their
decision, you can appeal to the IESG.

Stewart

BUSI ITALO wrote:
>>> The requirement is to allow a vendor to implement 
>>>       
>> proprietary innovative
>>     
>>> features.
>>>
>>> Italo
>>>
>>>   
>>>       
>> Italo
>>

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 3 Oct 2008 10:23:08 +0200

I think that everybody has a different view about the meaning of "behave
reasonably".

Any guideline you can write to describe what is a reasonable behavior is
open to different interpreation.

I can appeal to the IESG and to whatever authority to enforce a
reasonable behavior but this will end up in an endless discussion.

Endless discussions are against fast time to market.

Italo

> Sent: Friday, October 03, 2008 10:09 AM
> To: BUSI ITALO

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Fri, 3 Oct 2008 10:52:15 -0400

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:[email-masked]] 
Sent: Friday, October 03, 2008 3:39 AM
To: [email-masked]; BRUNGARD, DEBORAH A, ATTLABS;
[email-masked]; BOCCI Matthew
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [mpls-tp] [mpls] [PWE3] Changes to PW ACH Channel
Typeallocationpolicy

Italo

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 03 Oct 2008 11:02:39 -0400

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

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Mon, 6 Oct 2008 12:34:34 +0200

Hi Matthew,
I support option 2.

Best Regards
Annamaria 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BOCCI Matthew
Sent: martedì 30 settembre 2008 18.23
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [mpls-tp] FW: [PWE3] Changes to PW ACH Channel Type allocationpolicy

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: [email-masked] [mailto:[email-masked]] On Behalf Of BOCCI Matthew
Sent: 25 September 2008 16:36
To: [email-masked]
Subject: [PWE3] Changes to PW ACH Channel Type allocation policy

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

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Mon, 6 Oct 2008 17:25:46 +0200

Hi Matthew,
I also prefer the method that Wishwas proposed;
that for the several reasons yet clearly exposed in the mails below.
Besides, is it possible to "recognize" it as a possible third solution 
and add it to the two ones you proposed in your first mail ?

Thanks,BR.

Annamaria  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: giovedì 2 ottobre 2008 9.52
To: Vishwas Manral
Cc: [email-masked]; [email-masked]; BOCCI Matthew; [email-masked]; [email-masked]; [email-masked]; BUSI ITALO
Subject: Re: [mpls] [mpls-tp] [PWE3] FW: Changes to PW ACH ChannelType allocationpolicy

Hi Vishwas,

Your proposal is in fact in line with the way the vendor specific codepoint is used in ITU-T Y.1731.

One of the objectives of the MPLS-TP JWT is to align with Y.1731 so this perfectly matches the objective.

Cheers, Huub.

>> The advantage of this approach is that we do not have to worry about 
>> how many codepoints we need to allocate for proprietary extensions: 
>> we just need one codepoint.
>>
>> Italo
>>
>>> Cc: [email-masked]; BOCCI Matthew; [email-masked]; [email-masked]; 
>>> [email-masked]; [email-masked]
>>> Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel Type 
>>> allocationpolicy
>>>
>>> Hi Matthew,
>>>
>>> I would like to propose another option if it is for vendor 
>>> proprietery "Channel Type" values in the ACH header. With the number 
>>> of values of the channel type being limited and the number of 
>>> vendors actually a lot, I would think something in the lines of what 
>>> the draft below talks about may make sense:
>>>
>>>> on WG consensus that since the associated channel exists in the 
>>>> data path, and VCCV packets are typically processed by the
>>> control processor
>>>> within the standards track protocols, but believe that the 
>>>> standards track protocols would be much cleaner if the proprietary
>>> protocols ran
>>>> request is dealt with in a timely and fair manner. This policy 
>>>> would include hurdles with regard to security, congestion etc
>>> that would be

                   http://www.van-helvoort.eu/ ================================================================

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 02 Oct 2008 18:28:29 +0100

If the process is going to be changed I would vote for Option #1 (expert
review).

Ben

>     --Tom (Speaking as my British alter-ego)

I hope that's not me ;-))