Re: [mpls] [mpls-tp] [PWE3] Changes to PW ACH Channel Typeallocationpolicy
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mpls] [mpls-tp] [PWE3] Changes to PW ACH Channel Typeallocationpolicy
Hi Italo,
It is much more than a codepoint and ensuring the nodes are provisioned
correctly - which is in itself difficult - especially in large networks.
Here's just a partial list of additional concerns from an operator:
- proprietary protocols perpetuate the use of vendor islands - good for
a vendor/bad for an operator;-(
- each protoFrom mpls-bounces at ietf.org Fri Oct 3 07:53:07 2008
Return-Path: <mpls-bounces at ietf.org>
X-Original-To: mpls-archive at megatron.ietf.org
Delivered-To: ietfarch-mpls-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id DF81E3A6820;
Fri, 3 Oct 2008 07:53:06 -0700 (PDT)
X-Original-To: mpls at core3.amsl.com
Delivered-To: mpls at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id D880B3A6820;
Fri, 3 Oct 2008 07:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.274
X-Spam-Level:
X-Spam-Status: No, score=-106.274 tagged_above=-999 required=5
tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4,
USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 27vhBdDKjTTQ; Fri, 3 Oct 2008 07:53:03 -0700 (PDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com
[216.82.250.83])
by core3.amsl.com (Postfix) with ESMTP id 6C7A33A6765;
Fri, 3 Oct 2008 07:53:03 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: dbrungard at att.com
X-Msg-Ref: server-12.tower-120.messagelabs.com!1223045541!41660334!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 20948 invoked from network); 3 Oct 2008 14:52:22 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com)
(144.160.20.54)
by server-12.tower-120.messagelabs.com with AES256-SHA encrypted SMTP;
3 Oct 2008 14:52:22 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1])
by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id
m93EqLd7012603; Fri, 3 Oct 2008 10:52:21 -0400
Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com
[135.53.26.19])
by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id
m93EqGVS012542; Fri, 3 Oct 2008 10:52:16 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 3 Oct 2008 10:52:15 -0400
Message-ID: <D6CB948F7AFD6F4881D4B4F80C8509AA0124B2E4 at gaalpa1msgusr7e.ugd.att.com>
In-Reply-To: <6FD21B53861BF44AA90A288402036AB40193F9F1 at FRVELSMBS21.ad2.ad.alcatel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mpls-tp] [mpls] [PWE3] Changes to PW ACH Channel
Typeallocationpolicy
Thread-Index: AckkQ71IH8+xzlBPTXyZ2QuPfVC+nQAT4P0wAAFwrKAAI6eCgAAPAbNQ
References: <0458D2EE0C36744BABB36BE37805C29A029C6251 at FRVELSMBS11.ad2.ad.alcatel.com><639AAB99-9B29-40B1-A57D-C3476D87696C at castlepoint.net><D6CB948F7AFD6F4881D4B4F80C8509AA01208045 at gaalpa1msgusr7e.ugd.att.com>
<7DBAFEC6A76F3E42817DF1EBE64CB02605E3E1D2 at ftrdmel2>
<6FD21B53861BF44AA90A288402036AB40193F9F1 at FRVELSMBS21.ad2.ad.alcatel.com>
From: "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard at att.com>
To: "BUSI ITALO" <Italo.Busi at alcatel-lucent.it>
Cc: l2vpn at ietf.org, mpls at ietf.org, ccamp at ietf.org, pwe3 at ietf.org,
mpls-tp at ietf.org
Subject: Re: [mpls] [mpls-tp] [PWE3] Changes to PW ACH Channel
Typeallocationpolicy
X-BeenThere: mpls at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>,
<mailto:mpls-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mpls>
List-Post: <mailto:mpls at ietf.org>
List-Help: <mailto:mpls-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>,
<mailto:mpls-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mpls-bounces at ietf.org
Errors-To: mpls-bounces at ietf.org
Hi Italo,
It is much more than a codepoint and ensuring the nodes are provisioned
correctly - which is in itself difficult - especially in large networks.
Here's just a partial list of additional concerns from an operator:
- proprietary protocols perpetuate the use of vendor islands - good for
a vendor/bad for an operator;-(
- each protocol, procol, proprietary or not, for an operator requires testing of
the protocol itself, not just if it works as it should, but also
development and testing of failure scenarios, and the negotiation with
the vendor for fixes. And if it's proprietary, an operator is on their
own for determining bugs, determining the correct fix, testing the fix,
etc, etc.
- OS development - this is probably the biggest hit on time for
deployment and most costly (and it's not just for deployment, it
continues for the lifetime).
Which is why we have standards. I'm sure the others can add many more
(still on my first coffee here) and take a look back over Shane's mails.
Deborah
-----Original Message-----
From: BUSI ITALO [mailto:Italo.Busi at alcatel-lucent.it]
Sent: Friday, October 03, 2008 3:39 AM
To: julien.meuric at orange-ftgroup.com; BRUNGARD, DEBORAH A, ATTLABS;
shane at castlepoint.net; BOCCI Matthew
Cc: l2vpn at ietf.org; mpls at ietf.org; ccamp at ietf.org; pwe3 at ietf.org;
mpls-tp at ietf.org
Subject: RE: [mpls-tp] [mpls] [PWE3] Changes to PW ACH Channel
Typeallocationpolicy
Julien, Tom, Shane and Deborah,
it looks like you have a common position regarding interoperability
issues of proprietary protocols.
I can understand your issues with proprietary protocols because, by
definition, they do not interoperate.
However please note that all proprietary protocols by default must be
disabled and enabled if and only if it is known that all the nodes that
need to process the proprietary packets are capable to support the
proprietary protocol. As such you can simply never enable any
proprietary protocol.
I fail to understand how the allocation policy of ACH codepoints for
proprietary use can change the management issues from your point of
view.
Italo
> -----Original Message-----
> From: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org]
> On Behalf Of julien.meuric at orange-ftgroup.com
> Sent: Thursday, October 02, 2008 5:18 PM
> To: dbrungard at att.com; shane at castlepoint.net; BOCCI Matthew
> Cc: l2vpn at ietf.org; mpls at ietf.org; ccamp at ietf.org;
> pwe3 at ietf.org; mpls-tp at ietf.org
> Subject: RE: [mpls-tp] [mpls] [PWE3] Changes to PW ACH
> Channel Typeallocationpolicy
>
> Hi.
>
> I must agree with Deborah and Shane.
>
> Option #3 hides the complexity behind a (useless) hierarchy and is
> clearly not desired. Option #2 would create an explicit non standard
> range and is not what we expect from the IETF.
> As a result, since changing the former process seems already
> committed,
> option #1 remains the better compromise.
>
> Regards,
>
> Julien
>
>
> -----Original Message-----
> From: mpls-tp-bounces at ietf.org [mailto:mpls-tp-bounces at ietf.org] On
> Behalf Of BRUNGARD, DEBORAH A, ATTLABS
>
> Agree- and with the strong wording that option #1 is not for
> SDOs/Forums. Option 2 (or the 3rd option being discussed),
> may be viewed
> as no bottleneck for vendors on development of proprietary
> options, but
> for operators, it will be an interoperability nightmare.
> Deborah
>
> -----Original Message-----
> From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On
> Behalf Of
> Shane Amante
>
> Matthew,
>
> Speaking as an operator, (L2VPN WG co-chair hat off), I would also
> prefer the existing mechanism that's already in place: expert review
> and IETF consensus. After all, there are significant benefits to
> standards-based OAM and signaling protocols. On the other
> hand, some
> people may still have a legitimate need to do uncommon things that
> aren't considered mainstream. In that case, I would rather see a
> (small) subset of codepoints allocated for expert review with
> no IETF
> consensus (Option #1 below).
>
> -shane
>
>
> On Sep 30, 2008, at 10:23 AM, BOCCI Matthew wrote:
> > 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: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org]
> On Behalfprietary or not, for an operator requires testing of
the protocol itself, not just if it works as it should, but also
development and testing of failure scenarios, and the negotiation with
the vendor for fixes. And if it's proprietary, an operator is on their
own for determining bugs, determining the correct fix, testing the fix,
etc, etc.
- OS development - this is probably the biggest hit on time for
deployment and most costly (and it's not just for deployment, it
continues for the lifetime).
Which is why we have standards. I'm sure the others can add many more
(still on my first coffee here) and take a look back over Shane's mails.
Deborah
-----Original Message-----
From: BUSI ITALO [mailto:Italo.Busi at alcatel-lucent.it]
Sent: Friday, October 03, 2008 3:39 AM
To: julien.meuric at orange-ftgroup.com; BRUNGARD, DEBORAH A, ATTLABS;
shane at castlepoint.net; BOCCI Matthew
Cc: l2vpn at ietf.org; mpls at ietf.org; ccamp at ietf.org; pwe3 at ietf.org;
mpls-tp at ietf.org
Subject: RE: [mpls-tp] [mpls] [PWE3] Changes to PW ACH Channel
Typeallocationpolicy
Julien, Tom, Shane and Deborah,
it looks like you have a common position regarding interoperability
issues of proprietary protocols.
I can understand your issues with proprietary protocols because, by
definition, they do not interoperate.
However please note that all proprietary protocols by default must be
disabled and enabled if and only if it is known that all the nodes that
need to process the proprietary packets are capable to support the
proprietary protocol. As such you can simply never enable any
proprietary protocol.
I fail to understand how the allocation policy of ACH codepoints for
proprietary use can change the management issues from your point of
view.
Italo
> -----Original Message-----
> From: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org]
> On Behalf Of julien.meuric at orange-ftgroup.com
> Sent: Thursday, October 02, 2008 5:18 PM
> To: dbrungard at att.com; shane at castlepoint.net; BOCCI Matthew
> Cc: l2vpn at ietf.org; mpls at ietf.org; ccamp at ietf.org;
> pwe3 at ietf.org; mpls-tp at ietf.org
> Subject: RE: [mpls-tp] [mpls] [PWE3] Changes to PW ACH
> Channel Typeallocationpolicy
>
> Hi.
>
> I must agree with Deborah and Shane.
>
> Option #3 hides the complexity behind a (useless) hierarchy and is
> clearly not desired. Option #2 would create an explicit non standard
> range and is not what we expect from the IETF.
> As a result, since changing the former process seems already
> committed,
> option #1 remains the better compromise.
>
> Regards,
>
> Julien
>
>
> -----Original Message-----
> From: mpls-tp-bounces at ietf.org [mailto:mpls-tp-bounces at ietf.org] On
> Behalf Of BRUNGARD, DEBORAH A, ATTLABS
>
> Agree- and with the strong wording that option #1 is not for
> SDOs/Forums. Option 2 (or the 3rd option being discussed),
> may be viewed
> as no bottleneck for vendors on development of proprietary
> options, but
> for operators, it will be an interoperability nightmare.
> Deborah
>
> -----Original Message-----
> From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On
> Behalf Of
> Shane Amante
>
> Matthew,
>
> Speaking as an operator, (L2VPN WG co-chair hat off), I would also
> prefer the existing mechanism that's already in place: expert review
> and IETF consensus. After all, there are significant benefits to
> standards-based OAM and signaling protocols. On the other
> hand, some
> people may still have a legitimate need to do uncommon things that
> aren't considered mainstream. In that case, I would rather see a
> (small) subset of codepoints allocated for expert review with
> no IETF
> consensus (Option #1 below).
>
> -shane
>
>
> On Sep 30, 2008, at 10:23 AM, BOCCI Matthew wrote:
> > 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: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org]
> On Behalf
> > O
> > Of
> > BOCCI Matthew
> >
> > 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
> > pwe3 at ietf.org
> > https://www.ietf.org/mailman/listinfo/pwe3
>
> _______________________________________________
> mpls mailing list
> mpls at ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls-tp mailing list
> mpls-tp at ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls
f
> > BOCCI Matthew
> >
> > 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
> > pwe3 at ietf.org
> > https://www.ietf.org/mailman/listinfo/pwe3
>
> _______________________________________________
> mpls mailing list
> mpls at ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls-tp mailing list
> mpls-tp at ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
