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

From: "Masayuki Takase" <[email-masked]>
Date: Wed, 2 Apr 2008 19:37:46 +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 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 2 Apr 2008 09:50:17 -0400

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

	--Tom

---

From: "Francesco Fondelli" <[email-masked]>
Date: Wed, 2 Apr 2008 17:09:13 +0200

>  you implemented Y1711 using label 14?

Back in 2002/2003/2004? there used to be no 'T-' :-)

http://www.itu.int/rec/T-REC-Y.1711/en

"Y.1711: Operation & Maintenance mechanism for MPLS networks"

Clear, isn't it? //I'm sarcastic

Ciao
FF

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 2 Apr 2008 19:32:45 -0400

ITU recommendation Y1711 has nothing to do with MPLS OAM.  If you  
want a
good overview of IETF MPLS OAM take a look at RFC4221.

	--Tom

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 3 Apr 2008 08:10:21 -0400

Tom,

Could you please provide your definition of MPLS OAM? I have been involved
in MPLS and OAM for more than 10 years and my understanding is that Y.1711
is the first MPLS OAM defined in the industry.

-Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Thomas Nadeau
Sent: April-02-08 7:33 PM
To: Francesco Fondelli
Cc: [email-masked]; Masayuki Takase
Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 3 Apr 2008 09:33:07 -0400

Sharam,

	Lets please not play your normal games around this. We all know what  
you are getting
at here, and I have little time or patience to play that useless game  
again...

	--Tom

---

From: Ping Pan <[email-masked]>
Date: Thu, 03 Apr 2008 06:48:18 -0700

Have to bite:

Y.1711 may be the first to be defined, but LSP-ping was the first to get 
deployed and used to solve real problems. So the age, the complexity and 
the brand name sometimes do not matter much.

Why do we try this? (Maybe we have already). Let's lay out

- the problems that Y.1711 have solved where the existing mechanisms 
defined in IETF won't be able to address, and

- how serious those problems are.

Then let's move from there.

- Ping

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 3 Apr 2008 10:05:27 -0400

Ping,

My email was not about your invention (LSP-ping). I in fact like LSP-ping
and think it is useful. I was just answering Tom's claim that "Y.1711 has
nothing to do with MPLS OAM".

Shahram
. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ping
Pan
Sent: April-03-08 9:48 AM
To: Shahram Davari
Cc: 'Masayuki Takase'; [email-masked]
Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429

Have to bite:

- Ping

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 3 Apr 2008 10:07:57 -0400

Tom,

I think you should keep your personal problems with ITU to yourself. I was
not playing any games. I was just trying to understand your strange comments
that Y.1711 has nothing to do with MPLS OAM.

Shahram

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: April-03-08 9:33 AM
To: Shahram Davari
Cc: 'Francesco Fondelli'; [email-masked]; 'Masayuki Takase'
Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429

	Sharam,

you are getting

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 3 Apr 2008 10:46:04 -0400

> Tom,
>
> I think you should keep your personal problems with ITU to yourself.

	Thanks for the advice. I may keep this in mind for the future.

> I was not playing any games.

> I was just trying to understand your strange comments

	Back to my original point: Y.1711 is not IETF "MPLS OAM", which
what the original question was about.

	--Tom

---

From: <[email-masked]>
Date: Thu, 3 Apr 2008 15:49:44 +0100

Ping....to be clear here (given I was largely responsible for Y.1711):

-	Y.1711 (and before it the requirements given in Y.1710) was
based on trying to define a generic OAM solution for any correctly
specified co-ps mode layer network technology....the key principle
underpinning it was to 'keep things as simple as possible'.

-	If one breaks the architectural rules of what defines a
connection (eg must have single source) then there are no good/simple
OAM solutions.  Or more accurately, one cannot assign/manage resource in
a co-ps technology that breaks the rules of a connection.  BTW - One
cannot break this rule in the co-cs mode.  

-	The type of MPLS based on LDP creates merging mp2p constructs
(so does PHP on a last hop).  These are not connections.

-	LSP ping took something like 5-6 years and 13 or so
iterations....simple it is not.  The use of ECMP also greatly
complicates matters.

-	The OAM required to detect/handle defects in a properly
architected co-ps or co-cs mode layer network should be unidirectional
(and not of a request/response nature) for many reasons.....co-ps/cs
mode OAM is not like cl-ps mode OAM because connections create
constraining constructs under normal operation. 

So, having defined LDP (and PHP + ECMP) then Y.1711 is no good for this
type of MPLS....but this is not the fault of Y.1711 of course.  

regards, Neil

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ping Pan
> Sent: 03 April 2008 14:48
> To: Shahram Davari
> > Could you please provide your definition of MPLS OAM? I have been 
> > involved in MPLS and OAM for more than 10 years and my 
> understanding 
> > is that Y.1711 is the first MPLS OAM defined in the industry.
> > 
> > -Shahram
> > 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Thomas Nadeau

---

From: "Italo Busi" <[email-masked]>
Date: Thu, 3 Apr 2008 18:33:03 +0200

Tom,

I am feeling very unconfortable with the way this discussion is progressing.

There was a reasonable request coming from the chair to investigate whether
there are implementations and/or deployment of RFC3429 and Y.1711. Most of the
people are fairly reporting the status of their implementations/deployments.

I do not see why comparing Y.1711 against LSP Ping fits into this thread.

In addition I fail to understand the value of arguing against an approved ITU-T
Recommendation (i.e. Y.1711) recognized by IETF (i.e. RFC3429) expecially now
that ITU-T and IETF are improving the collaboration among themselves.

Italo

> Behalf Of Thomas Nadeau
> Sent: Thursday, April 03, 2008 3:33 PM
> To: Shahram Davari
> Cc: [email-masked]; 'Masayuki Takase'
> > involved
> > in MPLS and OAM for more than 10 years and my understanding 
> is that  
> > Y.1711
> > Of

---

From: Ping Pan <[email-masked]>
Date: Thu, 03 Apr 2008 10:52:29 -0700

Hi Neil,

First, I think you have made some very good observation. In fact, I 
agree with you on the point where, if a connection is no longer p2p, OAM 
would be tough to deal with.

You have brought up ECMP. As some of us have discussed in private, the 
reality could be worse. In case of ECMP, we at least know there may be 
multiple routes within a segment of the connection. If we consider 
Ethernet Link Aggregation (LAG), the packets may go over different 
physical links without the knowledgeable of upper layer OAM protocols.

However, this is not the fault of MPLS. MPLS is the mechanism to forward 
packets over the connections defined by routing and underlying physical 
topology.

To deal with this kind of complex scenarios, one tool is not enough! 
This is where a combination of LSP-ping, BFD and OAM interworking 
techniques could help us solving the problem. If we find new problems, 
let's put fixes into the defined and deployed mechanisms.

As I have mentioned before, let's put all the problems on the table for 
discussion. Simply pushing standard may not be the best way to solve 
problems.

Does it make sense?

Regards,

- Ping