Subject: [mpls-tp] A couple of questions/comments regarding draft-bhh-mpls-tp-oam-y1731-02

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 21 Jul 2010 16:16:37 +0300

Hi all,
I've looked up draft-bhh-mpls-tp-oam-y1731-02<http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-02> and it seems that traceroute (a.k.a. linktrace) OAM  function  is missing there.
There is an Editor's note saying:
Clarify that LTM/LTR, as currently defined in Y.1731, are not applicable to MPLS-TP.
While I agree that LTM, as defined in Y.1731, is not applicable to MPLS-TP, it would be nice to know the Editors' explanation (which may differ from my own:)).

Another question deals with the presence of MEL in the proposed PDUs. Could you please explain what is its meaning in the MPLS-TP context? (To the best of my understanding, in MPLS-TP ME = LSP, MEPs can be defined only at the LSP end points, and hence ME levels are meaningless; did I miss something)?

Regards,
     Sasha

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 21 Jul 2010 09:36:09 -0700

Dear Sasha,
according to my search
-04<http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-04>is the
latest version of the draft. I hope that the group will discuss the
document even if it not presented at the WG meeting.
I agree that MEL is not functional in MPLS-TP, level of MEG, in my
understanding, implied, not expressed explicitly, signaled in MPLS-TP.

Dear Authors and All,
I think that it is interesting to discuss changing G-ACh encapsulation. I'd
propose to remove MEL, use G-ACh Tunnel Type to closer reflect OpCode (can
use ACH TLV), and ACH TLV for versioning and Flags. And, in my view,
adaptation of Y.1731 requires use of MPLS-TP IDs, i.e. Unique MEP ID. Then
we might see that G-ACh encapsulation is close to one defined for BFD-based
CV-CC-RDI. And that might a good thing.

Regards,
Greg

On Wed, Jul 21, 2010 at 6:16 AM, Alexander Vainshtein <
[email-masked]> wrote:
> Hi all,
>
> I’ve looked up draft-bhh-mpls-tp-oam-y1731-02 and it seems that traceroute
> (a.k.a. linktrace) OAM  function  is missing there.
>
> There is an Editor’s note saying:
>
> Clarify that LTM/LTR, as currently defined in Y.1731, are not applicable
to
> MPLS-TP.
>
> While I agree that LTM, as defined in Y.1731, is not applicable to
MPLS-TP,
> it would be nice to know the Editors’ explanation (which may differ from
my
> ownJ).
>
>
>
> Another question deals with the presence of MEL in the proposed PDUs.
Could
> you please explain what is its meaning in the MPLS-TP context? (To the
best
> of my understanding, in MPLS-TP ME = LSP, MEPs can be defined only at the
> LSP end points, and hence ME levels are meaningless; did I miss
something)?
>
>
>
> Regards,
>
>      Sasha
>
>
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
>

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 22 Jul 2010 08:38:04 +0200

Sasha,
 
Link Trace is a tool which checks a connectionless flow forwarding rule
within the mp2mp or rmp transport path; i.e. it checks if a DA is registered
along the mp2mp or rmp transport path. As MPLS-TP only supports p2p and p2mp
transport paths, there is no need to register any DAs inside the transport
path's switching functions. As such Link Trace is not an applicable tool in
MPLS-TP.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: woensdag 21 juli 2010 15:17
To: [email-masked]; BUSI ITALO; [email-masked]
Cc: Mishael Wexler; [email-masked]; Rotem Cohen; Agmon;
[email-masked]
Subject: [mpls-tp] A couple of questions/comments regarding
draft-bhh-mpls-tp-oam-y1731-02

Hi all,

I've looked up draft-bhh-mpls-tp-oam-y1731-02
<http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-02>  and it seems
that traceroute (a.k.a. linktrace) OAM  function  is missing there.

Clarify that LTM/LTR, as currently defined in Y.1731, are not applicable to
MPLS-TP.

While I agree that LTM, as defined in Y.1731, is not applicable to MPLS-TP,
it would be nice to know the Editors' explanation (which may differ from my
ownJ).

Another question deals with the presence of MEL in the proposed PDUs. Could
you please explain what is its meaning in the MPLS-TP context? (To the best
of my understanding, in MPLS-TP ME = LSP, MEPs can be defined only at the
LSP end points, and hence ME levels are meaningless; did I miss something)?

Regards,

     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 22 Jul 2010 14:12:38 +0300

Maarten,

Please take a look at section 2.2.4 "Route Tracing" of RFC 5860<http://datatracker.ietf.org/doc/rfc5860/>. The first statement in this section states:

The MPLS-TP OAM toolset MUST provide functionality to enable an End Point to discover the Intermediate (if any) and End Point(s) along a PW, LSP, or Section, and more generally to trace the route of a PW,  LSP, or Section.  The information collected MUST include identifiers related to the nodes and interfaces composing that route.
Looks like the IETF position on route/link trace for is different from yours.
Regards,
     Sasha

From: Maarten Vissers [mailto:[email-masked]]
Sent: Thursday, July 22, 2010 9:38 AM
To: Alexander Vainshtein; [email-masked]; 'BUSI ITALO'; [email-masked]
Cc: Mishael Wexler; [email-masked]; Rotem Cohen; Gideon Agmon; [email-masked]
Subject: RE: [mpls-tp] A couple of questions/comments regarding draft-bhh-mpls-tp-oam-y1731-02

Sasha,

Link Trace is a tool which checks a connectionless flow forwarding rule within the mp2mp or rmp transport path; i.e. it checks if a DA is registered along the mp2mp or rmp transport path. As MPLS-TP only supports p2p and p2mp transport paths, there is no need to register any DAs inside the transport path's switching functions. As such Link Trace is not an applicable tool in MPLS-TP.

Regards,
Maarten

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: woensdag 21 juli 2010 15:17
To: [email-masked]; BUSI ITALO; [email-masked]
Cc: Mishael Wexler; [email-masked]; Rotem Cohen; Agmon; [email-masked]
Subject: [mpls-tp] A couple of questions/comments regarding draft-bhh-mpls-tp-oam-y1731-02
Hi all,
I've looked up draft-bhh-mpls-tp-oam-y1731-02<http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-02> and it seems that traceroute (a.k.a. linktrace) OAM  function  is missing there.
There is an Editor's note saying:
Clarify that LTM/LTR, as currently defined in Y.1731, are not applicable to MPLS-TP.
While I agree that LTM, as defined in Y.1731, is not applicable to MPLS-TP, it would be nice to know the Editors' explanation (which may differ from my own:)).

Regards,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 22 Jul 2010 14:24:44 +0300

Dear Greg,
Lots of thanks for the input. I have found that the latest version of the draft in the IETF repository is actually -05<https://datatracker.ietf.org/doc/draft-bhh-mpls-tp-oam-y1731/> (dated July 12).

This version simply does not mention route/link trace, LTM/LTR etc (the Editor's  note from -02 has disappeared).
Please note that RFC 5860 contains a MUST level requirement for the route/link trace tool. The draft, at least in its present form, simply ignores this requirement.

Regards,
     Sasha

From: Greg Mirsky [mailto:[email-masked]]
Sent: Wednesday, July 21, 2010 7:36 PM
To: Alexander Vainshtein
Cc: [email-masked]; BUSI ITALO; [email-masked]; Mishael Wexler; [email-masked]; Rotem Cohen; Gideon Agmon; [email-masked]
Subject: Re: [mpls-tp] A couple of questions/comments regarding draft-bhh-mpls-tp-oam-y1731-02

Dear Sasha,
according to my search -04<http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-04> is the latest version of the draft. I hope that the group will discuss the document even if it not presented at the WG meeting.
I agree that MEL is not functional in MPLS-TP, level of MEG, in my understanding, implied, not expressed explicitly, signaled in MPLS-TP.

Dear Authors and All,
I think that it is interesting to discuss changing G-ACh encapsulation. I'd propose to remove MEL, use G-ACh Tunnel Type to closer reflect OpCode (can use ACH TLV), and ACH TLV for versioning and Flags. And, in my view, adaptation of Y.1731 requires use of MPLS-TP IDs, i.e. Unique MEP ID. Then we might see that G-ACh encapsulation is close to one defined for BFD-based CV-CC-RDI. And that might a good thing.

Regards,
Greg

On Wed, Jul 21, 2010 at 6:16 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
> Hi all,
>
> I've looked up draft-bhh-mpls-tp-oam-y1731-02 and it seems that traceroute
> [email-masked]<mailto:[email-masked]>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 26 Jul 2010 09:36:31 +0200

Sasha,
 
The quoted text describes a very different capability then what Ethernet
LinkTrace provides.
 
Ethernet OAM does not provide a tool that allows you to discover the nodes
passed through by a specific VLAN. Neither do PDH, SDH, ATM and OTN need
such OAM tool. Managed networks know where there connections are...
 
I am aware that MPLS-TP OAM requirements include such PathTrace requirement,
and I have always wondered why this kind of tool would be needed in MPLS-TP
networks and not in PDH, SDH, ATM, OTN and Ethernet VLAN networks.... do we
expect that MPLS-TP networks are so much worse in knwoing where there
connections are then those other transport networks? Or was there a
misunderstanding between tracing "flow connectivity" within a rmp/mp2mp
connection versus tracing the "path" of a p2p/p2mp connection?
 
MPLS-TP would need an equivalent LinkTrace tool if it would support
"connectionless" LSPs; i.e. rmp or mp2mp LSPs in which the inner label is
used to control forwarding of a packet to one or more of the rmp/mp2mp LSP
output ports. It seems kind of simple to extend MPLS switches with such
functionality, as most of those switches already inspect the second label...
if you would now use the value of the second label to control forwarding of
the packet to one or more of the output ports, then you have created a rmp
or mp2mp LSP. Network management or GMPLS control plane can configure the
set of the inner flow labels in each node per rmp/mp2mp LSP; e.g. take a 11
port rmp LSP carrying 100 p2p PWs, required to deliver PWs 100-109 to LSP
port B, PWs 110-119 to LSP port C, etc. If that rmp LSP has a branching
point in the LSP transport path with e.g. four ports, then incoming on port
1 packets with inner PW label values 100 to 129 are forwarded to port 2,
packets with PW label values 130 to 169 are forwarded to port 3 and the
other packets to port 4. You can now run a MPLS-TP LSP Link Trace tool to
check if the configuration of e.g. PW packet flow #148 within the rmp LSP is
done correctly.
 
Note that there is much less to configure compared to the above if you would
used structured PW label values; e.g. have PW labels subdivided into a
source, a destination and an instance field. All PW flows within the rmp or
mp2mp LSP destined to e.g. LSP output port X will then get the same value
"X" in their destination field and forwarding would be done on the value in
this field. A strucutred PW label also would allow to perform local learning
to fill the flow table; i.e. learn the value in the source field of the PW
label of p2p PW flows and there is no need to have network management or
control plane to configure this.
 
The above is how MPLS-TP technology could support rmp and mp2mp LSPs to
support rmp and mp2mp services. Today however these services are supported
by Ethernet technology deployment in MPLS-TP networks (referred to as
HVPLS). Ethernet OAM supports as described the LinkTrace tool to check flow
connectivity (i.e. MAC address registration per VLAN/HVPLS output port).
Ethernet OAM does not (need to) support VLAN/HVPLS PathTrace.
 
Regards,
Maarten

  _____  

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: donderdag 22 juli 2010 13:13
To: Maarten Vissers
Cc: Mishael Wexler; [email-masked]; Rotem Cohen; Gideon Agmon;
[email-masked]; [email-masked]; 'BUSI ITALO'; [email-masked]
Subject: RE: [mpls-tp] A couple of questions/comments regarding
draft-bhh-mpls-tp-oam-y1731-02

Maarten,

Please take a look at section 2.2.4 "Route Tracing" of RFC
<http://datatracker.ietf.org/doc/rfc5860/> 5860. The first statement in this
section states:

The MPLS-TP OAM toolset MUST provide functionality to enable an End Point to
discover the Intermediate (if any) and End Point(s) along a PW, LSP, or
Section, and more generally to trace the route of a PW,  LSP, or Section.
The information collected MUST include identifiers related to the nodes and
interfaces composing that route.

Looks like the IETF position on route/link trace for is different from
yours.

Regards,

     Sasha

From: Maarten Vissers [mailto:[email-masked]] 
Sent: Thursday, July 22, 2010 9:38 AM
To: Alexander Vainshtein; [email-masked]; 'BUSI ITALO';
[email-masked]
Cc: Mishael Wexler; [email-masked]; Rotem Cohen; Gideon Agmon;
[email-masked]
Subject: RE: [mpls-tp] A couple of questions/comments regarding
draft-bhh-mpls-tp-oam-y1731-02

Sasha,

Regards,

Maarten

  _____  

Hi all,

Regards,

     Sasha