Re: [mpls] [PWE3] Question on the status of Y.1711 and RFC3429

["Shahram Davari" <davari at ieee.org>]

Loa, George and all,

TPACK has implemented Y.1711 using label 14 and TPACK's customers have
reported Y.1711 has been deployed and in operation by the network operators
using their products.

Therefore TPACK objects to deprecation of the Label 14 allocation that is
currently defined in RFC 3429 and suggests using a different reserved label
value for T-MPLS needs.

Regards,
Shahram Davari
TPACK

-----Original Message-----
From: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] On Behalf Of
Alexander Vainshtein
Sent: April-03-08 7:39 AM
To: Loa Andersson; swallow at cisco.com; mpls at ietf.org
Cc: L2VPN; l3vpn at ietf.org; ccamp; pwe3; David Ward
Subject: Re: [PWE3] Question on the status of Y.1711 and RFC3429

Loa, George and all,
ECI Telecom has implemented ITU-T recommendation Y.1711 using 
Label 14 as defined in RFC 3429 in its XDM (TM) products family. 

The corresponding products have been deployed in live 
networks, and their Y.1711-related functionality is now in 
operational use.

Based on this, we (ECI) object to deprecation of the Label 14 
allocation that is currently defined in RFC 3429 and suggests using
a different reserved label value for T-MPLS needs.

Regards,
                   Sasha 

> -----Original Message-----
> From: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org] 
> On Behalf Of Loa Andersson
> Sent: Friday, March 28, 2008 11:50 AM
> To: mpls at ietf.org; pwe3; l3vpn at ietf.org; L2VPN; ccamp
> Cc: Ross Callon; David Ward
> Subject: Question on the status of Y.1711 and RFC3429
> 
> All,
> 
> In the discussions the IETF and the ITU-T have had on T-MPLS we have
> discussed the intended use for label 14 and the different documents
> where this has been specified.
> 
> As a side effect we've also started to ask ourselves if there are any
> implementations and/or deployments that uses label 14.
> 
> A quick survey among known implementers of MPLS has not shown any
> implementations/deployments.
> 
> Since one of the approaches discussed in the Joint Working Team
> context is a solution that requires the allocation of a reserved
> label and reserved labels are a scarce resource we'd like to know
> if it possible to redefine label 14 for that particular use.
> 
> There are still technical issues to be sorted out with the suggested
> approach, but in the mean time we would like to know if it is possible
> to deprecate RFC3429 and redefine the OAM Alert Label.
> 
> The questions is: "Are there any implementations/deployments of Y.1711
> or the OAM Alert label as it is allocated in RFC3429; and is there
> objection to deprecating the protocol as it stands today?"
> 
> ITU-T has sent out a question along the same lines, see the included
> mail below.
> 
> Please respond to the mpls working group mailing list or to the mpls
> working chairs directly. As usual non-responses will be counted as
> that there is no implementation/deployment.
> 
> Loa and George
> 
> 
> ------------------- included mail ------------------------------------
> 
> All users/implementers of recommendation Y.1711,
> 
> Currently the Joint Working Team of ITU-T and IETF experts is
> considering the options of using IETF mechanisms to provide
> OAM for T-MPLS.
> 
> One possibility is the following mechanism:
> -------------------------------------------
> Push/pop a label at the MEP/domain boundary.
> 
> This makes the OAM alert label directly visible at the
> sink MEP.
> 
> To make the OAM label visible to a MIP the TTL in the server
> (lower) layer is set by the MEP to expire when the OAM frame
> reaches the intended MIP.
> 
> The OAM alert label will point to an "opcode" at the bottom
> of the stack.
> ------------------------------------------
> 
> This behaviour (when the OAM alert label is received) is not
> consistent with the behaviour currently defined in Y.1711 when
> label 14 is received.
> 
> *QUESTION* are there any users/implementers of the current Y.1711
> concerned with this change in behaviour?
> 
> If there are no concerns then recommendation Y.1711 can be
> withdrawn or revised to describe the desired behaviour (described
> above).
> 
> Please send me (or this list) your response ASAP.
> 
> Kind regards, Huub van Helvoort, your rapporteur.
> 
> -- 
> Loa Andersson
> 
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  loa.andersson at acreo.se
>                                             loa at pi.se
> 
_______________________________________________
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