Subject: RE: Question on the status of Y.1711 and RFC3429

From: "Masayuki Takase" <[email-masked]>
Date: Wed, 2 Apr 2008 19:43:33 +0900

Hi Loa,

Hitachi has implemented Transport Switch chips that support MPLS OAM using 
the Label 14. Therefore we disagree to the modification of the existing 
RFC3429 document.
So we also suggest using a different label for the new function.

Regards,
-----------------------------------
Masayuki Takase
Hitachi, Communication Technologies, Ltd.
216 Totsuka-cho, Totsuka-ku,
Yokohama-shi 244-8567, Japan
Tel: +81-45-865-7003(Ext.4094)
Email:[email-masked]

----- Original Message ----- 
> Hi,
>
> Yes we have implemented the Label 14 in our packet processor/switch chips 
> as
> requested by our customers. So we suggest using a different label for the
> new function.
>
>
> Regards,
>
>    Shahram Davari | Director, Systems Engineering
>    T|PACK| 9 King's Inn Trail | Markham | Ontario L3T 1T6| Canada
>    Direct: +1 905 597 3125 | Mobile: +1 416 371 3139 | Email:
> davari at tpack.com
>    www.tpack.com
>
> TPACK CONFIDENTIAL
> Note: This message and any attachment hereto is intended solely for the 
> use
> of the designated recipient(s) and their appointed delegates and may 
> contain
> confidential information. Any unauthorized use, disclosure, copying, or
> distribution of its contents is strictly prohibited. If you have received
> this message in error, please destroy it and advise the sender immediately
> by phone or email Thank you for your cooperation.
>
>
>
>
> -----Original Message-----
> From: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org] On 
> Behalf Of
> Loa Andersson
> Sent: March-28-08 4: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
>
>
>