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

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.

=================================================
> 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
> 
> On 10/2/08, BUSI ITALO <Italo.Busi@alcatel-lucent.it> wrote:
>> 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
>>
>>> -----Original Message-----
>>> From: mpls-tp-bounces@ietf.org
>>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Vishwas Manral
>>> Sent: Wednesday, October 01, 2008 5:47 PM
>>> To: Shahram Davari
>>> Cc: l2vpn@ietf.org; BOCCI Matthew; mpls@ietf.org;
>>> ccamp@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org
>>> 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:
>>>
>>> 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 <davari@tpack.com> 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: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]
>>> On Behalf Of
>>>> BOCCI Matthew
>>>> Sent: September-30-08 12:23 PM
>>>> To: pwe3@ietf.org; mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org;
>>>> l2vpn@ietf.org
>>>> 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: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]
>>> On Behalf Of
>>>> BOCCI Matthew
>>>> Sent: 25 September 2008 16:36
>>>> To: pwe3@ietf.org
>>>> 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
>>>> pwe3@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>> _______________________________________________
>>>> pwe3 mailing list
>>>> pwe3@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> pwe3 mailing list
>>>> pwe3@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>>
>>> _______________________________________________
>>> mpls-tp mailing list
>>> mpls-tp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> 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
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp