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

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

    Stewart,

        I agree with you %100.  It is not the time of approval that will be
the issue in the long run -- I would think an expert review assignment could
be serviced in a couple of weeks to a month (max) anyway. IMHO the real
issue is in how the assignments get implemented later, and precisely as you
say, in the data plane.  The affects here unintentional or intentional, can
be disastrous.

    --Tom (Speaking as my British alter-ego)



On 10/1/08 12:12 PM, "Stewart Bryant" <[e-mail]> wrote:

> Vishwas Manral wrote:
>> 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
>>   
> 
> Vishwas
> 
> We have 65000 units of innovation, and that is without expanding into
> the next
> octet which is currently reserved for expansion.
> 
> Given that we have not yet run out of UDP ports I don't think we need to
> be concerned
> in that regard.
> 
> The reason that we have been very cautious in the past is because we don't
> want anything that goes on in the ACH straying into the dataplane - for
> example  no one using the ACH as a PID and requiring the forwarder to look
> at it.
> 
> Then when we designed VCCV we had all sorts of concerns over traffic volume
> and security of traffic delivered straight to the management processor.
> 
> We were very cautious when we standardized the ACH mechanism, there is a
> good case for maintaining that caution until we see what people are going
> to use it for.
> 
> Stewart (speaking as myself)
> 
> 
> 
>