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

["Masayuki Takase" <masayuki.takase.vx at hitachi.com>]

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:masayuki.takase.vx at hitachi.com

----- Original Message ----- 
> Hi Loa,
>
> 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
>
> _______________________________________________
> mpls mailing list
> mpls at ietf.org
> https://www.ietf.org/mailman/listinfo/mpls




_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls