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

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 2 Aug 2010 18:16:01 +0100

Maarten,

On 26 Jul 2010, at 08:36, Maarten Vissers wrote:

> 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?

You appear to be assuming a steady state operation, what happens when the configuration of cross-connects in the network do not correlate with the management system's view of where the path should be? You need some method to find what exactly the path of the connection is. It could be done via 'management' (automated or manual by operations staff) or via some protocol such as path trace but I find it hard to believe that operators running the network technologies you list have no such capability at all and rely on faith that their equipment (and the staff operating it) will never misbehave (make mistakes).

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 03 Aug 2010 13:31:47 +0200

Ben,

As described there is no specific **data plane** type PathTrace OAM tool
specified in those technologies. That does not imply that there is no method
to detect that the path is different then intended... 

In managed transport networks a connection is set up and modified under
control of network management. Point&Click type user interfaces supported by
NMS based path computation and NMS controlled explicit route set up (with or
without the help of GMPLs signalling) provide full control over the paths.
NMS systems have the ability to query nodes to check if the configured
matrix connection is (still) present, and as such implement a **management
plane** type PathTrace.

As you know a connection that has unexpected endpoints is detected and
alarmed, and also a connection in which one of the intermediate matrices is
reconfigured and causes loss of continuity, different connectivitivy or
additional connectivity is detected and alarmed. NMS systems then run a
**management plane** type of Path Trace to detect the node in which the
connection was corrupted. In SDH/OTN type networks NMS can use non-intrusive
monitors at ingress (and egress) ports to locate the node in which the
matrix connection was unintentionally modified. In ATM/Ethernet type
networks NMS can use loopback and/or non-intrusive monitors to do the same.
Once the node with the modified configuration is located he connection can
be restored.

What is different in MPLS-TP that would require an additional data plane
PathTrace OAM tool? 
 
I have understood that in MPLS there is no equivalent management plane with
equivalent knowledge of paths, and as such there is a need for a tool to
figure out which nodes/ports are supporting a connection. In -TP such
management plane is however present and  such PathTrace tool would be
superfluous.

Regards,
Maarten

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: maandag 2 augustus 2010 19:16
To: Maarten Vissers
Cc: 'Alexander Vainshtein'; [email-masked]
Subject: Re: [mpls-tp] A couple of questions/comments regarding
draft-bhh-mpls-tp-oam-y1731-02

Maarten,

On 26 Jul 2010, at 08:36, Maarten Vissers wrote:

> 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?

You appear to be assuming a steady state operation, what happens when the
configuration of cross-connects in the network do not correlate with the
management system's view of where the path should be? You need some method
to find what exactly the path of the connection is. It could be done via
'management' (automated or manual by operations staff) or via some protocol
such as path trace but I find it hard to believe that operators running the
network technologies you list have no such capability at all and rely on
faith that their equipment (and the staff operating it) will never misbehave
(make mistakes).

Ben

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 03 Aug 2010 13:26:20 -0400

In message <[email-masked]>
> Once the node with the modified configuration is located he connection can

As a former customer of a provider and their largest consumer of ATM
service, I can say that 15 years ago it certainly didn't work as you
described.  The craft workers often screwed things up and the
management plane didn't catch it.  We often called in trouble only to
get insistance that nothing was wrong and everything was working
perfectly.  I'm quite sure things have improved since 13-15 years ago.

> management plane is however present and  such PathTrace tool would be

This is not true.  The same capability exists but many providers
prefer to use dynamic routing and use traceroute to verify that
packets are flowing where they expect them to be flowing.  Even
providers which use explicit paths use traceroute to verify that
traffic is flowing where they think it should be going.  They also use
LSP Ping to make sure all components of a LAG are forwarding correctly
through the pair of LSR (not just traffic originated on one or the
other LSR, failing to test the ingress forwarding).  This has no
equivalent in transport OAM or in Y.1711 or Y.1731 and is a key
requirement for LSP Ping.  Path trace also has no equivalent in
transport OAM or in Y.1711 or Y.1731 and is considered useful by
providers and is therefore also a requirement.

> Maarten

PathTrace is a requirement.  Providers use traceroute today and want
to see it continue to work.  Lets not argue further about why.  The
time for that was OAM requirements and OAM framework.

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 04 Aug 2010 12:50:01 +0200

Curtis,

> As a former customer of a provider and their largest consumer
> of ATM service, I can say that 15 years ago it certainly didn't
> work as you described.  The craft workers often screwed things
> up and the management plane didn't catch it. 

15 years ago ATM OAM and protection was non-existing. I.610 (ATM OAM) was
approved in Nov 1995, and I.630 (ATM prot) was approved in Feb 1999). 8
years ago metro ethernet networks were very unreliable, and this resulted in
the developmnt of Ethernet OAM (Y.1731) and protection switching (G.8031,
G.8032). Deploymnet of OAM and protection are known tools that make networks
reliable and give operators immediate visibility of problems in their
network. Your experience seems to be with a network not having those tools
in place.

> Path trace also has no equivalent in transport OAM or in Y.1711
> or Y.1731 and is considered useful by providers and is therefore also a
requirement.

I am aware it is a requirement in MPLS-TP and so it will become available. I
am also aware that it is not one of the necessary OAM tools in a transport
network.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 3 augustus 2010 19:26
To: Maarten Vissers
Cc: 'Ben Niven-Jenkins'; [email-masked]
Subject: Re: [mpls-tp] PathTrace OAM application? [was: RE: A couple of
questions/comments regarding draft-bhh-mpls-tp-oam-y1731-02]

Maarten Vissers writes:
>  
> Ben,
>  
> As described there is no specific **data plane** type PathTrace OAM 
> tool specified in those technologies. That does not imply that there 
> is no method to detect that the path is different then intended...
>  
> In managed transport networks a connection is set up and modified 
> under control of network management. Point&Click type user interfaces 
> supported by NMS based path computation and NMS controlled explicit 
> route set up (with or without the help of GMPLs signalling) provide full
control over the paths.
> alarmed, and also a connection in which one of the intermediate 
> matrices is reconfigured and causes loss of continuity, different 
> connectivitivy or additional connectivity is detected and alarmed. NMS 
> systems then run a **management plane** type of Path Trace to detect 
> the node in which the connection was corrupted. In SDH/OTN type 
> networks NMS can use non-intrusive monitors at ingress (and egress) 
> ports to locate the node in which the matrix connection was 
> unintentionally modified. In ATM/Ethernet type networks NMS can use
loopback and/or non-intrusive monitors to do the same.
> Once the node with the modified configuration is located he connection 
> can be restored.

As a former customer of a provider and their largest consumer of ATM
service, I can say that 15 years ago it certainly didn't work as you
described.  The craft workers often screwed things up and the management
plane didn't catch it.  We often called in trouble only to get insistance
that nothing was wrong and everything was working perfectly.  I'm quite sure
things have improved since 13-15 years ago.

> What is different in MPLS-TP that would require an additional data 
> plane PathTrace OAM tool?
>  
> I have understood that in MPLS there is no equivalent management plane 
> with equivalent knowledge of paths, and as such there is a need for a 
> tool to figure out which nodes/ports are supporting a connection. In 
> -TP such management plane is however present and  such PathTrace tool 
> would be superfluous.

This is not true.  The same capability exists but many providers prefer to
use dynamic routing and use traceroute to verify that packets are flowing
where they expect them to be flowing.  Even providers which use explicit
paths use traceroute to verify that traffic is flowing where they think it
should be going.  They also use LSP Ping to make sure all components of a
LAG are forwarding correctly through the pair of LSR (not just traffic
originated on one or the other LSR, failing to test the ingress forwarding).
This has no equivalent in transport OAM or in Y.1711 or Y.1731 and is a key
requirement for LSP Ping.  Path trace also has no equivalent in transport
OAM or in Y.1711 or Y.1731 and is considered useful by providers and is
therefore also a requirement.

> Maarten

PathTrace is a requirement.  Providers use traceroute today and want to see
it continue to work.  Lets not argue further about why.  The time for that
was OAM requirements and OAM framework.

Curtis