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

[Thomas Nadeau <tnadeau at lucidvision.com>]

	How could you have built MPLS OAM to support label 14? Do you mean  
you implemented Y1711 using label 14?

	--Tom


On Apr 2, 2008, at 6:37 AM, Masayuki Takase wrote:
> 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
>

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