Subject: [mpls-tp] MPLS-TP Addressing Scheme and Applicability of RFC 4447 to MPLS-TP

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 30 Jul 2008 12:16:20 +0300

Stewart, Matthew, Marc and all,
I have a question related to section 3.6.1 "PW Control Plane" of draft-blb-mpls-tp-framework-00.

The text of this section seems to suggest that the PW setup and maintenance mechanism based on Targeted LDP (as defined in RFC 4447) is applicable to and will be retained in MPLS-TP.

RFC 4447 implicitly defines two addressing schemes for PW endpoints:

 1.  With FEC 128, a PW address is represented by triple:
    *   An /32 IPv4 prefix used for setting up a Targeted LDP session (presumably this can be also an /128 IPv6  prefix).
    *   PW Type
    *   PW ID
 2.  With FEC 129, PW ID is replaced by the {AGI, AIII} pair.

These addressing schemes are used, among other things, in the PW connectivity verification mechanisms (e.g., LSP Ping in BFD).

On the other hand, MPLS-TP seemingly does not have any explicit addressing scheme at all.

I wonder if acceptance of targeted LDP for PW setup does not impose the PW addressing scheme on MPLS-TP.
This would not be an issue if it were done explicitly, and if it would be the only addressing scheme for MPLS-TP.
Otherwise we will have to deal with the address translation mechanisms...

Please note that IMHO a similar issue in fact exists in the  traditional transport networks, where the OSS identifies the transport nodes by their IP addresses, but some OAM mechanisms (e.g., Trail Identifiers in SONET/SDH) imply their own loosely defined addressing scheme...

Did I miss something here?

Regards,
    Sasha

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

---

From: "LASSERRE, Marc \(Marc\)" <[email-masked]>
Date: Wed, 30 Jul 2008 11:48:40 +0200

Sasha,

This is a good point.

If T-LDP is enabled, IP addressing is implied.

For static PW, IP addressing is not needed.

As discussed during today's mpls-tp IETF session, node addressing is
still being discussed. As noted before, IP addressing is the only IETF
addressing scheme supported so far.

Thanks,

Marc

________________________________

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: mercredi 30 juillet 2008 11:16
To: [email-masked]; Bocci, Matthew (Matthew); LASSERRE, Marc (Marc)
Cc: [email-masked]
Subject: MPLS-TP Addressing Scheme and Applicability of RFC 4447 to
MPLS-TP

I have a question related to section 3.6.1 "PW Control Plane" of
draft-blb-mpls-tp-framework-00.

The text of this section seems to suggest that the PW setup and
maintenance mechanism based on Targeted LDP (as defined in RFC 4447) is
applicable to and will be retained in MPLS-TP.

	*	An /32 IPv4 prefix used for setting up a Targeted LDP
session (presumably this can be also an /128 IPv6  prefix).
	*	PW Type
	*	PW ID

These addressing schemes are used, among other things, in the PW
connectivity verification mechanisms (e.g., LSP Ping in BFD).

On the other hand, MPLS-TP seemingly does not have any explicit
addressing scheme at all.

I wonder if acceptance of targeted LDP for PW setup does not impose the
PW addressing scheme on MPLS-TP.

This would not be an issue if it were done explicitly, and if it would
be the only addressing scheme for MPLS-TP.

Otherwise we will have to deal with the address translation
mechanisms...

Please note that IMHO a similar issue in fact exists in the  traditional
transport networks, where the OSS identifies the transport nodes by
their IP addresses, but some OAM mechanisms (e.g., Trail Identifiers in
SONET/SDH) imply their own loosely defined addressing scheme...

Regards,

    Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 30 Jul 2008 13:02:15 +0300

Marc,
Lots of thanks for a prompt response.

IMHO (and FWIW) the MPLS-TP addressing scheme is a mandatory building block, with many of the other blocks depending on it. One example is CV which essentially checks the actual DA vs. the intended one...

If we agree that MPLS-TP uses an IP addressing scheme (be it IPv4 or IPv6), we could easily eliminate the need for a separate ACH type for network management since this would presumably run over IP...  On the other hand, if we accept IP addressing scheme and allow IS-IS as the routing protocol for management traffic, we would need an ACH type of OSI etc.

Do you see any way in which the MPLS-TP addressing scheme (preferably based on IP) can be expedited?

Regards,
    Sasha

________________________________
From: LASSERRE, Marc (Marc) [mailto:[email-masked]]
Sent: Wednesday, July 30, 2008 12:49 PM
To: Alexander Vainshtein; [email-masked]; Bocci, Matthew (Matthew)
Cc: [email-masked]
Subject: RE: MPLS-TP Addressing Scheme and Applicability of RFC 4447 to MPLS-TP

Sasha,

This is a good point.

As discussed during today's mpls-tp IETF session, node addressing is still being discussed. As noted before, IP addressing is the only IETF addressing scheme supported so far.

Thanks,
Marc

Subject: MPLS-TP Addressing Scheme and Applicability of RFC 4447 to MPLS-TP

Regards,
    Sasha

---

From: "LASSERRE, Marc \(Marc\)" <[email-masked]>
Date: Wed, 30 Jul 2008 12:09:16 +0200

Sasha,

I concur that MPLS-TP addressing is a fundamental building block.

However, IP addressing is orthogonal to IP forwarding. Hence, even if IP
addressing is used, it does not imply that IP forwarding be used.

Anyway, we plan to address (no punt intended) this issue very quickly.

Thanks,

Marc

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: mercredi 30 juillet 2008 12:02
To: LASSERRE, Marc (Marc)
Cc: [email-masked]; Bocci, Matthew (Matthew); [email-masked]
Subject: RE: MPLS-TP Addressing Scheme and Applicability of RFC 4447 to
MPLS-TP

Marc,

IMHO (and FWIW) the MPLS-TP addressing scheme is a mandatory building
block, with many of the other blocks depending on it. One example is CV
which essentially checks the actual DA vs. the intended one...

If we agree that MPLS-TP uses an IP addressing scheme (be it IPv4 or
IPv6), we could easily eliminate the need for a separate ACH type for
network management since this would presumably run over IP...  On the
other hand, if we accept IP addressing scheme and allow IS-IS as the
routing protocol for management traffic, we would need an ACH type of
OSI etc.

Do you see any way in which the MPLS-TP addressing scheme (preferably
based on IP) can be expedited?

Regards,

    Sasha

	From: LASSERRE, Marc (Marc)
[mailto:[email-masked]] 
	Sent: Wednesday, July 30, 2008 12:49 PM
	To: Alexander Vainshtein; [email-masked]; Bocci, Matthew
(Matthew)
	Cc: [email-masked]
	Subject: RE: MPLS-TP Addressing Scheme and Applicability of RFC
4447 to MPLS-TP

	Sasha,

	This is a good point.

	As discussed during today's mpls-tp IETF session, node
addressing is still being discussed. As noted before, IP addressing is
the only IETF addressing scheme supported so far.

	Thanks,

	Marc

	From: Alexander Vainshtein
[mailto:[email-masked]] 
	Sent: mercredi 30 juillet 2008 11:16
	To: [email-masked]; Bocci, Matthew (Matthew); LASSERRE, Marc
(Marc)
	Cc: [email-masked]
	Subject: MPLS-TP Addressing Scheme and Applicability of RFC 4447
to MPLS-TP

	RFC 4447 implicitly defines two addressing schemes for PW
endpoints:

		*	An /32 IPv4 prefix used for setting up a
Targeted LDP session (presumably this can be also an /128 IPv6  prefix).

		*	PW Type 
		*	PW ID 

	I wonder if acceptance of targeted LDP for PW setup does not
impose the PW addressing scheme on MPLS-TP.

	This would not be an issue if it were done explicitly, and if it
would be the only addressing scheme for MPLS-TP.

	Please note that IMHO a similar issue in fact exists in the
traditional transport networks, where the OSS identifies the transport
nodes by their IP addresses, but some OAM mechanisms (e.g., Trail
Identifiers in SONET/SDH) imply their own loosely defined addressing
scheme...

	Regards,

	    Sasha

---

From: "Howard Green" <[email-masked]>
Date: Wed, 30 Jul 2008 12:16:02 +0200

Just to clarify the point I was trying to make in the session. I have no
problem with the development of an IP-based control plane for MPLS-TP.
In fact I think that the extension of GMPLS to provide an out of band
IP-based control plane is one of the most important aspects of the
program. This clearly requires an addressing scheme. Without wishing to
rule out other possibilities, clearly IP-based node addressing will be
required. I was trying to make it clear that the use for transport
applications does not depend in any way on IP data plane forwarding (and
implicitly, that a fully out of band control plane solution is
absolutely required). Also as discussed in the session, clean
interworking with other uses of the MPLS suite is thoroughly desirable.
/Howard

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Alexander Vainshtein
	Sent: 30 July 2008 12:02
	To: LASSERRE, Marc (Marc)
	Cc: [email-masked]
	Subject: Re: [mpls-tp] MPLS-TP Addressing Scheme and
Applicability of RFC 4447 to MPLS-TP

	Marc,
	 
	IMHO (and FWIW) the MPLS-TP addressing scheme is a mandatory
building block, with many of the other blocks depending on it. One
example is CV which essentially checks the actual DA vs. the intended
one...
	 
	If we agree that MPLS-TP uses an IP addressing scheme (be it
IPv4 or IPv6), we could easily eliminate the need for a separate ACH
type for network management since this would presumably run over IP...
On the other hand, if we accept IP addressing scheme and allow IS-IS as
the routing protocol for management traffic, we would need an ACH type
of OSI etc.
	 
	Do you see any way in which the MPLS-TP addressing scheme
(preferably based on IP) can be expedited?
	 
	Regards,
	    Sasha

		From: LASSERRE, Marc (Marc)
[mailto:[email-masked]] 
		Sent: Wednesday, July 30, 2008 12:49 PM
		To: Alexander Vainshtein; [email-masked]; Bocci,
Matthew (Matthew)
		Cc: [email-masked]
		Subject: RE: MPLS-TP Addressing Scheme and Applicability
of RFC 4447 to MPLS-TP

		Sasha,

		This is a good point.

		Thanks,

		Marc

		From: Alexander Vainshtein
[mailto:[email-masked]] 
		Sent: mercredi 30 juillet 2008 11:16
		To: [email-masked]; Bocci, Matthew (Matthew);
LASSERRE, Marc (Marc)
		Cc: [email-masked]
		Subject: MPLS-TP Addressing Scheme and Applicability of
RFC 4447 to MPLS-TP

		I have a question related to section 3.6.1 "PW Control
Plane" of draft-blb-mpls-tp-framework-00.

		The text of this section seems to suggest that the PW
setup and maintenance mechanism based on Targeted LDP (as defined in RFC
4447) is applicable to and will be retained in MPLS-TP.

		RFC 4447 implicitly defines two addressing schemes for
PW endpoints:

		1.	With FEC 128, a PW address is represented by
triple: 

			*	PW Type 
			*	PW ID 

		2.	With FEC 129, PW ID is replaced by the {AGI,
AIII} pair. 

		These addressing schemes are used, among other things,
in the PW connectivity verification mechanisms (e.g., LSP Ping in BFD).

		On the other hand, MPLS-TP seemingly does not have any
explicit addressing scheme at all.

		I wonder if acceptance of targeted LDP for PW setup does
not impose the PW addressing scheme on MPLS-TP.

		This would not be an issue if it were done explicitly,
and if it would be the only addressing scheme for MPLS-TP.

		Otherwise we will have to deal with the address
translation mechanisms...

		Please note that IMHO a similar issue in fact exists in
the  traditional transport networks, where the OSS identifies the
transport nodes by their IP addresses, but some OAM mechanisms (e.g.,
Trail Identifiers in SONET/SDH) imply their own loosely defined
addressing scheme...

		Regards,

		    Sasha

---

From: "LASSERRE, Marc \(Marc\)" <[email-masked]>
Date: Wed, 30 Jul 2008 12:23:27 +0200

Thanks Howard. I think that this is in line with my replies to Sasha's
email.

Marc

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Howard Green
Sent: mercredi 30 juillet 2008 12:16
To: [email-masked]
Subject: Re: [mpls-tp] MPLS-TP Addressing Scheme and Applicability of
RFC4447 to MPLS-TP

/Howard

	Marc,

	Regards,

	    Sasha

		Sasha,

		This is a good point.

		Thanks,

		Marc

			*	PW Type 
			*	PW ID 

		Regards,

		    Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 30 Jul 2008 13:28:35 +0300

Marc,
Thanks again for a prompt response.

Just a minor comment: network management traffic IMHO needs both an addressing scheme AND a forwarding scheme.
The alternative would be a set of dedicated protected LSPs connecting the head-end node (to which the OSS is connected) to each and every node in the management domain - and these LSPs would have to be created without using the OSS...

Of course, IP forwarding of management traffic is orthogonal to forwarding of the user frames.

On the other hand, if it is in place for management traffic, it can be piggy-backed for forwarding some OAM (e.g., to report detected misconnection to the head-end node), thus eliminating the need of every transit node to be aware of pairing of the two directions of every bi-directional LSP.

My 2c.
    Sasha

Sent: Wednesday, July 30, 2008 1:09 PM
To: Alexander Vainshtein

Sasha,

However, IP addressing is orthogonal to IP forwarding. Hence, even if IP addressing is used, it does not imply that IP forwarding be used.

Thanks,
Marc

Marc,

Regards,
    Sasha

This is a good point.

Thanks,
Marc

 1.  With FEC 129, PW ID is replaced by the {AGI, AIII} pair.
These addressing schemes are used, among other things, in the PW connectivity verification mechanisms (e.g., LSP Ping in BFD).

Regards,
    Sasha

---

From: <[email-masked]>
Date: Wed, 30 Jul 2008 12:09:30 +0100

Hi Howard, a while since we spoke

	Howard Green  wrote 30 July 2008 11:16
	
	Just to clarify the point I was trying to make in the session. I
have no problem with the development of an IP-based control plane for
MPLS-TP. In fact I think that the extension of GMPLS to provide an out
of band IP-based control plane is one of the most important aspects of
the program. This clearly requires an addressing scheme. Without wishing
to rule out other possibilities, clearly IP-based node addressing will
be required. I was trying to make it clear that the use for transport
applications does not depend in any way on IP data plane forwarding (and
implicitly, that a fully out of band control plane solution is
absolutely required). Also as discussed in the session, clean
interworking with other uses of the MPLS suite is thoroughly desirable.
	/Howard 
	===
	Hi Howard....a pearl of wisdom in here wrt to the need for an
OOB CP in MPLS-TP.....but let me make you aware of one consequence here
you might not have factored in wrt the S bit.

	First, let me deal with a related PW issue. PWs are a
consequence of how MPLS was originally specified. MPLS treats its
clients differently , viz :

	- IP => null encaps (real client case) or peer PDU (MPLS CP
case).....this is completely bizarre from a perspective of modelling as
a layer network and it's this that leads to most subsequent problems,
inc hurting moving to a GMPLS OOB CP......however just park that
observation for now

	- MPLS => digital wrapper, ie 'just add a new header'....this
contains the illusion that we can create client LSP layer topology on
the fly just by adding a new MPLS header at will....this is the point I
want to ultimately come back on

	- all else => insert the CW adaptation and create a PW

	Now the main purpose of the PW adaptation is to mitigate a
problem caused by the 1st point above.....specifically the use of ECMP
snooping/load-spreading with LDP as this uses an in-band CP bootstrap.

	Aside => Stopping PWs at 1 hop would have left us with this
odd-ball adaptation function to mitgate the in-band CP/ECMP-snooping
layer violation....however, once PWs go multi-hop there is a big change
in behaviour and now the PWs themselves also become a full blown co-ps
layer network above the IP/MPLS server hybrid....which is sort-of what
kicked off this thread with Sasha's observations on PW addressing and
questioning what the addressing might be in MPLS-TP.

	Now, if we want resource determinism in MPLS-TP we must have
pukka connections, ie single source constructs only...so LDP (and PHP)
need to go as they create merging behaviours.....and we also don't need
ECMP. So now we have RSVP-TE LSPs in MPLS-TP. There is also a dead easy
step to get the required OOB MPLS CP (and MP), we just set- aside some
reserved labels for this....and we now satisfy a long-standing CCAMPs
charter item to boot wrt GMPLS/MPLS CP harmonisation.

	Having REMOVED the things that created the need for PWs in the
1st place we now don't actually need PWs any more. However, given all
the time/money invested in creating PWs I guess this observation is not
very welcome ;-)

	But let's park that and come back to the S bit. Some folks claim
stacked LSPs create hierarchy.....this is not strictly true (I'll avoid
a full blown explanation), and what they certainly do not do is create a
client/server relationship between stacked LSPs (which is one reason we
had to write
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-transport-02.tx
t
<http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-transport-02.t
xt>  in order to carry the LSPs of one party over the LSPs of another
party in a true transparent client/server manner). So if we really want
to sort this 'feature/bug' in MPLS-TP we are going to have to deprecate
the use of the S bit as used in MPLS today.   

	One could actually now re-spin this field as an OAM indicate
function....and of course in a proper co-ps mode layer network the TTL
would not be useful  either.    However, I guess this will have folks
squirming even more than they already probably are from what I've
written above.  

	But this was the point on the S bit and the real meaning of
client/server hierachy in stacked LSPs within a MPLS-TP network that I
wanted to raise Howard..... I think it should make sense to you .

	regards, neil 

	

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Alexander Vainshtein
		Sent: 30 July 2008 12:02
		To: LASSERRE, Marc (Marc)
		Cc: [email-masked]
		Subject: Re: [mpls-tp] MPLS-TP Addressing Scheme and
Applicability of RFC 4447 to MPLS-TP

		Marc,
		 
		IMHO (and FWIW) the MPLS-TP addressing scheme is a
mandatory building block, with many of the other blocks depending on it.
One example is CV which essentially checks the actual DA vs. the
intended one...
		 
		If we agree that MPLS-TP uses an IP addressing scheme
(be it IPv4 or IPv6), we could easily eliminate the need for a separate
ACH type for network management since this would presumably run over
IP...  On the other hand, if we accept IP addressing scheme and allow
IS-IS as the routing protocol for management traffic, we would need an
ACH type of OSI etc.
		 
		Do you see any way in which the MPLS-TP addressing
scheme (preferably based on IP) can be expedited?
		 
		Regards,
		    Sasha

			From: LASSERRE, Marc (Marc)
[mailto:[email-masked]] 
			Sent: Wednesday, July 30, 2008 12:49 PM
			To: Alexander Vainshtein; [email-masked];
Bocci, Matthew (Matthew)
			Cc: [email-masked]
			Subject: RE: MPLS-TP Addressing Scheme and
Applicability of RFC 4447 to MPLS-TP

			Sasha,

			This is a good point.

			As discussed during today's mpls-tp IETF
session, node addressing is still being discussed. As noted before, IP
addressing is the only IETF addressing scheme supported so far.

			Thanks,

			Marc

			From: Alexander Vainshtein
[mailto:[email-masked]] 
			Sent: mercredi 30 juillet 2008 11:16
			To: [email-masked]; Bocci, Matthew
(Matthew); LASSERRE, Marc (Marc)
			Cc: [email-masked]
			Subject: MPLS-TP Addressing Scheme and
Applicability of RFC 4447 to MPLS-TP

			I have a question related to section 3.6.1 "PW
Control Plane" of draft-blb-mpls-tp-framework-00.

			The text of this section seems to suggest that
the PW setup and maintenance mechanism based on Targeted LDP (as defined
in RFC 4447) is applicable to and will be retained in MPLS-TP.

			RFC 4447 implicitly defines two addressing
schemes for PW endpoints:

			1.	With FEC 128, a PW address is
represented by triple: 

				*	An /32 IPv4 prefix used for
setting up a Targeted LDP session (presumably this can be also an /128
IPv6  prefix). 
				*	PW Type 
				*	PW ID 

			2.	With FEC 129, PW ID is replaced by the
{AGI, AIII} pair. 

			These addressing schemes are used, among other
things, in the PW connectivity verification mechanisms (e.g., LSP Ping
in BFD).

			On the other hand, MPLS-TP seemingly does not
have any explicit addressing scheme at all.

			I wonder if acceptance of targeted LDP for PW
setup does not impose the PW addressing scheme on MPLS-TP.

			This would not be an issue if it were done
explicitly, and if it would be the only addressing scheme for MPLS-TP.

			Please note that IMHO a similar issue in fact
exists in the  traditional transport networks, where the OSS identifies
the transport nodes by their IP addresses, but some OAM mechanisms
(e.g., Trail Identifiers in SONET/SDH) imply their own loosely defined
addressing scheme...

			Regards,

			    Sasha

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 30 Jul 2008 14:25:48 +0300

Hi Neil,

Regarding your reasoning about the S bit.

You may remember that a long time ago Shahram and I proposed
allowing transport of one operator's MPLS over another's MPLS network.

This could easily be done by allowing an MPLS stack terminated by an S=1 label,
under which was another MPLS stack terminated by another S=1.

This was considered broken at the time, but we are apparently coming back to it.
However, this time the feeling is that we need to use PWs to separate the
stacks, so instead of ONLY using S=1, we use S=1 AND a CW.

This actually has the advantage of enabling use of OAM per MPLS stack
(not per layer), but actually changes the architecture in a subtle way.

In the standard MPLS architecture, MPLS has 3 types of clients,
which can be uniquely determined from the packet format:
1) MPLS (by label stacking, S=0)
2) IP (by S=1 and first nibble = 4 or 6)
3) PWs (by CW - first nibble = 0 or 1)
(I purposely ignore the possibility of CW-less PWs.)

In this new "transport-oriented" design, we use CWs and thus have IP and MPLS PWs.
So MPLS has a single client type - the PW.

There are, however, multiple PW client types that can not be determined from the packet
since PWs are not self-describing.

Y(J)S

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 30, 2008 2:10 PM
To: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MPLS-TP Addressing Scheme and Applicability of RFC4447 to MPLS-TP

Howard Green  wrote 30 July 2008 11:16
Just to clarify the point I was trying to make in the session. I have no problem with the development of an IP-based control plane for MPLS-TP. In fact I think that the extension of GMPLS to provide an out of band IP-based control plane is one of the most important aspects of the program. This clearly requires an addressing scheme. Without wishing to rule out other possibilities, clearly IP-based node addressing will be required. I was trying to make it clear that the use for transport applications does not depend in any way on IP data plane forwarding (and implicitly, that a fully out of band control plane solution is absolutely required). Also as discussed in the session, clean interworking with other uses of the MPLS suite is thoroughly desirable.
/Howard
===

Hi Howard....a pearl of wisdom in here wrt to the need for an OOB CP in MPLS-TP.....but let me make you aware of one consequence here you might not have factored in wrt the S bit.

First, let me deal with a related PW issue. PWs are a consequence of how MPLS was originally specified. MPLS treats its clients differently , viz :

- IP => null encaps (real client case) or peer PDU (MPLS CP case).....this is completely bizarre from a perspective of modelling as a layer network and it's this that leads to most subsequent problems, inc hurting moving to a GMPLS OOB CP......however just park that observation for now

- MPLS => digital wrapper, ie 'just add a new header'....this contains the illusion that we can create client LSP layer topology on the fly just by adding a new MPLS header at will....this is the point I want to ultimately come back on

Now the main purpose of the PW adaptation is to mitigate a problem caused by the 1st point above.....specifically the use of ECMP snooping/load-spreading with LDP as this uses an in-band CP bootstrap.

Aside => Stopping PWs at 1 hop would have left us with this odd-ball adaptation function to mitgate the in-band CP/ECMP-snooping layer violation....however, once PWs go multi-hop there is a big change in behaviour and now the PWs themselves also become a full blown co-ps layer network above the IP/MPLS server hybrid....which is sort-of what kicked off this thread with Sasha's observations on PW addressing and questioning what the addressing might be in MPLS-TP.

Now, if we want resource determinism in MPLS-TP we must have pukka connections, ie single source constructs only...so LDP (and PHP) need to go as they create merging behaviours.....and we also don't need ECMP. So now we have RSVP-TE LSPs in MPLS-TP. There is also a dead easy step to get the required OOB MPLS CP (and MP), we just set- aside some reserved labels for this....and we now satisfy a long-standing CCAMPs charter item to boot wrt GMPLS/MPLS CP harmonisation.

Having REMOVED the things that created the need for PWs in the 1st place we now don't actually need PWs any more. However, given all the time/money invested in creating PWs I guess this observation is not very welcome ;-)

But let's park that and come back to the S bit. Some folks claim stacked LSPs create hierarchy.....this is not strictly true (I'll avoid a full blown explanation), and what they certainly do not do is create a client/server relationship between stacked LSPs (which is one reason we had to write http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-transport-02.txt in order to carry the LSPs of one party over the LSPs of another party in a true transparent client/server manner). So if we really want to sort this 'feature/bug' in MPLS-TP we are going to have to deprecate the use of the S bit as used in MPLS today.

One could actually now re-spin this field as an OAM indicate function....and of course in a proper co-ps mode layer network the TTL would not be useful  either.    However, I guess this will have folks squirming even more than they already probably are from what I've written above.

But this was the point on the S bit and the real meaning of client/server hierachy in stacked LSPs within a MPLS-TP network that I wanted to raise Howard..... I think it should make sense to you .

regards, neil

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: 30 July 2008 12:02
To: LASSERRE, Marc (Marc)
Cc: [email-masked]
Subject: Re: [mpls-tp] MPLS-TP Addressing Scheme and Applicability of RFC 4447 to MPLS-TP

Marc,

Regards,
    Sasha

Sasha,

This is a good point.

Thanks,
Marc

Regards,
    Sasha

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 30 Jul 2008 13:53:39 +0200

Sasha,
 
SDH, OTN, Ethernet transport networks have a Data Communication Network
(DCN) to support network management (MCN) and the optional control plane
(SCN). Rec. G.7712 specifies the details of this DCN. 
 
MPLS-TP will be just another transport technology that will be connected to
this DCN. The design of this DCN and the technologisch deployed in a DCN
should be transport network technology independent.
 
Many MPLS-TP capable nodes will also support SDH, OTN and Ethernet
functions. Management plane traffic for all those technologies may be sent
to the same network management system, or to different ones; this is
operator specific.
 
The DCN is set up to interconnect network elements, network management
systems and optional control plane systems in the multi technology transport
network. The DCN is not designed to support the transport layer network OAM
functions. It is as such a bad idea to piggy-back the DCN for forwarding
some transport layer network OAM.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: 30 July 2008 12:29
To: LASSERRE, Marc (Marc)
Cc: [email-masked]
Subject: Re: [mpls-tp] MPLS-TP Addressing Scheme and Applicability of RFC
4447 to MPLS-TP

Marc,
 
Just a minor comment: network management traffic IMHO needs both an
addressing scheme AND a forwarding scheme. 
The alternative would be a set of dedicated protected LSPs connecting the
head-end node (to which the OSS is connected) to each and every node in the
management domain - and these LSPs would have to be created without using
the OSS...
 
Of course, IP forwarding of management traffic is orthogonal to forwarding
of the user frames.
 
On the other hand, if it is in place for management traffic, it can be
piggy-backed for forwarding some OAM (e.g., to report detected misconnection
to the head-end node), thus eliminating the need of every transit node to be
aware of pairing of the two directions of every bi-directional LSP.
 
My 2c.
    Sasha

  _____  

Sasha,

Thanks,

Marc

  _____  

Marc,

IMHO (and FWIW) the MPLS-TP addressing scheme is a mandatory building block,
with many of the other blocks depending on it. One example is CV which
essentially checks the actual DA vs. the intended one...

If we agree that MPLS-TP uses an IP addressing scheme (be it IPv4 or IPv6),
we could easily eliminate the need for a separate ACH type for network
management since this would presumably run over IP...  On the other hand, if
we accept IP addressing scheme and allow IS-IS as the routing protocol for
management traffic, we would need an ACH type of OSI etc.

Do you see any way in which the MPLS-TP addressing scheme (preferably based
on IP) can be expedited?

Regards,

    Sasha

  _____  

Sasha,

This is a good point.

As discussed during today's mpls-tp IETF session, node addressing is still
being discussed. As noted before, IP addressing is the only IETF addressing
scheme supported so far.

Thanks,

Marc

  _____  

The text of this section seems to suggest that the PW setup and maintenance
mechanism based on Targeted LDP (as defined in RFC 4447) is applicable to
and will be retained in MPLS-TP.

*	An /32 IPv4 prefix used for setting up a Targeted LDP session
(presumably this can be also an /128 IPv6  prefix). 

*	PW Type 

*	PW ID 

On the other hand, MPLS-TP seemingly does not have any explicit addressing
scheme at all.

I wonder if acceptance of targeted LDP for PW setup does not impose the PW
addressing scheme on MPLS-TP.

This would not be an issue if it were done explicitly, and if it would be
the only addressing scheme for MPLS-TP.

Please note that IMHO a similar issue in fact exists in the  traditional
transport networks, where the OSS identifies the transport nodes by their IP
addresses, but some OAM mechanisms (e.g., Trail Identifiers in SONET/SDH)
imply their own loosely defined addressing scheme...

Regards,

    Sasha

---

From: <[email-masked]>
Date: Wed, 30 Jul 2008 12:58:40 +0100

Thanks Yaakov...good points...some further observations in-line:

	From: Yaakov Stein [mailto:[email-masked]] 
	Sent: 30 July 2008 12:26
	To: Harrison,N,Neil,CXM R; [email-masked];
[email-masked]
	Subject: RE: [mpls-tp] MPLS-TP Addressing Scheme and
Applicability ofRFC4447 to MPLS-TP

	Hi Neil, 
	 
	Regarding your reasoning about the S bit. 
	NH=> Just remember the key point here: if one REALLY wants
proper client/server behaviour (and IMO this is a MUST for any
technology setting itself up as 'transport') one cannot stack
connections unless they are functionally decoupled, ie each resides in a
layer network in its own right.  When I was watching the ITU
deliberations of T-MPLS unfold I was a little amazed to note that no one
seemed to have picked-up on this carry-over problem from MPLS,
especially given some of those involved have a long history of deep
immersion in functional arch concepts.
	 
	You may remember that a long time ago Shahram and I proposed
	allowing transport of one operator's MPLS over another's MPLS
network. 
	NH=> Yes, I have also considered this when we were 1st creating
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-transport-02.tx
t
<http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-transport-02.t
xt>  , and the most elegant/efficient solution I could see was using a
reserved label for this purpose. 
	 
	This could easily be done by allowing an MPLS stack terminated
by an S=1 label,
	under which was another MPLS stack terminated by another S=1. 
	NH=> If you use a reserved label here this solves the problem
better IMO, ie it has the well-known semantic 'this is a functional
breakwater between 2 MPLS stacks'....now the S bit can be set
independently in each stack. 
	 
	This was considered broken at the time, but we are apparently
coming back to it. 
	NH=> The issue is slightly different IMO.  What I discuss above
wrt to using a reserved label maintains MPLS as-is with the notion that
LSPs can be stacked at will in the same layer network.  However, what I
was discussing wrt MPLS-TP is to say 'if we really want proper
client/server we CANNOT carry over the original idea of the S bit in
MPLS as-is'.  Folks might not like this, but it is something that is
required if you want a proper transport solution IMO.
	 
	However, this time the feeling is that we need to use PWs to
separate the
	stacks, so instead of ONLY using S=1, we use S=1 AND a CW.
	 
	This actually has the advantage of enabling use of OAM per MPLS
stack
	(not per layer), but actually changes the architecture in a
subtle way.
	 
	In the standard MPLS architecture, MPLS has 3 types of clients,
	which can be uniquely determined from the packet format:
	1) MPLS (by label stacking, S=0)
	2) IP (by S=1 and first nibble = 4 or 6)
	3) PWs (by CW - first nibble = 0 or 1)
	(I purposely ignore the possibility of CW-less PWs.) 
	NH=> Understood.....this 'distributed PID' is all you really
need....don't need (in principle) label 13, but guess its helps in
implementation. 
	 
	In this new "transport-oriented" design, we use CWs and thus
have IP and MPLS PWs.
	So MPLS has a single client type - the PW. 
	NH=> Indeed, I also considered this a long time ago wrt getting
consistent OAM on LSPs, ie force all LSPs (irrespective of client when
S=1) to have the CW/AC.  So even though labels have (increasingly)
inconsistent semantics, if the OAM is least consistent then one can
always consistently detect misconnectivity defects.  Not possible to
achieve with LDP of course.
	 
	But don't you find it perversely ironic that in creating MPLS-TP
we have to get rid of the very things that created PWs in the 1st place,
but then we try and standardise the features of MPLS-TP on those that
were created for PWs!  Quite amazing if you think about it.  Ho hum.....
	 
	regards, Neil
	 
	There are, however, multiple PW client types that can not be
determined from the packet
	since PWs are not self-describing.
	 
	Y(J)S

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
	Sent: Wednesday, July 30, 2008 2:10 PM
	To: [email-masked]; [email-masked]
	Subject: Re: [mpls-tp] MPLS-TP Addressing Scheme and
Applicability of RFC4447 to MPLS-TP

		
		Just to clarify the point I was trying to make in the
session. I have no problem with the development of an IP-based control
plane for MPLS-TP. In fact I think that the extension of GMPLS to
provide an out of band IP-based control plane is one of the most
important aspects of the program. This clearly requires an addressing
scheme. Without wishing to rule out other possibilities, clearly
IP-based node addressing will be required. I was trying to make it clear
that the use for transport applications does not depend in any way on IP
data plane forwarding (and implicitly, that a fully out of band control
plane solution is absolutely required). Also as discussed in the
session, clean interworking with other uses of the MPLS suite is
thoroughly desirable.
		/Howard 
		===
		Hi Howard....a pearl of wisdom in here wrt to the need
for an OOB CP in MPLS-TP.....but let me make you aware of one
consequence here you might not have factored in wrt the S bit.

		- IP => null encaps (real client case) or peer PDU (MPLS
CP case).....this is completely bizarre from a perspective of modelling
as a layer network and it's this that leads to most subsequent problems,
inc hurting moving to a GMPLS OOB CP......however just park that
observation for now

		- MPLS => digital wrapper, ie 'just add a new
header'....this contains the illusion that we can create client LSP
layer topology on the fly just by adding a new MPLS header at
will....this is the point I want to ultimately come back on

		Now the main purpose of the PW adaptation is to mitigate
a problem caused by the 1st point above.....specifically the use of ECMP
snooping/load-spreading with LDP as this uses an in-band CP bootstrap.

		Aside => Stopping PWs at 1 hop would have left us with
this odd-ball adaptation function to mitgate the in-band
CP/ECMP-snooping layer violation....however, once PWs go multi-hop there
is a big change in behaviour and now the PWs themselves also become a
full blown co-ps layer network above the IP/MPLS server hybrid....which
is sort-of what kicked off this thread with Sasha's observations on PW
addressing and questioning what the addressing might be in MPLS-TP.

		Now, if we want resource determinism in MPLS-TP we must
have pukka connections, ie single source constructs only...so LDP (and
PHP) need to go as they create merging behaviours.....and we also don't
need ECMP. So now we have RSVP-TE LSPs in MPLS-TP. There is also a dead
easy step to get the required OOB MPLS CP (and MP), we just set- aside
some reserved labels for this....and we now satisfy a long-standing
CCAMPs charter item to boot wrt GMPLS/MPLS CP harmonisation.

		Having REMOVED the things that created the need for PWs
in the 1st place we now don't actually need PWs any more. However, given
all the time/money invested in creating PWs I guess this observation is
not very welcome ;-)

		But let's park that and come back to the S bit. Some
folks claim stacked LSPs create hierarchy.....this is not strictly true
(I'll avoid a full blown explanation), and what they certainly do not do
is create a client/server relationship between stacked LSPs (which is
one reason we had to write
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-transport-02.tx
t
<http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-transport-02.t
xt>  in order to carry the LSPs of one party over the LSPs of another
party in a true transparent client/server manner). So if we really want
to sort this 'feature/bug' in MPLS-TP we are going to have to deprecate
the use of the S bit as used in MPLS today.   

		One could actually now re-spin this field as an OAM
indicate function....and of course in a proper co-ps mode layer network
the TTL would not be useful  either.    However, I guess this will have
folks squirming even more than they already probably are from what I've
written above.  

		But this was the point on the S bit and the real meaning
of client/server hierachy in stacked LSPs within a MPLS-TP network that
I wanted to raise Howard..... I think it should make sense to you .

		regards, neil 

		

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Alexander Vainshtein
			Sent: 30 July 2008 12:02
			To: LASSERRE, Marc (Marc)
			Cc: [email-masked]
			Subject: Re: [mpls-tp] MPLS-TP Addressing Scheme
and Applicability of RFC 4447 to MPLS-TP

			Marc,
			 
			IMHO (and FWIW) the MPLS-TP addressing scheme is
a mandatory building block, with many of the other blocks depending on
it. One example is CV which essentially checks the actual DA vs. the
intended one...
			 
			If we agree that MPLS-TP uses an IP addressing
scheme (be it IPv4 or IPv6), we could easily eliminate the need for a
separate ACH type for network management since this would presumably run
over IP...  On the other hand, if we accept IP addressing scheme and
allow IS-IS as the routing protocol for management traffic, we would
need an ACH type of OSI etc.
			 
			Do you see any way in which the MPLS-TP
addressing scheme (preferably based on IP) can be expedited?
			 
			Regards,
			    Sasha

				From: LASSERRE, Marc (Marc)
[mailto:[email-masked]] 
				Sent: Wednesday, July 30, 2008 12:49 PM
				To: Alexander Vainshtein;
[email-masked]; Bocci, Matthew (Matthew)
				Cc: [email-masked]
				Subject: RE: MPLS-TP Addressing Scheme
and Applicability of RFC 4447 to MPLS-TP

				Sasha,

				This is a good point.

				If T-LDP is enabled, IP addressing is
implied.

				For static PW, IP addressing is not
needed.

				Thanks,

				Marc

				I have a question related to section
3.6.1 "PW Control Plane" of draft-blb-mpls-tp-framework-00.

				The text of this section seems to
suggest that the PW setup and maintenance mechanism based on Targeted
LDP (as defined in RFC 4447) is applicable to and will be retained in
MPLS-TP.

				RFC 4447 implicitly defines two
addressing schemes for PW endpoints:

				2.	With FEC 129, PW ID is replaced
by the {AGI, AIII} pair. 

				These addressing schemes are used, among
other things, in the PW connectivity verification mechanisms (e.g., LSP
Ping in BFD).

				On the other hand, MPLS-TP seemingly
does not have any explicit addressing scheme at all.

				I wonder if acceptance of targeted LDP
for PW setup does not impose the PW addressing scheme on MPLS-TP.

				This would not be an issue if it were
done explicitly, and if it would be the only addressing scheme for
MPLS-TP.

				Otherwise we will have to deal with the
address translation mechanisms...

				Please note that IMHO a similar issue in
fact exists in the  traditional transport networks, where the OSS
identifies the transport nodes by their IP addresses, but some OAM
mechanisms (e.g., Trail Identifiers in SONET/SDH) imply their own
loosely defined addressing scheme...

				Regards,

				    Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 30 Jul 2008 20:00:07 +0300

Maarten,

Regarding your statement "The DCN is not designed to support the transport layer network OAM functions":

 *   This was definitely true with SONET/SDH and OTN
 *   MHO this MUST be reconsidered when we move to packet-based transport.

The reasons for that:

 1.  This approach has proved its validity:
    *   In the currently deployed IP/MPLS networks that successfully perform transport functions TODAY
    *   In the GMPLS-based scenarios where the DCN is not congruent to the transport network (note that, with GMPLS, nodes effectively "talk" to each other, not just to the OSS)
 2.  The alternative approach you promote:
    *   Places additional heavy burden on equipment (like maintaining the pairing state of the two directions of a bi-directional P2P LSP in each transit node)
    *   Cannot be extended to uni-directional P2P LSPs (something that the old transport technologies either did not support or did not cope well with - what happens to RDI when one of the receiving end points of a uni-directional P2MP SDH trail enters a defect state?)

My 2c,
    Sasha

________________________________
From: Maarten Vissers [mailto:[email-masked]]
Sent: Wednesday, July 30, 2008 2:54 PM
To: Alexander Vainshtein; 'LASSERRE, Marc (Marc)'
Cc: [email-masked]
Subject: RE: [mpls-tp] MPLS-TP Addressing Scheme and Applicability of RFC 4447 to MPLS-TP

Sasha,

SDH, OTN, Ethernet transport networks have a Data Communication Network (DCN) to support network management (MCN) and the optional control plane (SCN). Rec. G.7712 specifies the details of this DCN.

MPLS-TP will be just another transport technology that will be connected to this DCN. The design of this DCN and the technologisch deployed in a DCN should be transport network technology independent.

Many MPLS-TP capable nodes will also support SDH, OTN and Ethernet functions. Management plane traffic for all those technologies may be sent to the same network management system, or to different ones; this is operator specific.

The DCN is set up to interconnect network elements, network management systems and optional control plane systems in the multi technology transport network. The DCN is not designed to support the transport layer network OAM functions. It is as such a bad idea to piggy-back the DCN for forwarding some transport layer network OAM.

Regards,
Maarten

Marc,

My 2c.
    Sasha

Sasha,

Thanks,
Marc

Marc,

Regards,
    Sasha

This is a good point.

Thanks,
Marc

Regards,
    Sasha

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 31 Jul 2008 13:30:59 +0200

Sasha,
 
As soon as you start to combine support for different functions with
different performance requirements and/or different mandatory requirements
into a single solution, you will either get performance problems for one
function (e.g. millisecond error and defect detection), or have a too
powerfull (thus complex/costly) design for the other function (e.g. 1 Gbit/s
DCN), or require the presence of the optional function (e.g. control plane).
That's why transport OAM must be separated from the DCN.
 
The DCN connects network elements with each other and with management
systems. That's why it could support GMPLS.
 
RDI and REI signals have micro or millisecond exchange requirements. Just
not possible to support this via a DCN.
RDI application is for remote maintenance and more important for
bidirectional performance monitoring. A unidirectional p2p or p2mp LSP will
never have the need for bidirectional performance monitoring, so there is no
RDI/REI requirement.
 
Regards,
Maarten

  _____  

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: 30 July 2008 19:00
To: Maarten Vissers; 'LASSERRE, Marc (Marc)'
Cc: [email-masked]
Subject: RE: [mpls-tp] MPLS-TP Addressing Scheme and Applicability of RFC
4447 to MPLS-TP

Maarten,
 
Regarding your statement "The DCN is not designed to support the transport
layer network OAM functions": 

*	MHO this MUST be reconsidered when we move to packet-based
transport. 

The reasons for that:

*	In the currently deployed IP/MPLS networks that successfully perform
transport functions TODAY 

*	In the GMPLS-based scenarios where the DCN is not congruent to the
transport network (note that, with GMPLS, nodes effectively "talk" to each
other, not just to the OSS)

*	Places additional heavy burden on equipment (like maintaining the
pairing state of the two directions of a bi-directional P2P LSP in each
transit node) 

*	Cannot be extended to uni-directional P2P LSPs (something that the
old transport technologies either did not support or did not cope well with
- what happens to RDI when one of the receiving end points of a
uni-directional P2MP SDH trail enters a defect state?)

My 2c,
    Sasha

  _____  

From: Maarten Vissers [mailto:[email-masked]] 
Sent: Wednesday, July 30, 2008 2:54 PM
To: Alexander Vainshtein; 'LASSERRE, Marc (Marc)'
Cc: [email-masked]
Subject: RE: [mpls-tp] MPLS-TP Addressing Scheme and Applicability of RFC
4447 to MPLS-TP

Sasha,

 

Regards,
Maarten

  _____  

Marc,

 
 
My 2c.
    Sasha

  _____  

Sasha,

Thanks,

Marc

  _____  

Marc,

Regards,

    Sasha

  _____  

Sasha,

This is a good point.

Thanks,

Marc

  _____  

*	PW Type 

*	PW ID 

Regards,

    Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 31 Jul 2008 15:03:41 +0300

Maarten,
I CC Italo because I've discussed some of these points with him in a face-to-face meeting this morning.

You say that
<quote>
A unidirectional p2p or p2mp LSP will never have the need for bidirectional performance monitoring
<end quote>
An interesting point. But please note that:

 *   As long as the two endpoints of a connection are in the same management domain, there is no need in collecting the so-called "Far End" PM as you can retrieve the PM results directly from the source over the DCN
 *   If the two endpoints of a connection are in different management domains, Far End PM (i.e., how well my peer receives what I am sending) is relevant regardless whether the connection is bi- or uni-directional. Actually, based on this information transmitter could take some protection actions in 1:1 architectures, right?

Please note also that the Far-End PM parameter which requires RDI is actually the Far-End UAS (Unavailable Seconds) counter. Which IMHO means that delivery of indications within, say 100 ms would suffice for all practical reasons.

Regarding the DCN throughput: The limitations imposed by the SONET/SDH design on the DCN links (192, or, at best, 576 Kbit/s) look somewhat ridiculous today when it is pretty difficult to find a computer that does not support at least a 100 Mbit/s Ethernet port, and when my home Internet connection is 5 Mbit/s (upgraded by my provider from 2.5 Mbit/s at no additional cost...). I do not think that we should consider these restrictions as defining our designs for MPLS-TP. And while 1G may be a bit exotic today, 100Mbit/s does not look like an exaggeration for managing a modern network with 10GbE (or OC-192) links.

Last but not least, I'm very glad to see that you are not opposed to the idea of management and control plane sharing the same DCN.

Regards,
    Sasha

Sent: Thursday, July 31, 2008 2:31 PM

Sasha,

As soon as you start to combine support for different functions with different performance requirements and/or different mandatory requirements  into a single solution, you will either get performance problems for one function (e.g. millisecond error and defect detection), or have a too powerfull (thus complex/costly) design for the other function (e.g. 1 Gbit/s DCN), or require the presence of the optional function (e.g. control plane). That's why transport OAM must be separated from the DCN.

The DCN connects network elements with each other and with management systems. That's why it could support GMPLS.

RDI and REI signals have micro or millisecond exchange requirements. Just not possible to support this via a DCN.
RDI application is for remote maintenance and more important for bidirectional performance monitoring. A unidirectional p2p or p2mp LSP will never have the need for bidirectional performance monitoring, so there is no RDI/REI requirement.

Regards,
Maarten

Maarten,

The reasons for that:

My 2c,
    Sasha

Sasha,

Regards,
Maarten

Marc,

My 2c.
    Sasha

Sasha,

Thanks,
Marc

Marc,

Regards,
    Sasha

This is a good point.

Thanks,
Marc

Regards,
    Sasha

---

From: "Italo Busi" <[email-masked]>
Date: Thu, 31 Jul 2008 14:42:51 +0100

I agree with Maarten. These are the design principle of all transport
technologies (SONET/SDH and OTH) proven by many years of deployment experience
that we wish to retain in MPLS-TP.
 
Italo

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Maarten Vissers
Sent: Thursday, July 31, 2008 12:31 PM
To: 'Alexander Vainshtein'; 'LASSERRE, Marc (Marc)'
Cc: [email-masked]
Subject: Re: [mpls-tp] MPLS-TP Addressing Scheme and Applicability of RFC 4447
to MPLS-TP

Sasha,
 
As soon as you start to combine support for different functions with different
performance requirements and/or different mandatory requirements  into a single
solution, you will either get performance problems for one function (e.g.
millisecond error and defect detection), or have a too powerfull (thus
complex/costly) design for the other function (e.g. 1 Gbit/s DCN), or require
the presence of the optional function (e.g. control plane). That's why transport
OAM must be separated from the DCN.
 
The DCN connects network elements with each other and with management systems.
That's why it could support GMPLS.
 
RDI and REI signals have micro or millisecond exchange requirements. Just not
possible to support this via a DCN.
RDI application is for remote maintenance and more important for bidirectional
performance monitoring. A unidirectional p2p or p2mp LSP will never have the
need for bidirectional performance monitoring, so there is no RDI/REI
requirement.
 
Regards,
Maarten

  _____  

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: 30 July 2008 19:00
To: Maarten Vissers; 'LASSERRE, Marc (Marc)'
Cc: [email-masked]
Subject: RE: [mpls-tp] MPLS-TP Addressing Scheme and Applicability of RFC 4447
to MPLS-TP

Maarten,
 
Regarding your statement "The DCN is not designed to support the transport layer
network OAM functions": 

The reasons for that:

*	Places additional heavy burden on equipment (like maintaining the
pairing state of the two directions of a bi-directional P2P LSP in each transit
node) 

*	Cannot be extended to uni-directional P2P LSPs (something that the old
transport technologies either did not support or did not cope well with - what
happens to RDI when one of the receiving end points of a uni-directional P2MP
SDH trail enters a defect state?)

My 2c,
    Sasha

  _____  

From: Maarten Vissers [mailto:[email-masked]] 
Sent: Wednesday, July 30, 2008 2:54 PM
To: Alexander Vainshtein; 'LASSERRE, Marc (Marc)'
Cc: [email-masked]
Subject: RE: [mpls-tp] MPLS-TP Addressing Scheme and Applicability of RFC 4447
to MPLS-TP

Sasha,
 
SDH, OTN, Ethernet transport networks have a Data Communication Network (DCN) to
support network management (MCN) and the optional control plane (SCN). Rec.
G.7712 specifies the details of this DCN. 
 
MPLS-TP will be just another transport technology that will be connected to this
DCN. The design of this DCN and the technologisch deployed in a DCN should be
transport network technology independent.
 
Many MPLS-TP capable nodes will also support SDH, OTN and Ethernet functions.
Management plane traffic for all those technologies may be sent to the same
network management system, or to different ones; this is operator specific.
 
The DCN is set up to interconnect network elements, network management systems
and optional control plane systems in the multi technology transport network.
The DCN is not designed to support the transport layer network OAM functions. It
is as such a bad idea to piggy-back the DCN for forwarding some transport layer
network OAM.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexander Vainshtein
Sent: 30 July 2008 12:29
To: LASSERRE, Marc (Marc)
Cc: [email-masked]
Subject: Re: [mpls-tp] MPLS-TP Addressing Scheme and Applicability of RFC 4447
to MPLS-TP

Marc,
 
Just a minor comment: network management traffic IMHO needs both an addressing
scheme AND a forwarding scheme. 
The alternative would be a set of dedicated protected LSPs connecting the
head-end node (to which the OSS is connected) to each and every node in the
management domain - and these LSPs would have to be created without using the
OSS...
 
Of course, IP forwarding of management traffic is orthogonal to forwarding of
the user frames.
 
On the other hand, if it is in place for management traffic, it can be
piggy-backed for forwarding some OAM (e.g., to report detected misconnection to
the head-end node), thus eliminating the need of every transit node to be aware
of pairing of the two directions of every bi-directional LSP.
 
My 2c.
    Sasha

  _____  

Sasha,

Thanks,

Marc

  _____  

Marc,

If we agree that MPLS-TP uses an IP addressing scheme (be it IPv4 or IPv6), we
could easily eliminate the need for a separate ACH type for network management
since this would presumably run over IP...  On the other hand, if we accept IP
addressing scheme and allow IS-IS as the routing protocol for management
traffic, we would need an ACH type of OSI etc.

Do you see any way in which the MPLS-TP addressing scheme (preferably based on
IP) can be expedited?

Regards,

    Sasha

  _____  

Sasha,

This is a good point.

As discussed during today's mpls-tp IETF session, node addressing is still being
discussed. As noted before, IP addressing is the only IETF addressing scheme
supported so far.

Thanks,

Marc

  _____  

The text of this section seems to suggest that the PW setup and maintenance
mechanism based on Targeted LDP (as defined in RFC 4447) is applicable to and
will be retained in MPLS-TP.

*	PW Type 

*	PW ID 

These addressing schemes are used, among other things, in the PW connectivity
verification mechanisms (e.g., LSP Ping in BFD).

This would not be an issue if it were done explicitly, and if it would be the
only addressing scheme for MPLS-TP.

Please note that IMHO a similar issue in fact exists in the  traditional
transport networks, where the OSS identifies the transport nodes by their IP
addresses, but some OAM mechanisms (e.g., Trail Identifiers in SONET/SDH) imply
their own loosely defined addressing scheme...

Regards,

    Sasha

---

From: "Italo Busi" <[email-masked]>
Date: Thu, 31 Jul 2008 14:54:08 +0100

Sasha,
 
there is still some discussion about the RDI within the context of the OAM
requirement draft.
 
I agree that RDI is not needed for fault management when the two endpoint of a
connection are in the same management domain. The NMS can access the node where
the failure is detected and diagnose it.
 
The question is whether we need RDI for fault management when the two endpoints
are in different management domains. In this case I agree that this will be
required for both unidir and bidir connections.
 
But in this case, carrying RDI over the DCN does not help.
 
I think that RDI is required for performance monitoring of a bidirectional
connection. With bidirectional PM, the RDI contributes to the unavailability
time of the bidirectional connection and this is an important parameter to be
monitored (the unavailability time is an important parameter in transport's
SLA).
 
This is required in both caases where the two endpoints of a connection are in
the same management domain or are in different management domain but only for
bidirectional connections.
 
Italo

  _____  

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Thursday, July 31, 2008 1:04 PM
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; Italo Busi
Subject: RE: [mpls-tp] MPLS-TP Addressing Scheme and Applicability of RFC 4447
to MPLS-TP

Maarten,
I CC Italo because I've discussed some of these points with him in a
face-to-face meeting this morning.
 
You say that 
<quote>

A unidirectional p2p or p2mp LSP will never have the need for bidirectional
performance monitoring

<end quote>

*	As long as the two endpoints of a connection are in the same management
domain, there is no need in collecting the so-called "Far End" PM as you can
retrieve the PM results directly from the source over the DCN 

*	If the two endpoints of a connection are in different management
domains, Far End PM (i.e., how well my peer receives what I am sending) is
relevant regardless whether the connection is bi- or uni-directional. Actually,
based on this information transmitter could take some protection actions in 1:1
architectures, right?

Please note also that the Far-End PM parameter which requires RDI is actually
the Far-End UAS (Unavailable Seconds) counter. Which IMHO means that delivery of
indications within, say 100 ms would suffice for all practical reasons.
 
Regarding the DCN throughput: The limitations imposed by the SONET/SDH design on
the DCN links (192, or, at best, 576 Kbit/s) look somewhat ridiculous today when
it is pretty difficult to find a computer that does not support at least a 100
Mbit/s Ethernet port, and when my home Internet connection is 5 Mbit/s (upgraded
by my provider from 2.5 Mbit/s at no additional cost...). I do not think that we
should consider these restrictions as defining our designs for MPLS-TP. And
while 1G may be a bit exotic today, 100Mbit/s does not look like an exaggeration
for managing a modern network with 10GbE (or OC-192) links.   
 
Last but not least, I'm very glad to see that you are not opposed to the idea of
management and control plane sharing the same DCN.
 
Regards,
    Sasha

  _____  

Sasha,

 
 
Regards,
Maarten

  _____  

Maarten,

The reasons for that:

My 2c,
    Sasha

  _____  

Sasha,

 

Regards,
Maarten

  _____  

Marc,

 
 
My 2c.
    Sasha

  _____  

Sasha,

Thanks,

Marc

  _____  

Marc,

Regards,

    Sasha

  _____  

Sasha,

This is a good point.

Thanks,

Marc

  _____  

*	PW Type 

*	PW ID 

Regards,

    Sasha