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

From: Maarten Vissers <[email-masked]>
Date: Tue, 05 Aug 2008 09:52:24 +0200

Italo, Sasha,
 
  _____  

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

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. 
 
[mv] Correct. That is why reporting a RDI failure is by default disabled. 
 
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. 
 
[mv] RDI in fault management is used for 'single ended maintenance'. In this
case one of the two endpoints is in a system that is not
directly/continuously connected to the DCN. Receiving RDI at the endpoint
connected to the DCN can trigger network management to have a look at the
remote node. E.g. by dialing up the node. To do this, you need a
bidirectional connection to this node,
 
[mv] So far I have only seen unidirectional connections for broadcast TV
distribution; endpoints are typically connected to the DCN and thus
accessible by NMS. All other connections are bidirectional.
 
But in this case, carrying RDI over the DCN does not help. 
 
[mv] Correct; the remote node is not (permanently) connected to the DCN. 
 
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). 
 
[mv] This is indeed the main application for RDI. There is unidirectional PM
for maintenance applications and bidirectional PM for service verification.
Clause 10/G.7710 describes the mechanisms for both types of PM.
 
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. 
 
[mv] Agree.
 
Regards,
Maarten 
 
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>
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

  _____  

From: Maarten Vissers [mailto:[email-masked]] 
Sent: Thursday, July 31, 2008 2: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": 

*	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

  _____  

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

  _____  

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

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,

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.

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

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