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

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

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