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

From: Luca Martini <[email-masked]>
Date: Thu, 02 Oct 2008 12:17:15 -0600

Shahram,
the point of expert review is not to prevent vendor specific OAM 
methods. It is to prevent duplication, and guide implementors in the 
right direction.
For example , if somebody needs a new PW type , for a very vendor 
specific protocol , say Apollo DDS ( I was the last recorded user of 
that ;-) ), but asks for an ACH type instead , the expert can advise to 
use a new pw type. In the end there is no enforcement method, so any 
vendor can do anything they want. The only part we can do here , is have 
some sane documentation of the methods we put in the registry. ( 
documentation could be as short a a line , or as long as a draft )

Luca

Shahram Davari wrote:
> No one asked for IETF rubber stamping. I asked for a mechanism (code point assignment) that easily implement vendor specific methods. I don't see any reason why IETF should review and approve a vendor specific method. If IETF doesn't want to see any vendor specific method, then it doesn't need to allocate any code points. However, if IETF wants to encourage vendor specific protocols then it must do so in a way that makes it easy for vendors to use it.
>
> -Shahram
>
>
> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]] 
> Sent: October-02-08 12:44 PM
> To: Shahram Davari; Shane Amante
> Cc: [email-masked]; [email-masked]; BOCCI Matthew; [email-masked]; [email-masked]; Vishwas Manral; [email-masked]; BUSI ITALO
> Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel Type allocationpolicy
>
>
>
>     I agree with %100 of Shane's comments. One bit to add below:
>
>   
>> Hi Shane,
>>
>> Please see my response in-line.
>>
>> Best regards,
>> Shahram
>>
>>
>> -----Original Message-----
>> From: Shane Amante [mailto:[email-masked]]
>> Sent: October-02-08 10:43 AM
>> To: Shahram Davari
>> Cc: BUSI ITALO; Vishwas Manral; [email-masked]; BOCCI Matthew; [email-masked];
>> [email-masked]; [email-masked]; [email-masked]
>> Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel Type
>> allocationpolicy
>>
>> Shahram Davari wrote:
>>     
>>> 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.
>>>       
>>  From the POV of an operator, this is actually a substantial disadvantage.
>>
>> [Shahram] OTOH it encourages more innovation and differentiation by vendors.
>>     
>
>     That is hogwash. Customers encourage vendors to innovate not standards
> bodies. Standards bodies help encourage and foster interoperability of a
> common specification. The latter is the important point Shane is making (as
> am I and others who are the customers in this equation). We don't want to
> encourage proprietary implementations for the sake of proprietary
> implementations; we want to encourage them to ultimately interoperate on a
> common specification. However, if your goal as a vendor is to create
> proprietary implementations you are free to do so, but you do not need the
> IETF unless you are looking for some sort of rubber stamp of approval.
>
>     --Tom
>
>
>   
>   
>>> 2) reduces the load of reviewing by IETF and PWE3
>>>       
>> OTOH, the benefit of such reviews by the IETF and PWE3 is when
>> "commonality" among similar applications are discovered they can be
>> standardized, rather kept proprietary.
>>
>> [Shahram] Not if the inventing vendor is not willing to do so.
>>
>>
>>     
>>> 3) results a faster time to market, since no expert review will be needed
>>>       
>> True, to some extent.  But, IMHO, I would much rather see a *slightly*
>> slower process involving a careful expert review and/or IETF consensus
>> to make sure we're not: a) unnecessarily duplicating work; and, b) at
>> the same time, encouraging more standards-based approach.
>>
>>
>>     
>>> 4) provides more codepoint space that the ACH channel type
>>>       
>> This is false.  There is no shortage on ACH channel types today.
>> [Shahram] You are correct. 16-bit is sufficient enough.
>>
>>
>>     
>>> 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.
>>>       
>> Also, let's take a step back here.  Wasn't the whole point with the
>> joint ITU-T/IETF effort surrounding MPLS-TP to create an environment in
>> which MPLS-TP could seamlessly interoperate within (existing) MPLS
>> environments?  I thought a fundamental part of that work is striving
>> towards creating a *standards-based* MPLS-TP data-plane, OAM, signaling,
>> etc. mechanisms.  IMO, Vishwas' proposal and Matthew's proposal #2 seems
>> to run contrary to that goal.
>>
>> [Shahram] off course we should all encourage standards methods. But we should
>> provide a fast and reasonable procedure for vendor specific protocols that
>> don't affect interoperability. I worry that in first method competitors may
>> vote down code point requests for commercial reasons.
>>
>> -shane (speaking only for himself, not as co-chair)
>>
>>
>>
>>     
>
>
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>   

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 3 Oct 2008 09:08:33 +0200

Luca,

Reading your mail, I understand that Expert Review is just providing an
advice and cannot enforce the requestor.

However, this is in contradiction from what I can understand reading RFC
4446 and in particulare the statement saying that "The expert reviewing
the request MUST approve or disapprove ...".

My understanding of RFC 4446 is that the experts can disapprove the
request and avoid the requestor using the ACH for its own proprietary
protocol.

Could you please clarify whether I am misunderstanding you or RFC 4446?

Thanks, Italo

> From: Luca Martini [mailto:[email-masked]] 
> Sent: Thursday, October 02, 2008 8:17 PM
> To: Shahram Davari
> Cc: Thomas D. Nadeau; Shane Amante; [email-masked]; 
> [email-masked]; BOCCI Matthew; [email-masked]; 
> [email-masked]; [email-masked]; BUSI ITALO
> Subject: Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channel 
> Type allocationpolicy
> 
> Shahram,
> > No one asked for IETF rubber stamping. I asked for a 
> mechanism (code point assignment) that easily implement 
> vendor specific methods. I don't see any reason why IETF 
> should review and approve a vendor specific method. If IETF 
> doesn't want to see any vendor specific method, then it 
> doesn't need to allocate any code points. However, if IETF 
> wants to encourage vendor specific protocols then it must do 
> so in a way that makes it easy for vendors to use it.
> >
> > -Shahram
> >
> >
> > Cc: [email-masked]; [email-masked]; BOCCI Matthew; 
> [email-masked]; [email-masked]; Vishwas Manral; 
> [email-masked]; BUSI ITALO

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 3 Oct 2008 09:13:41 +0200

Luca,

I fully agree with you that using an ACH for implementing a new PW type
for a very vendor specific protocol is a very bad idea.

However, I think that the best way to avoid people running proprietary
PW within a ACH is not to overload experts with these requests but to
clearly document that a vendor that wishes to implement a new PW type
for a very vendor specific protocol MUST define a new PW type.

Italo

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 3 Oct 2008 08:36:46 -0500

Luca,

	The practical reality is that expert review gives the 
designated "expert" (or experts) the same level of control 
of assignment as IESG review gives ADs over RFC publication.
While it is possible to push something through against the
"wishes" of an expert (who does in fact have more than the
ability to "advise" the requesting individual/organization),
the process can be quite confrontational and tedious.

--
Eric Gray
Principal Engineer
Ericsson  

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Luca Martini
> Sent: Thursday, October 02, 2008 2:17 PM
> To: Shahram Davari
> Cc: Thomas D. Nadeau; [email-masked]; BOCCI Matthew; 
> [email-masked]; [email-masked]; [email-masked]; BUSI ITALO; 
> [email-masked]
> Subject: Re: [mpls] [PWE3] [mpls-tp] FW: Changes to PW ACH 
> ChannelType allocationpolicy
> 
> Shahram,
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Luca Martini <[email-masked]>
Date: Fri, 03 Oct 2008 08:53:29 -0600

Eric,

This is true, but it all depends on the Expert guidelines we setup.
We can easily put in place a rule that mitigates this problem.

Luca

Eric Gray wrote:
>>> Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel 
>>>       
>> Type allocationpolicy
>>     
>>>
>>>> Cc: BUSI ITALO; Vishwas Manral; [email-masked]; BOCCI 
>>>>         
>> Matthew; [email-masked];
>>     
>>>>> I also prefer the method that Wishwas proposed. This has 
>>>>>           
>> many advantages:
>>     
>>>>> 1) Allows vendors to not expose their proprietary 
>>>>>           
>> techniques to their
>>     
>>>>> competitors.
>>>>>       
>>>>>           
>>>>  From the POV of an operator, this is actually a 
>>>>         
>> substantial disadvantage.
>>     
>>>> [Shahram] OTOH it encourages more innovation and 
>>>>         
>> differentiation by vendors.
>>     
>>>>     
>>>>         
>>>     That is hogwash. Customers encourage vendors to 
>>>       
>> innovate not standards
>>     
>>> bodies. Standards bodies help encourage and foster 
>>>       
>> interoperability of a
>>     
>>> common specification. The latter is the important point 
>>>       
>> Shane is making (as
>>     
>>> am I and others who are the customers in this equation). We 
>>>       
>> don't want to
>>     
>>> implementations; we want to encourage them to ultimately 
>>>       
>> interoperate on a
>>     
>>> proprietary implementations you are free to do so, but you 
>>>       
>> do not need the
>>     
>>> IETF unless you are looking for some sort of rubber stamp 
>>>       
>> of approval.
>>     
>>>     --Tom
>>>
>>>
>>>   
>>>   
>>>       
>>>>> 3) results a faster time to market, since no expert 
>>>>>           
>> review will be needed
>>     
>>>>>       
>>>>>           
>>>> True, to some extent.  But, IMHO, I would much rather see 
>>>>         
>> a *slightly*
>>     
>>>> slower process involving a careful expert review and/or 
>>>>         
>> IETF consensus
>>     
>>>> to make sure we're not: a) unnecessarily duplicating work; 
>>>>         
>> and, b) at
>>     
>>>>> 5) only one VCCV ACH channel type needs to be configured 
>>>>>           
>> in each box for
>>     
>>>>> The 2nd method has the first 3 advantages only, and the 
>>>>>           
>> first method has none
>>     
>>>>> of these advantages.
>>>>>       
>>>>>           
>>>> joint ITU-T/IETF effort surrounding MPLS-TP to create an 
>>>>         
>> environment in
>>     
>>>> environments?  I thought a fundamental part of that work 
>>>>         
>> is striving
>>     
>>>> towards creating a *standards-based* MPLS-TP data-plane, 
>>>>         
>> OAM, signaling,
>>     
>>>> etc. mechanisms.  IMO, Vishwas' proposal and Matthew's 
>>>>         
>> proposal #2 seems
>>     
>>>> [Shahram] off course we should all encourage standards 
>>>>         
>> methods. But we should
>>     
>>>> provide a fast and reasonable procedure for vendor 
>>>>         
>> specific protocols that
>>     
>>>> don't affect interoperability. I worry that in first 
>>>>         
>> method competitors may
>>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 06 Oct 2008 09:49:26 +0200

Sharam,

I agree.

In my understanding the PW ACH Channel Type provides the same function as
the EtherType in Ethernet networks. IEEE provides a means to buy an
EtherType codepoint (http://standards.ieee.org/regauth/ethertype/eth.txt).
The requesting organisation can decide to keep their associated application
private ("Protocl unavailable.") or to make it public.

As far as I understand this EtherType allocation policy is an industry
standard and could be copied for PW ACH Channel Type allocation policy.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Shahram Davari
Sent: 02 October 2008 19:18
To: Thomas D. Nadeau; Shane Amante
Cc: [email-masked]; [email-masked]; BOCCI Matthew; [email-masked];
[email-masked]; [email-masked]; BUSI ITALO
Subject: Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channel
Typeallocationpolicy

No one asked for IETF rubber stamping. I asked for a mechanism (code point
assignment) that easily implement vendor specific methods. I don't see any
reason why IETF should review and approve a vendor specific method. If IETF
doesn't want to see any vendor specific method, then it doesn't need to
allocate any code points. However, if IETF wants to encourage vendor
specific protocols then it must do so in a way that makes it easy for
vendors to use it.

-Shahram

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: October-02-08 12:44 PM
To: Shahram Davari; Shane Amante
Cc: [email-masked]; [email-masked]; BOCCI Matthew; [email-masked];
[email-masked]; Vishwas Manral; [email-masked]; BUSI ITALO
Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel Type
allocationpolicy

    --Tom

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 6 Oct 2008 10:27:08 +0200

Maarten and all,
Please see some comments inline below. The unrelated text has been snipped to improve readability.

Regards,
        Sasha
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Maarten Vissers
> Sent: Monday, October 06, 2008 9:49 AM
> To: 'Shahram Davari'; 'Thomas D. Nadeau'; 'Shane Amante'
> Cc: [email-masked]; [email-masked]; 'BOCCI Matthew';
> [email-masked]; [email-masked]; [email-masked]; 'BUSI ITALO'
> Subject: Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channel Type allocation policy
>
> Sharam,
>
> I agree.
>
> In my understanding the PW ACH Channel Type provides the same
> function as the Ethertype in Ethernet networks. IEEE provides a means to buy an
> Ethertype codepoint (http://standards.ieee.org/regauth/ethertype/eth.txt).
> The requesting organization can decide to keep their associated application
> private ("Protocol unavailable.") or to make it public.
>
> As far as I understand this Ethertype allocation policy is an industry
[Sasha] IMHO and FWIW your description of the IEEE process is somewhat inaccurate.
I am not an expert in the field, and Shahram (and others) will probably provide a much more accurate description
of the process, but still:

1. As you've mentioned, IEEE *SELLS* its Ethertype codepoints - at USD $2,500 per a *PUBLIC* codepoint.
    AFAIK, the IETF does not charge anybody  for its codepoints (hopefully this will not result in any bright ideas:-)

2. There is no such thing as a *PRIVATE* Ethertype codepoint at IEEE  (at least, I did not find any references
    on their Web site). AFAIK, the only private values you can obtain from IEEE are OUIs,
    and you must pay USD $1,650/year per private OUI to maintain privacy (that on top of USD $2,000 per a public OUI)

3. IEEE still requires description of the protocol before it approves your registration request, and it takes at least 90
    days before a new code point is granted. (From my experience when dealing with other SDOs IEEE requires an approved
    protocol spec lacking just the new Ethertype value in order to grant a new Ethertype codepoint.)

On top of all that, the most important issue here is that ACH has never been intended to be a new multiprotocol network layer.
This point has been raised already by the others.

Unfortunately your analogy between the ACH type and Ethertype only strengthens the suspicions that this can easily happen with an over-relaxed codepoint allocation policy.

... snipped to the end...