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

["Annamaria Fulignoli" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Huub van Helvoort
Sent: giovedì 2 ottobre 2008 9.52
To: Vishwas Manral
Cc: [e-mail]; [e-mail]; BOCCI Matthew; [e-mail]; [e-mail]; [e-mail]; BUSI ITALO
Subject: Re: [mpls] [mpls-tp] [PWE3] FW: Changes to PW ACH ChannelType 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 <[e-mail]> 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: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Vishwas Manral
>>> Sent: Wednesday, October 01, 2008 5:47 PM
>>> To: Shahram Davari
>>> Cc: [e-mail]; BOCCI Matthew; [e-mail]; [e-mail]; 
>>> [e-mail]; [e-mail]
>>> 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 <[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
>>>> _______________________________________________
>>>> pwe3 mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> pwe3 mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>>
>>> _______________________________________________
>>> mpls-tp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> 

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