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

["Thomas D. Nadeau" <[e-mail]>]

On 10/2/08 3:11 AM, "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.

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

    --Tom

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

_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3