Subject: [mpls-tp] Addressing (my personal favorite topic)

From: "Eric Gray" <[email-masked]>
Date: Tue, 27 Jan 2009 13:55:39 -0600

On several occasions, the issue of required and default addressing has
been raised.
 
In the latest round of design team meetings, several people pointed out
that a management
channel (as a practical consideration, at least) require addresses.
 
One thing I anticipate as a comment is what addressing scheme is the
default.  I expect
that we all know that the answer to that question is IP addressing, but
I do not feel that 
the NM requirements draft is the appropriate place to make such a
statement - except as
a potential qualification of multiple choices offered in some other
document.
 
The question is: what document is the natural home for a statement on
addressing, both
required and default?
 
I looked in the MPLS-TP requirements draft, and did not find it there.
Where else might it
be found?  Given the number of times this issue has been raised, I am
sure it should be
somewhere.
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Tue, 27 Jan 2009 15:25:36 -0500

Hi Eric,

It's captured in the framework document.

Deborah

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Gray
Sent: Tuesday, January 27, 2009 2:56 PM
To: [email-masked]
Subject: [mpls-tp] Addressing (my personal favorite topic)

required and default?

somewhere.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Jan 2009 08:21:04 +0200

Eric and all,
I have been speaking about the need of an addressing scheme both in face-to-face meetings in Dublin (I did not attend the Minneapolis IETF) and in some emails. I've also tried to convince the people that addressing is required not just for network management but also for some OAM functions (e.g., the misconnection detection), and that maintaining multiple addressing schemes (with the necessary translations involved) would be sub-optimal (to put it very mildly).

The only responses I've seen so far have been from Maarten (who suggested to use the OSI addressing in network management for compatibility with legacy equipment) and Stewart's responses to the contrary.
What I have NOT seen is clear perception of the need for an addressing scheme for MPLS-TP at the conceptual/architectural level. I see Eric's message as an indication that this is not just because I've missed some fine text in the latest MPLS-TP drafts.

IMHO the big question is, how are we going to address the MPLS-TP addressing scheme (or, actually, lack of an addressing scheme for MPLS-TP)  problem.

Regards,
     Sasha

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Eric Gray [[email-masked]]
Sent: Tuesday, January 27, 2009 9:55 PM
To: [email-masked]
Subject: [mpls-tp] Addressing (my personal favorite topic)

On several occasions, the issue of required and default addressing has been raised.

In the latest round of design team meetings, several people pointed out that a management
channel (as a practical consideration, at least) require addresses.

One thing I anticipate as a comment is what addressing scheme is the default.  I expect
that we all know that the answer to that question is IP addressing, but I do not feel that
the NM requirements draft is the appropriate place to make such a statement - except as
a potential qualification of multiple choices offered in some other document.

The question is: what document is the natural home for a statement on addressing, both
required and default?

I looked in the MPLS-TP requirements draft, and did not find it there.  Where else might it
be found?  Given the number of times this issue has been raised, I am sure it should be
somewhere.
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: <[email-masked]>
Date: Wed, 28 Jan 2009 11:26:53 -0000

Sasha,  I could not agree with you (and Eric) more about this.  And yes
the addressing scheme of the traffic DP network access points will be
disjoint form that of the OOB CP/MP.  MPLS never really sorted this
(because it was so intertwined with an IP layer) and PWs made a complete
hash of this IMO (but they should never have been allowed to become a
layer network in their own right in the first place).
 
I think CCAMPs/GMPLS  experts should be a source of advice on this as
they have already had to deal with these issues for adding an OOB CP to
co-cs mode technologies (because the co-cs mode forces one to work with
an OOB CP/MP and thus have to deal with these addressing issues).
 
BTW - Most of you will know I am not a fan of nested TCM OAM levels, but
for the basic always-on CV OAM that goes between trail term pts this
should contain access point addresses and not some locally generated ID
(as was (still is?) the case with BFD).  Moreover, the CV OAM needs to
be unidirectional for many reasons.
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Alexander Vainshtein
	Sent: 28 January 2009 06:21
	To: Eric Gray; [email-masked]
	Subject: Re: [mpls-tp] Addressing (my personal favorite topic)

	Eric and all,
	I have been speaking about the need of an addressing scheme both
in face-to-face meetings in Dublin (I did not attend the Minneapolis
IETF) and in some emails. I've also tried to convince the people that
addressing is required not just for network management but also for some
OAM functions (e.g., the misconnection detection), and that maintaining
multiple addressing schemes (with the necessary translations involved)
would be sub-optimal (to put it very mildly).
	 
	The only responses I've seen so far have been from Maarten (who
suggested to use the OSI addressing in network management for
compatibility with legacy equipment) and Stewart's responses to the
contrary.
	What I have NOT seen is clear perception of the need for an
addressing scheme for MPLS-TP at the conceptual/architectural level. I
see Eric's message as an indication that this is not just because I've
missed some fine text in the latest MPLS-TP drafts.
	 
	IMHO the big question is, how are we going to address the
MPLS-TP addressing scheme (or, actually, lack of an addressing scheme
for MPLS-TP)  problem.
	 
	Regards,
	     Sasha

	From: [email-masked] [[email-masked]] On
Behalf Of Eric Gray [[email-masked]]
	Sent: Tuesday, January 27, 2009 9:55 PM
	To: [email-masked]
	Subject: [mpls-tp] Addressing (my personal favorite topic)

	On several occasions, the issue of required and default
addressing has been raised.
	 
	In the latest round of design team meetings, several people
pointed out that a management
	channel (as a practical consideration, at least) require
addresses.
	 
	One thing I anticipate as a comment is what addressing scheme is
the default.  I expect
	that we all know that the answer to that question is IP
addressing, but I do not feel that 
	the NM requirements draft is the appropriate place to make such
a statement - except as
	a potential qualification of multiple choices offered in some
other document.
	 
	The question is: what document is the natural home for a
statement on addressing, both
	required and default?
	 
	I looked in the MPLS-TP requirements draft, and did not find it
there.  Where else might it
	be found?  Given the number of times this issue has been raised,
I am sure it should be
	somewhere.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Jan 2009 15:36:28 +0200

Debora (and all),
I've read the Addressing and Forwarding sections in the Framework draft, and I would like to ask several questions:

 1.  The text (and the diagram) seem to suggest that node addressing for network management and for control/signaling may be different.
    *   Is this understanding correct?
    *   I so, what is the justification for having two distinct addressing schemes?
 2.  The forwarding plane of MPLS-TP seems to be the same as that of (regular) MPLS. Does this mean that the data plane destination address of an MPLS-TP packet (including OAM packets) is its label stack?
 3.  The text states that OAM packets must carry identifier of the source. At the same time it states that addressing of OAM packets must be that of the forwarding (data) plane.
    *   Source address of which entity should be carried in the  OAM packets? That of the source node or that of the source LSP end-point?
    *   With distinct addressing schemes for the data, management and control/signaling planes of MPLS-TP, which source address must be included in the OAM packets?
    *   Is there a requirement for the source address in the OAM packet to be understandable by all nodes in the MPLS-TP domain?
    *   Is it required for any MPLS-TP node that terminates an OAM packet (e.g., due to TTL expiration or because the last label  in the label stack has been popped) to be able to send a "response" to its source based on the source address contained in this packet? Note that this question is different from the previous one: e.g., if the source address used in the OAM packets is IP address of the source node in the management plane, it would be globally understandable, but the terminating node may not be able to send a response back to the source node because ability to map management pane IP addresses to data plane addresses is not required.
 4.  RFC 4379 defines the traceroute mode for MPLS, thus providing the operators with the ability to trace actual paths traversed by the labeled packets in an IP/MPLS network. The Framework draft explicitly states that the mechanisms defined for that purpose in 4379 are not applicable to MPLS-TP. But it does not state whether the traceroute functionality itself is required for MPLS-TP, and a scan for the word "trace" on the MPLS-TP OAM requirements draft did not find any hits. Does this imply that traceroute functionality is not required for (and hence will not be supported with) MPLS-TP?

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, January 27, 2009 10:26 PM
To: Eric Gray; [email-masked]
Subject: Re: [mpls-tp] Addressing (my personal favorite topic)

Hi Eric,

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Tuesday, January 27, 2009 2:56 PM
To: [email-masked]
Subject: [mpls-tp] Addressing (my personal favorite topic)

---

From: <[email-masked]>
Date: Wed, 28 Jan 2009 14:48:35 -0000

Sasha,  I have some observations here:

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Alexander Vainshtein
	Sent: 28 January 2009 13:36
	To: BRUNGARD, DEBORAH A, ATTLABS
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Addressing (my personal favorite topic)

	Debora (and all),
	I've read the Addressing and Forwarding sections in the
Framework draft, and I would like to ask several questions:

	1.	The text (and the diagram) seem to suggest that node
addressing for network management and for control/signaling may be
different. 

		*	Is this understanding correct? 
		*	I so, what is the justification for having two
distinct addressing schemes?

	2.	The forwarding plane of MPLS-TP seems to be the same as
that of (regular) MPLS. Does this mean that the data plane destination
address of an MPLS-TP packet (including OAM packets) is its label stack?

		NH=> A DP label is not an address...it is a proxy for a
real address. A label only has to be unique on a single link-connection
(==hop), and its size is determined by how many client instances one
wants to distinguish on a link. In most co-ps mode networks the only
label that is used is a forwarding label that is proxy for the
connection DA access point. Since a connection *must* only have a single
source one does not need to provide a SA in normal co-ps mode traffic
units ....which in any case are only forwarded on the DA proxy
label..... as the connection itself carries the SA semantic. This works
fine until there is misconnectivity....which is why one has to run a SA
in a CV OAM flow on *all* connections in a label-swapping co-ps
technology. If the traffic units already carry a SA (like PBB-TE does
say, and obviously all cl-ps mode network do too) then one does not have
to run an adjunct CV OAM flow to detect/protect-against
misconnectivity...this now comes 'for free'  with no OAM running .

		The label in a PW is *not* a DA fowarding proxy but a SA
proxy....this is necessary to recover  the SA information lost from
merging that LDP/PHP create. And this is why when PWs go multi-hop  (ie
become another co-ps mode network) there is problem here because the
label now need to become a DA proxy for forwarding .   Aside=>This is
not a problem when only carrying IP, since IP is cl-ps and always
carries a SA....so this can resolve any lower layer LDP/PHP merging that
causes a loss of SA information 

	3.	The text states that OAM packets must carry identifier
of the source. At the same time it states that addressing of OAM packets
must be that of the forwarding (data) plane. 

		*	Source address of which entity should be carried
in the  OAM packets? That of the source node or that of the source LSP
end-point?  
			NH=> CV OAM pkts should carry the SA of the
connection, ie the trail/access point address
			  
		*	With distinct addressing schemes for the data,
management and control/signaling planes of MPLS-TP, which source address
must be included in the OAM packets? 
			NH=> The DP OAM CV SA has nothing to do with the
logically OOB CP/MP network...that must run its own OAM in the 1-hop
server links it uses between logically adjacent CP/MP nodes.
			  
		*	Is there a requirement for the source address in
the OAM packet to be understandable by all nodes in the MPLS-TP domain?

			NH=> No...not by the nodes.  But the addresses
must be unique in the network (and a real access point address not some
locally generated string) so that if there is misconnectivity the SA
gives immediate identification (to operations folks) of the offending
connection.
			   
		*	Is it required for any MPLS-TP node that
terminates an OAM packet (e.g., due to TTL expiration or because the
last label  in the label stack has been popped) 
			NH=>I have to say I find the notion of TTL in
what is supposed to be a co-ps *transport* network rather bizarre.
			
			  to be able to send a "response" to its source
based on the source address contained in this packet? 
			NH=> If the DP detects a problem from the CV
flow it should flag this to the NMS MP at the node where the problem is
detected.  So there will be a *different* communications in the OOB MP
network in this respect....not directly in the traffic DP.  The only DP
OAM traffic that should result under such defects is a BDI OAM flow back
towards the sink (and then only in the case of p2p connections....BDI
makes no sense for p2mp connections in the direction leaf->root....which
is also why piggybacking BDI in CV OAM pkts that one sees in Y.1731 is
not a good idea for p2mp connections)   Note that this question is
different from the previous one: e.g., if the source address used in the
OAM packets is IP address of the source node in the management plane, it
would be globally understandable, but the terminating node may not be
able to send a response back to the source node because ability to map
management pane IP addresses to data plane addresses is not required.

	4.	RFC 4379 defines the traceroute mode for MPLS, thus
providing the operators with the ability to trace actual paths traversed
by the labeled packets in an IP/MPLS network. The Framework draft
explicitly states that the mechanisms defined for that purpose in 4379
are not applicable to MPLS-TP. But it does not state whether the
traceroute functionality itself is required for MPLS-TP, and a scan for
the word "trace" on the MPLS-TP OAM requirements draft did not find any
hits. Does this imply that traceroute functionality is not required for
(and hence will not be supported with) MPLS-TP? 
		NH=> This is a very important point Sasha as co networks
are *not* the same as cl networks wrt tracing function OAM.  Let me
explain.  When we create a connection in a co mode network it is a
"constraining construct"...in the sense that traffic/OAM sent from the
source of such a connection is never supposed to leave that connection.
However, if we have a defect which results in traffic leaking from one
connection to another one (eg unintentend replication where the
connection the traffic is leaking from may see no impact) then this is
almost certainly going to be a unidirectional fault.  What this means is
that any OAM pkts that are of a request/response nature will for sure
leave the connection at the point of leaking but they will never come
back.  This is why I have always insisted that there should some
warining in the OAM for co mode networks that makes it clear that
request/response OAM cannot be trusted under misconnectivity defects.
This is not the same a cl-ps mode network, where request/response OAM
pkts are fine for a tracing pupose.
		
		regards, Neil

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A,
ATTLABS
		Sent: Tuesday, January 27, 2009 10:26 PM
		To: Eric Gray; [email-masked]
		Subject: Re: [mpls-tp] Addressing (my personal favorite
topic)

		Hi Eric,

		Deborah

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Eric Gray
		Sent: Tuesday, January 27, 2009 2:56 PM
		To: [email-masked]
		Subject: [mpls-tp] Addressing (my personal favorite
topic)

		In the latest round of design team meetings, several
people pointed out that a management

		One thing I anticipate as a comment is what addressing
scheme is the default.  I expect

		the NM requirements draft is the appropriate place to
make such a statement - except as

		a potential qualification of multiple choices offered in
some other document.

		required and default?

		I looked in the MPLS-TP requirements draft, and did not
find it there.  Where else might it

		be found?  Given the number of times this issue has been
raised, I am sure it should be

		somewhere.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Jan 2009 21:43:52 +0200

Neil,
Lots of thanks for sharing your observations with me (and the list).

I would like to clarify two points related to these observations:

 1.
You say that you "find the notion of TTL in what is supposed to be a co-ps *transport* network rather bizarre. " My problem with this statement is that TTL is an integral part of the MPLS DP and, as such, is inherited by MPLS-TP DP. The framework draft states this in the most unambiguous way. So IMHO there are two internally consistent approaches to it:
    *
Redesign MPLS-TP DP in a way that does not provide for TTL. This would probably require using different protocol numbers for MPLS and MPLS-TP etc.
    *
Explicitly define handling of MPLS-TP packets with expired TTL (including OAM packets). There are two ways to do this IMHO:
       *
Silently discard these packets without any consequent action. At the very least this helps to break network loops
       *
Pass these packets for additional examination (beyond the data plane).
    *
IMHO and FWIW Ethernet experience shows that:
       *
Lack of TTL-based mechanisms requires special and dedicated effort for loop prevention
       *
TTL-based troubleshooting (e.g., see 802.1ag linktrace method) is extremely useful for the network troubleshooting.
 2.
I must admit that I have failed to understand why troubleshooting of unidirectional failures resulting in leakage from the configured connection would not benefit from the tracing functionality, especially if it is based on TTL expiration. E.g., in your example the operator suspecting a leakage could run a trace on the path traversed by the connection packets and easily find the point where the responses (provided that any node can send them back to the originating node) leave the configured path. In the case of unintended replication you would see "extra responses" in addition to the expected ones - and this seems to be equally useful for troubleshooting of p2p and p2mp connections. This is exactly the behavior provided by LSP-ping in the traceroute mode. The fact that such functionality does not exist in co-cs networks does not mean that it is not required IMHO.

My 2c,

     Sasha

________________________________
From: [email-masked] [[email-masked]]
Sent: Wednesday, January 28, 2009 4:48 PM
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Addressing (my personal favorite topic)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein

Debora (and all),

NH=> A DP label is not an address...it is a proxy for a real address. A label only has to be unique on a single link-connection (==hop), and its size is determined by how many client instances one wants to distinguish on a link. In most co-ps mode networks the only label that is used is a forwarding label that is proxy for the connection DA access point. Since a connection *must* only have a single source one does not need to provide a SA in normal co-ps mode traffic units ....which in any case are only forwarded on the DA proxy label..... as the connection itself carries the SA semantic. This works fine until there is misconnectivity....which is why one has to run a SA in a CV OAM flow on *all* connections in a label-swapping co-ps technology. If the traffic units already carry a SA (like PBB-TE does say, and obviously all cl-ps mode network do too) then one does not have to run an adjunct CV OAM flow to detect/protect-against misconnectivity...this now comes 'for free'  with no OAM running .

The label in a PW is *not* a DA fowarding proxy but a SA proxy....this is necessary to recover  the SA information lost from merging that LDP/PHP create. And this is why when PWs go multi-hop  (ie become another co-ps mode network) there is problem here because the label now need to become a DA proxy for forwarding .   Aside=>This is not a problem when only carrying IP, since IP is cl-ps and always carries a SA....so this can resolve any lower layer LDP/PHP merging that causes a loss of SA information

 3.  The text states that OAM packets must carry identifier of the source. At the same time it states that addressing of OAM packets must be that of the forwarding (data) plane.
    *   Source address of which entity should be carried in the  OAM packets? That of the source node or that of the source LSP end-point?
NH=> CV OAM pkts should carry the SA of the connection, ie the trail/access point address

    *   With distinct addressing schemes for the data, management and control/signaling planes of MPLS-TP, which source address must be included in the OAM packets?
NH=> The DP OAM CV SA has nothing to do with the logically OOB CP/MP network...that must run its own OAM in the 1-hop server links it uses between logically adjacent CP/MP nodes.

    *   Is there a requirement for the source address in the OAM packet to be understandable by all nodes in the MPLS-TP domain?
NH=> No...not by the nodes.  But the addresses must be unique in the network (and a real access point address not some locally generated string) so that if there is misconnectivity the SA gives immediate identification (to operations folks) of the offending connection.

    *   Is it required for any MPLS-TP node that terminates an OAM packet (e.g., due to TTL expiration or because the last label  in the label stack has been popped)
NH=>I have to say I find the notion of TTL in what is supposed to be a co-ps *transport* network rather bizarre.

  to be able to send a "response" to its source based on the source address contained in this packet?
NH=> If the DP detects a problem from the CV flow it should flag this to the NMS MP at the node where the problem is detected.  So there will be a *different* communications in the OOB MP network in this respect....not directly in the traffic DP.  The only DP OAM traffic that should result under such defects is a BDI OAM flow back towards the sink (and then only in the case of p2p connections....BDI makes no sense for p2mp connections in the direction leaf->root....which is also why piggybacking BDI in CV OAM pkts that one sees in Y.1731 is not a good idea for p2mp connections)   Note that this question is different from the previous one: e.g., if the source address used in the OAM packets is IP address of the source node in the management plane, it would be globally understandable, but the terminating node may not be able to send a response back to the source node because ability to map management pane IP addresses to data plane addresses is not required.
 4.  RFC 4379 defines the traceroute mode for MPLS, thus providing the operators with the ability to trace actual paths traversed by the labeled packets in an IP/MPLS network. The Framework draft explicitly states that the mechanisms defined for that purpose in 4379 are not applicable to MPLS-TP. But it does not state whether the traceroute functionality itself is required for MPLS-TP, and a scan for the word "trace" on the MPLS-TP OAM requirements draft did not find any hits. Does this imply that traceroute functionality is not required for (and hence will not be supported with) MPLS-TP?
NH=> This is a very important point Sasha as co networks are *not* the same as cl networks wrt tracing function OAM.  Let me explain.  When we create a connection in a co mode network it is a "constraining construct"...in the sense that traffic/OAM sent from the source of such a connection is never supposed to leave that connection.  However, if we have a defect which results in traffic leaking from one connection to another one (eg unintentend replication where the connection the traffic is leaking from may see no impact) then this is almost certainly going to be a unidirectional fault.  What this means is that any OAM pkts that are of a request/response nature will for sure leave the connection at the point of leaking but they will never come back.  This is why I have always insisted that there should some warining in the OAM for co mode networks that makes it clear that request/response OAM cannot be trusted under misconnectivity defects.  This is not the same a cl-ps mode network, where request/response OAM pkts are fine for a tracing pupose.

regards, Neil

Hi Eric,

It’s captured in the framework document.
Deborah

---

From: <[email-masked]>
Date: Wed, 28 Jan 2009 21:00:52 -0000

Thanks Sasha....have tried to answer:

	From: Alexander Vainshtein
[mailto:[email-masked]] 
	Sent: 28 January 2009 19:44
	To: Harrison,N,Neil,CXM R
	Cc: [email-masked]; [email-masked]
	Subject: RE: [mpls-tp] Addressing (my personal favorite topic)

	Neil,
	Lots of thanks for sharing your observations with me (and the
list).
	 
	I would like to clarify two points related to these
observations: 
	 
	You say that you "find the notion of TTL in what is supposed to
be a co-ps *transport* network rather bizarre. " My problem with this
statement is that TTL is an integral part of the MPLS DP and, as such,
is inherited by MPLS-TP DP.   The framework draft states this in the
most unambiguous way. 
	   
	NH=> To be perfectly blunt it does not matter what the framework
draft or any other document says, this is a technical point that exists
on its own merit....and that technical point is that a co-cs/co-ps layer
network does not require a TTL field for loop mitigation..show me an
existing one that does?  So if it is retained it is for other
reasons...like impact on existing silicon/boxes.  I can accept that
argument.....but then we should be more honest and say this and not
pretend/assume it is for loop mitigation here.....it can't be if MPLS-TP
is designed properly as a transport technology.  If MPLS-TP really needs
a TTL for loop mitigation then we must not call it a *transport
network*, because it won't be one.

  So IMHO there are two internally consistent approaches to it:

*	
	Redesign MPLS-TP DP in a way that does not provide for TTL.  
	NH=> How can one 'redesign' something that has not even yet been
specified and odes not exist?....or at least it shouldn't ;-)
	This would probably require using different protocol numbers for
MPLS and MPLS-TP etc. 
	NH=> Well, interesting you brought this up, because they will
for sure will be different layer networks....but MPLS was never singular
anyway, ie you cannot tell from the MPLS DP traffic unit header what the
signalling protocol is that one has to interwork with for this header.  

*	
	Explicitly define handling of MPLS-TP packets with expired TTL
(including OAM packets). There are two ways to do this IMHO:

	*	
		Silently discard these packets without any consequent
action. At the very least this helps to break network loops 
		NH=> Network loops?  The CP/MP can check if there are
any loops before establishing a connection.......how does GMPLS cope
with SDH, OTN in this respect?....No TTL there.
	*	
		Pass these packets for additional examination (beyond
the data plane). 

	*	IMHO and FWIW Ethernet experience shows that: 
		NH=> Ethernet is not a co technology....it is cl, and it
deals rather brutally with loop mitgation by topology pruning (STP) to
degree 1.
		  
	*	
		Lack of TTL-based mechanisms requires special and
dedicated effort for loop prevention
	*	
		TTL-based troubleshooting (e.g., see 802.1ag linktrace
method) is extremely useful for the network troubleshooting. 
		NH=> We are talking about a *co* mode network
here...these factors are not relevent. 

	I must admit that I have failed to understand why
troubleshooting of unidirectional failures resulting in leakage from the
configured connection would not benefit from the tracing functionality,
especially if it is based on TTL expiration. E.g., in your example the
operator suspecting a leakage could run a trace on the path traversed by
the connection packets and easily find the point where the responses
(provided that any node can send them back to the originating node)
leave the configured path. In the case of unintended replication you
would see "extra responses" in addition to the expected ones - and this
seems to be equally useful for troubleshooting of p2p and p2mp
connections. This is exactly the behavior provided by LSP-ping in the
traceroute mode. The fact that such functionality does not exist in
co-cs networks does not mean that it is not required IMHO. 
	NH=> Please re-read what I stated and have a think about it.
And remember we are not dealing with a cl-ps mode network
here....traffic/OAM leakage from a connection is NOT supposed to happen,
so you cannot assume that any such fault will be bidirectionally
symmetric in that one is going to get a *DP* response from any
downstream node where the traffic/OAM might leak to.
	 
	regards, neil

	My 2c,

	     Sasha

[mailto:[email-masked]] On Behalf Of Alexander Vainshtein

		Debora (and all),

		1.	The text (and the diagram) seem to suggest that
node addressing for network management and for control/signaling may be
different. 

			*	Is this understanding correct? 
			*	I so, what is the justification for
having two distinct addressing schemes?

		2.	The forwarding plane of MPLS-TP seems to be the
same as that of (regular) MPLS. Does this mean that the data plane
destination address of an MPLS-TP packet (including OAM packets) is its
label stack?  

			NH=> A DP label is not an address...it is a
proxy for a real address. A label only has to be unique on a single
link-connection (==hop), and its size is determined by how many client
instances one wants to distinguish on a link. In most co-ps mode
networks the only label that is used is a forwarding label that is proxy
for the connection DA access point. Since a connection *must* only have
a single source one does not need to provide a SA in normal co-ps mode
traffic units ....which in any case are only forwarded on the DA proxy
label..... as the connection itself carries the SA semantic. This works
fine until there is misconnectivity....which is why one has to run a SA
in a CV OAM flow on *all* connections in a label-swapping co-ps
technology. If the traffic units already carry a SA (like PBB-TE does
say, and obviously all cl-ps mode network do too) then one does not have
to run an adjunct CV OAM flow to detect/protect-against
misconnectivity...this now comes 'for free'  with no OAM running .

			The label in a PW is *not* a DA fowarding proxy
but a SA proxy....this is necessary to recover  the SA information lost
from merging that LDP/PHP create. And this is why when PWs go multi-hop
(ie become another co-ps mode network) there is problem here because the
label now need to become a DA proxy for forwarding .   Aside=>This is
not a problem when only carrying IP, since IP is cl-ps and always
carries a SA....so this can resolve any lower layer LDP/PHP merging that
causes a loss of SA information 

		3.	The text states that OAM packets must carry
identifier of the source. At the same time it states that addressing of
OAM packets must be that of the forwarding (data) plane. 

			*	Source address of which entity should be
carried in the  OAM packets? That of the source node or that of the
source LSP end-point?  
				NH=> CV OAM pkts should carry the SA of
the connection, ie the trail/access point address
				  
			*	With distinct addressing schemes for the
data, management and control/signaling planes of MPLS-TP, which source
address must be included in the OAM packets? 
				NH=> The DP OAM CV SA has nothing to do
with the logically OOB CP/MP network...that must run its own OAM in the
1-hop server links it uses between logically adjacent CP/MP nodes.
				  
			*	Is there a requirement for the source
address in the OAM packet to be understandable by all nodes in the
MPLS-TP domain?  
				NH=> No...not by the nodes.  But the
addresses must be unique in the network (and a real access point address
not some locally generated string) so that if there is misconnectivity
the SA gives immediate identification (to operations folks) of the
offending connection.
				   
			*	Is it required for any MPLS-TP node that
terminates an OAM packet (e.g., due to TTL expiration or because the
last label  in the label stack has been popped) 
				NH=>I have to say I find the notion of
TTL in what is supposed to be a co-ps *transport* network rather
bizarre.
				
				  to be able to send a "response" to its
source based on the source address contained in this packet? 
				NH=> If the DP detects a problem from
the CV flow it should flag this to the NMS MP at the node where the
problem is detected.  So there will be a *different* communications in
the OOB MP network in this respect....not directly in the traffic DP.
The only DP OAM traffic that should result under such defects is a BDI
OAM flow back towards the sink (and then only in the case of p2p
connections....BDI makes no sense for p2mp connections in the direction
leaf->root....which is also why piggybacking BDI in CV OAM pkts that one
sees in Y.1731 is not a good idea for p2mp connections)   Note that this
question is different from the previous one: e.g., if the source address
used in the OAM packets is IP address of the source node in the
management plane, it would be globally understandable, but the
terminating node may not be able to send a response back to the source
node because ability to map management pane IP addresses to data plane
addresses is not required.

		4.	RFC 4379 defines the traceroute mode for MPLS,
thus providing the operators with the ability to trace actual paths
traversed by the labeled packets in an IP/MPLS network. The Framework
draft explicitly states that the mechanisms defined for that purpose in
4379 are not applicable to MPLS-TP. But it does not state whether the
traceroute functionality itself is required for MPLS-TP, and a scan for
the word "trace" on the MPLS-TP OAM requirements draft did not find any
hits. Does this imply that traceroute functionality is not required for
(and hence will not be supported with) MPLS-TP? 
			NH=> This is a very important point Sasha as co
networks are *not* the same as cl networks wrt tracing function OAM.
Let me explain.  When we create a connection in a co mode network it is
a "constraining construct"...in the sense that traffic/OAM sent from the
source of such a connection is never supposed to leave that connection.
However, if we have a defect which results in traffic leaking from one
connection to another one (eg unintentend replication where the
connection the traffic is leaking from may see no impact) then this is
almost certainly going to be a unidirectional fault.  What this means is
that any OAM pkts that are of a request/response nature will for sure
leave the connection at the point of leaking but they will never come
back.  This is why I have always insisted that there should some
warining in the OAM for co mode networks that makes it clear that
request/response OAM cannot be trusted under misconnectivity defects.
This is not the same a cl-ps mode network, where request/response OAM
pkts are fine for a tracing pupose.
			
			regards, Neil

			Subject: Re: [mpls-tp] Addressing (my personal
favorite topic)

			Hi Eric,

			Deborah

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Eric Gray
			Sent: Tuesday, January 27, 2009 2:56 PM
			To: [email-masked]
			Subject: [mpls-tp] Addressing (my personal
favorite topic)

			On several occasions, the issue of required and
default addressing has been raised.

			In the latest round of design team meetings,
several people pointed out that a management

			channel (as a practical consideration, at least)
require addresses.

			One thing I anticipate as a comment is what
addressing scheme is the default.  I expect

			that we all know that the answer to that
question is IP addressing, but I do not feel that 

			the NM requirements draft is the appropriate
place to make such a statement - except as

			a potential qualification of multiple choices
offered in some other document.

			The question is: what document is the natural
home for a statement on addressing, both

			required and default?

			I looked in the MPLS-TP requirements draft, and
did not find it there.  Where else might it

			be found?  Given the number of times this issue
has been raised, I am sure it should be

			somewhere.