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

From: Lou Berger <[email-masked]>
Date: Thu, 02 Oct 2008 11:13:02 -0400

Shane,
         Your comments make a lot of sense to me.  Particularly your 
last point.

Lou

At 10:43 AM 10/2/2008, Shane Amante wrote:
>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.
>
>
>>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.
>
>
>>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.
>
>
>>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.
>
>-shane (speaking only for himself, not as co-chair)
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls
>

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

---

From: Loa Andersson <[email-masked]>
Date: Thu, 02 Oct 2008 17:21:24 +0200

<chair hat off>

makes great sense, thanks Shane!

</chair hat off>

/Loa

Shane Amante wrote:
>> 1) Allows vendors to not expose their proprietary techniques to their
>> competitors. 
> 
> 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.
> 
> 
>> 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.
> 
> 
> 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.
> 
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                           [email-masked]
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 2 Oct 2008 21:12:22 +0530

Hi Shane,

> to run contrary to that goal.

Thanks for the detailed mail regarding your point of view.

So if I got you right, your opposition to the idea I proposed is based
on the fact that you are against allowing any proprietary ACH code
points as they would not be *standard based*. The options mentionend
by Matthew are however to address the request for *proprietary
extensions*. Am I missing the point altogather?

Thanks,
Vishwas

---

From: "BOCCI Matthew" <[email-masked]>
Date: Thu, 2 Oct 2008 18:50:56 +0200

Shane,

We are not proposing changing the allocation policy for the whole
registry here. We can allocate, say, 1024 channel types by the new
method, and leave the rest for IETF consensus.

Regards

Matthew 

> -----Original Message-----
> From: Shane Amante [mailto:[email-masked]] 
> Sent: 02 October 2008 17:04
> To: Vishwas Manral
> Cc: Shahram Davari; BUSI ITALO; [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
> 
> Vishwas,
> 
> Vishwas Manral wrote:
> > Hi Shane,
> > 
> >> in which MPLS-TP could seamlessly interoperate within 
> (existing) MPLS 
> >> 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.
> > 
> Please note that I did not exclude Matthew's proposal #1 in 
> the response you quoted above.  However, I did recommend that 
> if the consensus was to adopt Matthew's proposal #1 I would 
> rather see it modified, so only a
> (small) subset of codepoints (not the whole range of ACH's) 
> were designated for "proprietary use", (still with expert 
> review).  Please refer back to my first e-mail on this 
> subject, where my position should be more clear:
> http://www.ietf.org/mail-archive/web/pwe3/current/msg09945.html
> 
> -shane
>

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 3 Oct 2008 10:11:15 +0200

See my comments in line marked with [ib] 

> From: Shahram Davari [mailto:[email-masked]] 
> Sent: Thursday, October 02, 2008 6:06 PM
> To: Shane Amante
> Cc: BUSI ITALO; Vishwas Manral; [email-masked]; BOCCI 
> Subject: RE: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel 
> Type allocationpolicy
> 
> Hi Shane,
> 
> Please see my response in-line. 
> 
> Best regards,
> Shahram
> 
> 
> Sent: October-02-08 10:43 AM
> To: Shahram Davari
> Cc: BUSI ITALO; Vishwas Manral; [email-masked]; BOCCI 
> > 1) Allows vendors to not expose their proprietary 
> techniques to their competitors. 
> 
> [Shahram] OTOH it encourages more innovation and 
> differentiation by vendors.
> 

[ib] I fully agree with Shaharm. This is exactly the objective of the
requirement to allow vendor proprietary extensions.

> [Shahram] Not if the inventing vendor is not willing to do so.
> 
> 
> *slightly* 
> [Shahram] You are correct. 16-bit is sufficient enough.
> 

[ib] I agree that the codepoint space is big enough and the codepoint
exhaustion is not a real issue.

However, with both option 1 and 2, we still have an open point to decide
how many codepoints we need to reserve for proprietary use and this is
not an easy task.

Option 3 has the advantage that we just need to allocate a single
codepoint.

> 
> > 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.
> 
> 
> signaling, 
> [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.
> 

[ib] I agree. Standard actions is definitely the preferred approach to
enhance the technology and MUST be pursed as much as possible.
BTW this is why we are all spending huge efforts to progress standard
activities.
However there are cases where multi-vendor interoperability is not an
issue/requirement and fast time to market is a key requirement, where
standard action is not appropriate.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 3 Oct 2008 10:45:47 +0200

" it encourages more innovation and differentiation by vendors". 
If there are some innovations (which is of course encouraged), why not
pushing it to be a standard behavior? 
I am pretty sure SPs will be happier to see it working in multi vendor
environment than as a proprietary solution that is supported by one
vendor only.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext BUSI ITALO
Sent: Friday, October 03, 2008 11:11
To: Shahram Davari; Shane Amante
Cc: [email-masked]; [email-masked]; BOCCI Matthew; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [PWE3] [mpls-tp] FW: Changes to PW ACH ChannelType
allocationpolicy

---

From: Loa Andersson <[email-masked]>
Date: Mon, 06 Oct 2008 12:12:33 +0200

All,

most IETF lists has a limit to how many recipients they allow on a
single mail. If we just keep responding to the last mail with a
"reply to all" the recipients list keep building up and actions by
list administrators is needed to let your mail be forwarded to the
list(s).

I've three suggestions:

1. We keep *discussion* of this just to the pwe3-list, now we all know
   that is is going on and are able to follow it on that list
2. when the pwe3 wg chairs make the consensus call they send it to all
   the lists it was originally sent to
3. We all make it a habit to prune the recipients-list to what is
   necessary (please make the assumption that people sending mails to
  IETF-lists are subscribed to the lists).

/Loa

Maarten Vissers wrote:
> Ben,
> 
> Also in case of a multi-vendor network there should be no issue. The new
> functionality is present only in the UNI-N ports (i.e. where the service is
> mapped into the PW). When you deploy such new functionality in UNI-N ports
> contained in Network Termination devices you can deploy those NT devices
> from one vendor. The main network now only has to carry the MS-PW between
> the NT devices at the edge of the network. The main network is as such
> agnostic to the new functionality.
> 
> The use of NT devices to support new (non standard) services not only allows
> differentiation by vendors, but also differentiation by operators. Operators
> wanting to differentiate their service offerings can ask a NT device vendor
> to add their operator specific service to the NT device.
> 
> Regards,
> Maarten
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben
> Niven-Jenkins
> Sent: 02 October 2008 19:30
> [email-masked]; [email-masked]; BUSI ITALO
> Subject: Re: [PWE3] [mpls-tp] FW: Changes to PW ACH Channel Type
> allocationpolicy
> 
> On 02/10/2008 17:05, "Shahram Davari" <[email-masked]> wrote:
>> From: Shane Amante [mailto:[email-masked]] Shahram Davari 
>> wrote:
>>> Hi,
>>>
>> [Shahram] OTOH it encourages more innovation and differentiation by
> vendors.
> 
> Which is fine until you run a multi-vendor network.
> 
> Ben
> 

-- 
Loa Andersson

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 02 Oct 2008 12:43:31 -0400

I agree with %100 of Shane's comments. One bit to add below:

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

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 02 Oct 2008 18:29:49 +0100

Ben

---

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

Ben,

Regards,
Maarten

-----Original Message-----

vendors.

Ben

---

From: <[email-masked]>
Date: Thu, 9 Oct 2008 18:36:26 +0200

Hi Maarten.

That might be true sometimes, but the IETF allocation policy is not the
limiting factor in that kind of processes... ;-)

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Maarten Vissers

[...]

The use of NT devices to support new (non standard) services not only
allows
differentiation by vendors, but also differentiation by operators.
Operators
wanting to differentiate their service offerings can ask a NT device
vendor
to add their operator specific service to the NT device.

Regards,
Maarten

---

From: "BOCCI Matthew" <[email-masked]>
Date: Mon, 20 Oct 2008 17:44:42 +0200

It is not clear that there is rough consensus for changing the
allocation policy for the ACH channel type to be either expert review or
first come first served or any of the other proposed options.
Nevertheless, there are a significant number of participants who would
like to be able to develop and test proprietary ACH protocols prior to
any proposal for a standardised function being made.

We would therefore like to propose the following way forward. This is to
allocate a small range (say 16) of Experimental code points. These would
follow the rules of RFC3692, should be disabled by default, and mapping
of a code point to any specific function must be configurable. The
remainder of the channel type registry would remain as IETF consensus.

Please reply with any comments to the PWE3 list only.

Regards

Matthew

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: 09 October 2008 17:36
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [PWE3] [mpls] [mpls-tp] FW: Changes to PW ACH 
> ChannelTypeallocationpolicy
> 
> Hi Maarten.
> 
> That might be true sometimes, but the IETF allocation policy 
> is not the limiting factor in that kind of processes... ;-)
> 
> Regards,
> 
> Julien
> 
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Maarten Vissers
> 
> [...]
> 
> The use of NT devices to support new (non standard) services 
> not only allows differentiation by vendors, but also 
> differentiation by operators.
> Operators
> wanting to differentiate their service offerings can ask a NT 
> device vendor to add their operator specific service to the NT device.
> 
> Regards,
> Maarten

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Fri, 24 Oct 2008 15:31:15 +0200

Hi Matthew,

I can support that.

Regards
Annamaria  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BOCCI Matthew
Sent: lunedì 20 ottobre 2008 17.45
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [PWE3] [mpls] FW: Changes to PW ACHChannelTypeallocationpolicy

It is not clear that there is rough consensus for changing the allocation policy for the ACH channel type to be either expert review or first come first served or any of the other proposed options.
Nevertheless, there are a significant number of participants who would like to be able to develop and test proprietary ACH protocols prior to any proposal for a standardised function being made.

We would therefore like to propose the following way forward. This is to allocate a small range (say 16) of Experimental code points. These would follow the rules of RFC3692, should be disabled by default, and mapping of a code point to any specific function must be configurable. The remainder of the channel type registry would remain as IETF consensus.

Regards

Matthew