Subject: Re: [mpls-tp] MPLS over OTN

From: "Howard Green" <[email-masked]>
Date: Mon, 4 Aug 2008 10:23:54 +0200

Adrian
Thanks (for the homily as well!)
My apologies for some lack of clarity.
As you say, GMPLS control of OTN is what it is. The use of a G-PID
describing an MPLS payload does, presumably, allow an OTN path to be
advertised (with suitable policy constraints) as an MPLS forwarding
adjacency. In the MPLS layer above this OTN, it is not so obvious how to
carry IP "in band", and therefore the GMPLS mechanics seem to be
required. As you say, the control plane could be "OOB but in fiber" (or
here, in OTN path) or out of fibre. Thus there would seem to be utility
in an optional associated channel mechanism for the control plane. I
wonder whether there may be a requirement of the reverse kind (maximum
diversity between data plane and control plane) in some circumstances.
/Howard

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: 01 August 2008 10:53
> To: Howard Green; [email-masked]
> Cc: [email-masked]
> Subject: Re: MPLS over OTN
> 
> Hi Howard,
> 
> [adding MPLS-TP mailing list]
> 
> Accurate representation of our conversation.
> That is, in GMPLS we have label type, switching type, 
> encoding type, and G-PID.
> G-PID identifies the payload and re-uses the Ethertype 
> codepoints. Thus we can carry MPLS.
> If GFP is used for framing, it must also identify the payload 
> and, as you point out, GFP has an MPLS codepoint.
> 
> That the GFP codepoint for MPLS is the same as that for 
> "T-MPLS" is good for Option 1 (which is where we are) since 
> there is no practical difference between MPLS and MPLS-TP.
> 
> Now, the operation of MPLS over OTN that you describe is 
> actually the operation of an OTN. So the issues of control 
> channels in OTN are exactly as you describe, but have nothing 
> to do with the payload protocol. This is simply GMPLS control 
> of OTN. Period.
> 
> GMPLS control of MPLS-TP is a different kettle of ball games. 
> Here the switching type is PSC: the same switching type as 
> for MPLS. A feature of GMPLS is that there is *logical* 
> separation of control plane and data plane. 
> This means that the control plane can be in-band (MPLS-TE), 
> out-of-band but in-fibre (SONET/SDH or OSC), or out-of-fibre.
> 
> MPLS-TP requirements say that it must be possible to operate 
> the network "in the absence of IP." I have taken this to mean 
> "in the absence of IP routing and forwarding" (but this is my 
> opinion and there is no explicit evidence in the requirements 
> I-D). With this view...
> - We can use IP identifiers (addresses) in the data plane and 
> the control plane
> - We can use IP-based control protocols (GMPLS)
> - We can use an IP-based control network if available, but we cannot
>    mandate it
> - Control entities that need to communicate must be allowed to be
>    IP-adjacent so that there is no requirement for 
> IP-forwarding in the
>    network
> 
> I believe we can do all of the above, and often do in GMPLS networks.
> The crunch questions are:
> 1. What is the physical technology for the data links in the 
> control plane?
> 2. How do we identify control plane traffic when it arrives at a node?
> 3. How do we exchange control plane messages between nodes that
>    do not have a common data link in the control plane?
> 
> Answers are:
> 1. We don't care :-)
>     But a possible answer in MPLS-TP is an LSP (e.g. a 
> reserved label) 2. From the data link (since there is no need 
> to disambiguate the control
>    plane traffic from any other traffic on the data link) 3. 
> This is a more tricky question. However nearly all of the messages
>    are exchanged only between data-plane-adjacent nodes. This can be
>    the case in the IGP-TE protocols, and is true for all messages in
>    RSVP-TE with a couple of exceptions (below). It is also 
> the case for
>    LMP. So IP forwarding is not required in the control plane.
>    The tricky cases are:
>    - echo response in LSP Ping (we are rebuilding the OAM)
>    - Notify message in RSVP-TE (we are considering OAM approaches
>      for the uses of Notify where IP forwarding is not available)
>    - "Targeted Path messages" used in hierarchical LSPs (and LSP
>       stitching). In these cases we are effectively building a virtual
>       data plane adjacency and should build a parallel virtual control
>       plane link between the end points (e.g. an LSP).
> 
> We should note that the output of the JWT *appears* to be 
> that "GMPLS meets the requirements of a control plane for MPLS-TP."
> 
> We should also note that management plane operation of 
> MPLS-TP is a requirement, and we must assume that management 
> plane messages may need to be exchanged between management 
> stations and network nodes using some protocol and connectivity.
> 
> </homily>
> 
> Adrian
> ----- Original Message -----
> From: "Howard Green" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, July 31, 2008 5:55 PM
> Subject: MPLS over OTN
> 
> 
> Just to record for the list a chat with Adrian and Lou Berger. I
> discover from reading G.7041 Amendment 2 that there is a codepoint
> defined to allow unicast MPLS frames to be carried over OTN (ODUx)
> channels by way of GFP encoding. Reading RFC 4328, there is 
> an encoding
> type for ODUx, and the switching type is TDM. There is no 
> specific G-PID
> value defined for the MPLS codepoint (which was probably defined
> concurrently with the writing of RFC 4328). Adrian and Lou 
> took the view
> that in this situation, the use of the unicast MPLS ethertype (#8847)
> would define for signalling this bearer type (as described in 
> RFC 3471).
> 
> This is relevant partly because G.7041 amendment 2 defines 
> the codepoint
> to be for "MPLS or T-MPLS". I assume that this usage carries over to
> MPLS-TP. In this situation,interestingly, there is no 
> prospect of inband
> IP control, and so GMPLS is the only control plane option.
> Is this correct?
> Regards Howard
> 
> 
> 
> 
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 4 Aug 2008 09:42:53 +0100

Hi again Howard,

So, to pick apart the control plane in an MPLS network ( I think I am 
agreeing with you fully)...

In band
This could only happen using the sort of mechanisms being proposed for ACH.
That is, each control plane message is packaged as an MPLS packet and 
labelled as for the LSP that it is controlling. The TTL is set to one (or 
more to allow non-adjacent signalling). A secondary label on the stack might 
be used to identify the control plane when the top-level label expires. We 
already have the Router Alert label defined.
However, such a mechanism would only work for existing LSPs meaning that we 
could never set up new ones!

Out of band in fibre
(Bear in mind that the nature of MPLS means that this is very similar to in 
band except within the switching fabric)
To make this work we simply need a reserved label to identify control plane 
traffic. The Router Alert label already provides this.
However, we lack a mechanism for non-adjacent signalling. There are two use 
cases in GMPLS...
1. Hierarchical and stitched LSPs
  In this case, we can use the hierarchical or stitched LSP to carry
  the control traffic. For hierarchical, it is simple since we can put the
  Router Alert label second on the stack where it will be discovered
  when the top label is popped. For stitching, we must also set the
  TTL to expire at the end of the stitching segment.
2. Notify messages
  These messages may be exchanged between non-adjacent nodes.
  Normally they rely on IP routing, but there is an option to get them
  forwarded hop-by-hop by the control planes of the nodes along the
  LSP - this is NOT IP-based forwarding, but relies on each node on
  the path of an LSP knowing the next control plane node in each
  direction (something that is required by RSVP-TE anyway).
  An alternative is to use the LSP that is being notified, and to set the
  TTL as necessary also using a Router Alert label just as for stitching.
A further alternative (sufficient but not necessary) approach would be to 
set up a mesh of LSPs to support the control plane.

Out of band out of fibre
I am inclined to agree that there may often be good reasons to operate this 
way.
Using an IP network as a DCN makes a lot of sense and it should be noted 
that this does not require that the NEs have IP forwarding capabilities.

Cheers,
Adrian

----- Original Message ----- 
From: "Howard Green" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 04, 2008 9:23 AM
Subject: RE: MPLS over OTN

Adrian

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 04 Aug 2008 14:50:06 +0200

Adrian, Howard,

In the (multi-technology) transport network you will find a Data
Communication Network (DCN) as per G.7712 (generic aspects), G.784 (SDH
specific aspects), G.874 (OTN specific aspects), G.8051 (ETH specific
aspects) and G.8151 (T-MPLS (in future MPLS-TP) specific aspects). This DCN
connects Network Elements with Network Management Systems, Network Elements
with Network Elements and Network Management Systems with Network Management
Systems. 

The DCN supports a Management Communication Network (MCN) and a Signalling
Communication Network (SCN). The MCN carries the network management related
messages, the SCN carries the control plane related messages. 

Many transport network elements support these days more than one technology;
e.g. SDH, OTN and Ethernet and in future also SDH, OTN, Ethernet and
MPLS-TP. The DCN carries messages for the superset of transport
technologies.

The transport network does not have an IP transport (i.e. data) plane in
which IP services are supported.

The transport network has a DCN, and this DCN inlcudes today a mix of OSI
and IP technologies.

A transport network element is connected to the DCN via two or more
interfaces. This may be Q-interfaces and/or Embedded Communication Channels
(ECC) in SDH, OTN, Ethernet, MPLS-TP NNIs. E.g. a SDH/Eth/MPLS-TP network
element may be connected to its NMS via a SDH ECC (e.g. MS-DCC) on two of
its STM-N interfaces. Management messages for the SDH, Ethernet and MPLS-TP
parts of this network element will be carried over such MS-DCC. Control
plane messages (if control plane is present for one or more of the
technologies) can also be carried over those MS-DCCs.

Similarly, MPLS-TP NNIs using 802.3 interface technology may carry
Management messages for SDH, OTN, Ethernet and MPLS-TP functions in the
network element via direct carriage over Ethernet with EtherType encoding
(e.g. EtherType = IPv4 when management messages are IPv4 encapsulated on
this interface). And when a MPLS-TP or Ethernet NNI uses G.707/G.7041
(SDH/GFP) interface technology, the management messages for
SDH/OTN/Eth/MPLS_TP can be carried over GFP directly using the appropriate
UPI code point value (OSI, IPv4, IPv6).

With OSI and IP technologies being deployed in the DCN of the transport
network, it is in some cases necessary to convert OSI encapsulated messages
into IP encapsulated messages and vice versa, or to be able to carry OSI
messages over IP, or IP messages over OSI (i.e. interworking). This is
supported in today's DCN; refer to G.7712.

In general in transport networks (inlcuding future MPLS-TP) you can assume
the presence of a G.7712 DCN, via which transport network elements and
network management systems are interconnected. Some work has to be performed
to extend G.7712 and G.8151 with ECC definitions for the MCN present in
MPLS-TP NNIs. For the SCN G.7712 and G.8151 already include specifications.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: 01 August 2008 10:53
To: Howard Green; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] MPLS over OTN

Hi Howard,

Accurate representation of our conversation.
That is, in GMPLS we have label type, switching type, encoding type, and
G-PID.
G-PID identifies the payload and re-uses the Ethertype codepoints. Thus we
can carry MPLS.
If GFP is used for framing, it must also identify the payload and, as you
point out, GFP has an MPLS codepoint.

That the GFP codepoint for MPLS is the same as that for "T-MPLS" is good for
Option 1 (which is where we are) since there is no practical difference
between MPLS and MPLS-TP.

Now, the operation of MPLS over OTN that you describe is actually the
operation of an OTN. So the issues of control channels in OTN are exactly as
you describe, but have nothing to do with the payload protocol. This is
simply GMPLS control of OTN. Period.

GMPLS control of MPLS-TP is a different kettle of ball games. Here the
switching type is PSC: the same switching type as for MPLS. A feature of
GMPLS is that there is *logical* separation of control plane and data plane.

This means that the control plane can be in-band (MPLS-TE), out-of-band but
in-fibre (SONET/SDH or OSC), or out-of-fibre.

MPLS-TP requirements say that it must be possible to operate the network "in
the absence of IP." I have taken this to mean "in the absence of IP routing
and forwarding" (but this is my opinion and there is no explicit evidence in
the requirements I-D). With this view...
- We can use IP identifiers (addresses) in the data plane and the control
plane
- We can use IP-based control protocols (GMPLS)
- We can use an IP-based control network if available, but we cannot
   mandate it
- Control entities that need to communicate must be allowed to be
   IP-adjacent so that there is no requirement for IP-forwarding in the
   network

1. What is the physical technology for the data links in the control plane?

Answers are:
1. We don't care :-)
    But a possible answer in MPLS-TP is an LSP (e.g. a reserved label) 
2. From the data link (since there is no need to disambiguate the control
   plane traffic from any other traffic on the data link) 
3. This is a more tricky question. However nearly all of the messages
   are exchanged only between data-plane-adjacent nodes. This can be
   the case in the IGP-TE protocols, and is true for all messages in
   RSVP-TE with a couple of exceptions (below). It is also the case for
   LMP. So IP forwarding is not required in the control plane.
   The tricky cases are:
   - echo response in LSP Ping (we are rebuilding the OAM)
   - Notify message in RSVP-TE (we are considering OAM approaches
     for the uses of Notify where IP forwarding is not available)
   - "Targeted Path messages" used in hierarchical LSPs (and LSP
      stitching). In these cases we are effectively building a virtual
      data plane adjacency and should build a parallel virtual control
      plane link between the end points (e.g. an LSP).

We should note that the output of the JWT *appears* to be that "GMPLS meets
the requirements of a control plane for MPLS-TP."

We should also note that management plane operation of MPLS-TP is a
requirement, and we must assume that management plane messages may need to
be exchanged between management stations and network nodes using some
protocol and connectivity.

</homily>

Adrian
----- Original Message -----
From: "Howard Green" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 31, 2008 5:55 PM
Subject: MPLS over OTN

Just to record for the list a chat with Adrian and Lou Berger. I
discover from reading G.7041 Amendment 2 that there is a codepoint
defined to allow unicast MPLS frames to be carried over OTN (ODUx)
channels by way of GFP encoding. Reading RFC 4328, there is an encoding
type for ODUx, and the switching type is TDM. There is no specific G-PID
value defined for the MPLS codepoint (which was probably defined
concurrently with the writing of RFC 4328). Adrian and Lou took the view
that in this situation, the use of the unicast MPLS ethertype (#8847)
would define for signalling this bearer type (as described in RFC 3471).

This is relevant partly because G.7041 amendment 2 defines the codepoint
to be for "MPLS or T-MPLS". I assume that this usage carries over to
MPLS-TP. In this situation,interestingly, there is no prospect of inband
IP control, and so GMPLS is the only control plane option.
Is this correct?
Regards Howard

---

From: "Francesco Fondelli" <[email-masked]>
Date: Mon, 4 Aug 2008 15:00:18 +0200

> The transport network has a DCN, and this DCN inlcudes today a mix of OSI

Hi,

--- draft-jenkins-mpls-mpls-tp-requirements-00

   o  It MUST be possible to operate and configure the MPLS-TP data
      (transport) plane without any IP functionality.

---

So what do you think about this requirement?

Ciao
FF

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 04 Aug 2008 16:28:13 +0200

Francesco,

This requirement defines that the MPLS-TP data (transport) plane operates in
the absence of an IP data (transport) plane. This requirement does not say
anything about the DCN, and the technologies deployed in this DCN.

Regards,
Maarten 

-----Original Message-----
From: Francesco Fondelli [mailto:[email-masked]] 
Sent: 04 August 2008 15:00
To: Maarten Vissers
Cc: Adrian Farrel; Howard Green; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MPLS over OTN

On Mon, Aug 4, 2008 at 2:50 PM, Maarten Vissers <[email-masked]>
wrote:
> Adrian, Howard,
>
> The transport network has a DCN, and this DCN inlcudes today a mix of 
> OSI and IP technologies.

Hi,

---

Ciao
FF

---

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 4 Aug 2008 17:23:25 +0200

Hi,
   I think that the Maarten interpretation is correct.

BR

Diego

> Of Maarten Vissers
> Sent: lunedì 4 agosto 2008 16.28
> To: 'Francesco Fondelli'
> Cc: [email-masked]; [email-masked]

---

From: "Francesco Fondelli" <[email-masked]>
Date: Mon, 4 Aug 2008 17:31:47 +0200

> Francesco,

Hi Maarten,

> anything about the DCN, and the technologies deployed in this DCN.

I agree with you, but I think that "and configure" should be removed.

How can you *configure* MPLS-TP data plane without IP (or OSI)?
Am I the only one that feel uncomfortable with this piece of text?

Ciao
FF

---

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 4 Aug 2008 17:35:37 +0200

Opsss you are right!

I've missed the term configure! I was focused on the fact that an MPLS-TP equipment doesn't need to be able to perform IP forwarding at the data plane.

BR

Diego

> Of Francesco Fondelli
> Sent: lunedì 4 agosto 2008 17.32
> To: Maarten Vissers

---

From: <[email-masked]>
Date: Mon, 4 Aug 2008 17:48:57 +0200

Hi Francesco.

I guess I understand your concern. I believe the original intention was
to say implicitely "It MUST be possible to operate and configure the
MPLS-TP data (transport) plane without any IP functionality *in the data
plane*." My interpretation of these requirements is indeed that they
apply to the MPLS-TP data plane only, not the MPLS-TP-capable equipment,
nor the MPLS-TP control plane...

Anyway you're right, this could be confusing and it deserves a small
rewording.

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Francesco Fondelli

Hi Maarten,

Ciao
FF

---

From: "Francesco Fondelli" <[email-masked]>
Date: Mon, 4 Aug 2008 17:59:45 +0200

> Hi Francesco.

Hi Julien,

> Anyway you're right, this could be confusing and it deserves a small

Nice, thanks a lot.

Ciao
FF

---

From: "Italo Busi" <[email-masked]>
Date: Mon, 4 Aug 2008 20:13:30 +0200

I think that Julien's proposed rephrase better describes the requirement so I
support it.

It is worth noticing that in case of static configuration and OSI based DCN, the
MPLS-TP data (transport) plane is actually configured without any IP
functionality.

However I think that DCN requirements should be described in
draft-gray-mpls-tp-nm-req-00.txt.

For the scope of draft-jenkins-mpls-mpls-tp-requirements-00.txt, I think that it
is more appropriate to rephrase the requirement as proposed by Julien.

Italo

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Francesco Fondelli
> Sent: Monday, August 04, 2008 6:00 PM
> To: [email-masked]
> On Mon, Aug 4, 2008 at 5:48 PM,  
> <[email-masked]> wrote:
> > Hi Francesco.
> 
> Hi Julien,
>

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Mon, 4 Aug 2008 13:31:24 -0500

Dear all,

Julien's proposed rephrase is good.

By the way, DCN requirements (more specifically Management Communication
Network (MCN) requirements) are already described in
draft-gray-mpls-tp-nm-req-00.txt. Of course comments for improvement are
always welcome.

Regards,
Kam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Italo Busi
Sent: Monday, August 04, 2008 2:14 PM
To: 'Francesco Fondelli'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MPLS over OTN

I think that Julien's proposed rephrase better describes the requirement
so I
support it.

It is worth noticing that in case of static configuration and OSI based
DCN, the
MPLS-TP data (transport) plane is actually configured without any IP
functionality.

For the scope of draft-jenkins-mpls-mpls-tp-requirements-00.txt, I think
that it
is more appropriate to rephrase the requirement as proposed by Julien.

Italo

---

From: "Diego Caviglia" <[email-masked]>
Date: Tue, 5 Aug 2008 09:38:04 +0200

Hi all,
       So we are at the point where we agreed that Ip forwarding is not needed in the data plane nevertheless Ip is needed for sure for GMPLS protocols (if used).

Now in this thread we mentioned several times the DCN, are there any requirement about the protocol to be used for the DCN? Do we think that the DCN should support both OSI and Ip?

Given that we are in IETF I think the answer is that the DCN and configuration protocol must be Ip based, but may be could be useful state that somewhere; I agree that draft-gray-mpls-tp-nm-req-00.txt is the right place.

BR

Diego

> Of Italo Busi
> Sent: lunedì 4 agosto 2008 20.14

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 05 Aug 2008 10:23:44 +0200

Diego,

The MPLS-TP functionality may be in equipment with e.g. SDH and OTN
functions. If such equipment uses MS-DCC to connect to the DCN, then it is
very likely that OSI is used. The MPLS-TP functions in this equipment should
**not** require that this equipment has to be equipped with two more DCN
connections supporting IP. I.e. it should be posible to manage MPLS-TP
functionality in equipment also via an OSI type DCN connection.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Diego Caviglia
Sent: 05 August 2008 09:38
To: Italo Busi; Francesco Fondelli; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN)

Hi all,
       So we are at the point where we agreed that Ip forwarding is not
needed in the data plane nevertheless Ip is needed for sure for GMPLS
protocols (if used).

Now in this thread we mentioned several times the DCN, are there any
requirement about the protocol to be used for the DCN? Do we think that the
DCN should support both OSI and Ip?

Given that we are in IETF I think the answer is that the DCN and
configuration protocol must be Ip based, but may be could be useful state
that somewhere; I agree that draft-gray-mpls-tp-nm-req-00.txt is the right
place.

BR

Diego

> I think that Julien's proposed rephrase better describes the 
> requirement so I support it.
> 
> It is worth noticing that in case of static configuration and OSI 
> based DCN, the MPLS-TP data (transport) plane is actually configured 
> without any IP functionality.
> 
> For the scope of draft-jenkins-mpls-mpls-tp-requirements-00.txt, I 
> think that it is more appropriate to rephrase the requirement as 
> proposed by Julien.
> 
> Italo
> 
> > > to say implicitely "It MUST be possible to operate and configure 
> > > the MPLS-TP data (transport) plane without any IP functionality
> > *in the data
> > > plane*." My interpretation of these requirements is indeed that 
> > > they apply to the MPLS-TP data plane only, not the
> > MPLS-TP-capable equipment,
> > > Anyway you're right, this could be confusing and it deserves a 
> > > small rewording.
> >
> > Nice, thanks a lot.
> >
> > > Regards,
> > >
> > > Julien
> >
> > Ciao
> > FF

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 5 Aug 2008 09:54:46 +0100

Maarten,

I think you need to get off this OSI thing.

Nothing the IETF does will require the use of IP in the DCN for an MPLS-TP 
stack. However, the IETF will only work on DCN protocols that are based on 
IP.

It will remain possible to manage MPLS-TP functionality using a DCN based on 
OSI, SNA, PNNI, or bluetak.

Since IP stacks are freely available and pretty small, and since it has 
already been established that IP forwarding is not necessarily required in 
the NEs, I don't know why this thread continues.

A

----- Original Message ----- 
From: "Maarten Vissers" <[email-masked]>
To: "'Diego Caviglia'" <[email-masked]>; "'Italo Busi'" 
<[email-masked]>; "'Francesco Fondelli'" 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 05, 2008 9:23 AM
Subject: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN)

Diego,

Regards,
Maarten

-----Original Message-----

Hi all,

BR

Diego

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 5 Aug 2008 10:15:52 +0100

Maarten had...

> interfaces. 

This needs to read "one or more".

A

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 11 Aug 2008 12:51:43 +0100

These control channels are the last vestige of OSI in modern networks 
(apart from ISIS which is alive and well). Surely it is in the long term 
economic interests of the customer (infrastructure equipment costs, 
training, commonality etc)  to migrate to IP?

Stewart

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 12 Aug 2008 17:59:47 +0100

Catching up on mails...

> nor the MPLS-TP control plane...

Correct.

> Anyway you're right, this could be confusing and it deserves a small

I have reworded to:
"It MUST be possible to operate and configure the MPLS-TP data (transport)
plane without any IP functionality in the MPLS-TP data plane."

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 15 Aug 2008 01:27:19 +0200

Do routers today only support IPv6, or are there still many of the older
protocols supported? I assume it is the latter case, as it is difficult to
switch off support for older protocols as long as its original equipment is
still present at some places in the network. I.e. wouldn't it be in the long
term economic interest of the customer to migrate to IPv6 only? When do you
think you can switch of support for IPv4 and older protocols in the routers?

With OSI in the DCN we have a similar situation. It is still present in many
network elements and must as such be supported within the existing and
future DCN.

Regards,
Maarten

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: 11 August 2008 13:52
To: Adrian Farrel
Cc: Maarten Vissers; 'Diego Caviglia'; 'Italo Busi'; 'Francesco Fondelli';
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN)

These control channels are the last vestige of OSI in modern networks (apart
from ISIS which is alive and well). Surely it is in the long term economic
interests of the customer (infrastructure equipment costs, training,
commonality etc)  to migrate to IP?

Stewart

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 15 Aug 2008 14:43:22 +0100

Maarten,

I agree that OSI is still present in many transport network elements and
therefore DCN support for OSI will be required for some DCNs.

However, does this lead to a requirement that MPLS-TP equipment *must*
support OSI?

Modern transport gear also supports IP for DCN and this is the direction
many operators are choosing to move.

So it would appear to me that the requirements placed on DCN design in
general are different to the requirements placed on the transport equipment
itself (which will be controlled via the DCN).

Let me use BT's transmission DCN as an example - we have a significant sized
DCN consisting of several thousand routers/switches (just for the
transmission DCN itself).  It supports both OSI and IP.  Therefore we are
able to accommodate new transport equipment control via IP while maintaining
control of old transport equipment via OSI.

Ben

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 15 Aug 2008 15:17:18 +0100

Maarten Vissers wrote:
> protocols supported? 
Some router support many protocols, but the only protocols forwarded at 
speed in carrier class routers are IPv4, IPv6 and MPLS.

> I assume it is the latter case, as it is difficult to
> term economic interest of the customer to migrate to IPv6 only? 
You know as well as I do that the issue is interoperability over a 
global network. However you have a much more constrained problem here.
> When do you
That all depends on when the impending address crisis hits and how it 
get resolved.
> network elements and must as such be supported within the existing and
Right, but all of the hosts are IP capable, so it's only the legacy 
clients that need to be OSI capable. We are designing a new MPLS based 
system here, and I see no reason why that needs to understand OSI. The 
most it needs to do is to pass it transparently.

- Stewart