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

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

Hi,

I also prefer the method that Wishwas proposed. This has many advantages:

1) Allows vendors to not expose their proprietary techniques to their competitors. 
2) reduces the load of reviewing by IETF and PWE3 
3) results a faster time to market, since no expert review will be needed
4) provides more codepoint space that the ACH channel type
5) only one VCCV ACH channel type needs to be configured in each box for vendor specific filtering

The 2nd method has the first 3 advantages only, and the first method has none of these advantages.


Best regards,
Shahram

-----Original Message-----
From: Thomas D. Nadeau [mailto:[e-mail]] 
Sent: October-02-08 8:13 AM
To: BUSI ITALO; Vishwas Manral; 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




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