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

[Stewart Bryant <[e-mail]>]

Since a reference was made to extension mechanisms proposed to
the ISIS WG, and since there seemed to be some enthusiasm
for it, to the point where there was a suggestion that we
might follow the same model, I asked my college Mike Shand
for some history and background and what happened next.

Please see the attached email for his answer.

I guess I have to ask whether there are lessons to be learned
from ISIS that we need to take into account here: i.e.
is experimental the way to go, and should we place significant
restriction on what you can do on an experimental codepoint?

Stewart

--- Begin Message ---

Stewart Bryant wrote:

---

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

From: "Vishwas Manral" <[e-mail]>

Date: Wed, 1 Oct 2008 21:17:22 +0530

To: "Shahram Davari" <[e-mail]>

To: "Shahram Davari" <[e-mail]>

CC: "[e-mail]" <[e-mail]>, BOCCI Matthew <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>

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" rel="nofollow">http://tools.ietf.org/draft-ietf-isis-proprietary-tlv-00
  

This draft was replaced by

http://tools.ietf.org/html/draft-ietf-isis-experimental-tlv" rel="nofollow">http://tools.ietf.org/html/draft-ietf-isis-experimental-tlv

because the working group did not want to sanction true vendor proprietary extensions, but wanted to limit them to those which could be described as experimental. A requirement was added that any such extension SHOULD be documented in an experimental RFC.

There were also strict limitations that the presence of an experimental TLV MUST NOT cause a router to calculate a different route.

It was also forbidden to use the TLV as a means for carrying general application data. GENAPP should be used for such purposes.

A particular constraint in IS-IS is that the number space available for TLVs is limited to 255.


However, despite all this, the draft expired in November 2005 and there has been no subsequent desire to resurrect it.

	Mike

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 <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
BOCCI Matthew
Sent: September-30-08 12:23 PM
To: [e-mail]; [e-mail]; [e-mail]; [e-mail];
[e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf Of
BOCCI Matthew
Sent: 25 September 2008 16:36
To: [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3" rel="nofollow">https://www.ietf.org/mailman/listinfo/pwe3
_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3" rel="nofollow">https://www.ietf.org/mailman/listinfo/pwe3



_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3" rel="nofollow">https://www.ietf.org/mailman/listinfo/pwe3

    

_______________________________________________
mpls-tp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-tp" rel="nofollow">https://www.ietf.org/mailman/listinfo/mpls-tp

  

--- End Message ---