Subject: Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free?

From: [email-masked]
Date: Fri, 1 Apr 2011 02:26:01 -0500

All,

True that in most cases an IP stack is present somewhere in most nodes to 
support a management interface.  However, this does not mean that high 
bandwidth or high reliability access is provided to that stack from the 
cards that support the forwarding plane functionality.  Typically in small 
transport nodes the card supporting the management interface has a low 
bandwidth and is non-redundant since if that card fails the forwarding 
plane is not affected (including OAM and protection).  This is the reason 
that MPLS-TP forwarding and dataplane OAM must run IP free.

This requirement was one of the primary inputs from the ITU and I am very 
surprised that people are raising questions at this stage.

Regards,

Malcolm

venkatesan mahalingam <[email-masked]> 
Sent by: [email-masked]
31/03/2011 04:12 PM

To
"Santiago Alvarez (saalvare)" <[email-masked]>, mpls <[email-masked]>, 
Alexander Vainshtein <[email-masked]>
cc

Subject
Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that 
MPLS-TP is IP-free?

Hi,

I think, we need at least an IP host stack on every node along the MPLS-TP 
path to support the IP based management operations (ex. SNMP).

Thanks,
Venkat.
On Thu, Mar 31, 2011 at 3:59 PM, Santiago Alvarez (saalvare) <
[email-masked]> wrote:
MPLS-TP nodes would need an IP host stack to be able to source/sink IP 
traffic for management (e.g. SNMP).  An LSR should not have an IP routing 
function with the exception of a LER where IP acts as a client. That IP 
routing/forwarding function should be defined in RFC 1812.
Cheers.
 
SA
--
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Alexander Vainshtein
Sent: Thursday, March 31, 2011 10:31 AM
To: Luca Martini (lmartini)
Cc: [email-masked]
Subject: [mpls] Do we need to reinvent TCP/IP, or what does it really mean 
that MPLS-TP is IP-free?
 
Luca and all,
What I have been trying to say at the mike today can be essentially 
reduced to a very simple statement:
 
The ?requirement? for IP-free MPLS-TP is very vague and requires 
clarification.
 
MPLS-TP nodes presumably have to be managed (especially if they are 
supposed to operate independent of any control plane). And personally I do 
not believe they are going to be managed by connecting a local terminal 
via a serial cable to each of these nodes (of course you are free to 
disagreeJ).  
 
This assumes a Management Communication Network (MCN), and , IMHO, this 
assumption is ensconced in RFC 5951 (which states that typically MPLS-TP 
nods can be expected o have addresses on the MCN) while RFC 5718 provides 
the required infrastructure for the MCN over G-ACH.
 
Of course we can pretend that we do not know which network protocol will 
run on top of the MCN (and some people have been arguing that we should 
select the OSI stack for that purpose in the early days of the MPLS-TP 
work); but I would expect that within the IETF refusal to use IP in this 
role should not be taken too seriouslyJ. The recent work  on SNMP MIBs 
architecture for MPLS-TP looks to me as an additional confirmation.
 
Hence it seems safe to assume that each MPLS-TP node will run at least a 
host IP stack (not necessarily in the forwarding path).
 
Once we agree on that, we could stop reinventing ?TCP/IP for poor?  with 
proprietary solutions for reliability, fragmentation/reassembly, 
congestion avoidance etc.
 
My 2c,
     Sasha

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

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

---

From: <[email-masked]>
Date: Fri, 1 Apr 2011 08:50:22 +0100

Might be worth trying to understand how layered networks work and how this varies in the 3 network modes of co-cs, co-ps, cl-ps.

-	In the cl-ps case the traffic units of the DP and their associated CP/MP protocols all use the same/single DP layer network.

-	In the co-cs case the traffic DP layer network is forced to be at least logically disjoint from the CP/MP layer network (as is the case with GMPLS).....and this is also a very good design principle for the co-ps mode for security and other reasons.
 
-	In the co-ps mode one needs to apply a conscious design decision to have the CP/MP logically OOB wrt to the traffic DP (ie it's not automatically forced like it is with the co-cs mode).  Indeed, we are now finally getting round to doing this with MPLS-TP.

The reason the different network modes exist comes from the physics of how one carves up a space/freq/time (capacity) resource and then labels it (eg to distinguish different client users).

A more formal description of what is going on here can be found in G.800.

Note:  All 3 networks modes are different and all are required for a full-service operator (ie one mode/technology cannot do-it-all well/efficiently).....which is of course why we have MPLS (co-ps...sort-of anyway) and GMPLS (co-cs) to complement IP (cl-ps).   Note also that in the co-cs and co-ps modes we essentially have a 'network system' as the traffic DP layer network and the CP/MP DP layer network are logically disjoint, and the network mode of the CP/MP is invariably cl-ps and IP-based whereas the traffic DP network mode is obviously either co-cs or co-ps in nature.  

I hope that helps as I often see quite a bit of confusion about the above points.

regards, Neil

BT Design

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000
====

From: [email-masked] [mailto:[email-masked]] On Behalf Of venkatesan mahalingam
Sent: 31 March 2011 21:12
To: Santiago Alvarez (saalvare); mpls; Alexander Vainshtein
Subject: Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free?

Hi,

I think, we need at least an IP host stack on every node along the MPLS-TP path to support the IP based management operations (ex. SNMP).

Thanks,
Venkat.
On Thu, Mar 31, 2011 at 3:59 PM, Santiago Alvarez (saalvare) <[email-masked]> wrote:
MPLS-TP nodes would need an IP host stack to be able to source/sink IP traffic for management (e.g. SNMP).  An LSR should not have an IP routing function with the exception of a LER where IP acts as a client. That IP routing/forwarding function should be defined in RFC 1812.
Cheers.
 
SA
--
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Thursday, March 31, 2011 10:31 AM
To: Luca Martini (lmartini)
Cc: [email-masked]
Subject: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free?
 
Luca and all,
What I have been trying to say at the mike today can be essentially reduced to a very simple statement:
 
      The “requirement” for IP-free MPLS-TP is very vague and requires clarification.
 
MPLS-TP nodes presumably have to be managed (especially if they are supposed to operate independent of any control plane). And personally I do not believe they are going to be managed by connecting a local terminal via a serial cable to each of these nodes (of course you are free to disagree☺).  
 
This assumes a Management Communication Network (MCN), and , IMHO, this assumption is ensconced in RFC 5951 (which states that typically MPLS-TP nods can be expected o have addresses on the MCN) while RFC 5718 provides the required infrastructure for the MCN over G-ACH.
 
Of course we can pretend that we do not know which network protocol will run on top of the MCN (and some people have been arguing that we should select the OSI stack for that purpose in the early days of the MPLS-TP work); but I would expect that within the IETF refusal to use IP in this role should not be taken too seriously☺. The recent work  on SNMP MIBs architecture for MPLS-TP looks to me as an additional confirmation.
 
Hence it seems safe to assume that each MPLS-TP node will run at least a host IP stack (not necessarily in the forwarding path).
 
Once we agree on that, we could stop reinventing “TCP/IP for poor”  with proprietary solutions for reliability, fragmentation/reassembly, congestion avoidance etc.
 
My 2c,
     Sasha

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 1 Apr 2011 14:33:37 +0200

Malcolm,

I 'm not aware of anything in the IETF specifications that's inconsistent
with this requirement, which is clear in section 2.3 in RFC 5654 and section
2.1.4 in RFC 5860 (and perhaps elsewhere as well).

Cheers,
Andy

On Fri, Apr 1, 2011 at 9:26 AM, <[email-masked]> wrote:

> bandwidth and is non-redundant since if that card fails the forwarding plane
> is not affected (including OAM and protection).  This is the reason that
> MPLS-TP forwarding and dataplane OAM must run IP free.
>
>  *venkatesan mahalingam <[email-masked]>*
> On Thu, Mar 31, 2011 at 3:59 PM, Santiago Alvarez (saalvare) <*
> [email-masked]* <[email-masked]>> wrote:
> *From:* [email-masked]* <[email-masked]> [mailto:*
> [email-masked]* <[email-masked]>] *On Behalf Of *Alexander
> Vainshtein*
> Sent:* Thursday, March 31, 2011 10:31 AM*
> To:* Luca Martini (lmartini)*
> Cc:* [email-masked]* <[email-masked]>*
> Subject:* [mpls] Do we need to reinvent TCP/IP, or what does it really
> mean that MPLS-TP is IP-free?
>
>
>
> Luca and all,
>
> not believe they are going to be managed by connecting a local terminal via
> a serial cable to each of these nodes (of course you are free to disagreeJ).
>
>
>
>
> Once we agree on that, we could stop reinventing “TCP/IP for poor”  with
> proprietary solutions for reliability, fragmentation/reassembly, congestion
> avoidance etc.
>
>
>
> My 2c,
>
>      Sasha
>
>
>
> mpls mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/mpls*<https://www.ietf.org/mailman/listinfo/mpls>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 1 Apr 2011 23:51:40 +0300

Malcolm,
Lots of thanks for a prompt response.

I see it as the first step (presumably of many to follow) towards clarifying the requirement of keeping MPLS-TP IP-free.

Please see more inline below.

Regards,
     Sasha

________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Friday, April 01, 2011 10:26 AM
To: [email-masked]
Subject: Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free?

All,

True that in most cases an IP stack is present somewhere in most nodes to support a management interface.
[[Sasha]] Great, we seem to be in agreement here!
However, this does not mean that high bandwidth or high reliability access is provided to that stack from the cards that support the forwarding plane functionality. [[Sasha]] This is fully understood and, in most cases, not required IMO. Luca's draft provides a very good example for that.

Typically in small transport nodes the card supporting the management interface has a low bandwidth [[Sasha]] Please see above and is non-redundant since if that card fails the forwarding plane is not affected (including OAM and protection).

[[Sasha]] This is a very strong assumption that is not in any way related to having - ort not having - IP stack.
IMHO  you say that ability of a transport node to response to a protection switch requests MUST NOT involve not just the the CP (which is a valid requirement), but also none of the HW components that are inv olved with teh CP operation. Did I read you correctly? If yes, why have ITU-T never specified such a requirement explicitly?

If this requirement was stated, it would strongly affect protection mechanisms because I would expect that, where applicable, Working and Protecting LSPs would be terminated on different cards.

And of course, processing of OAM messages (sent and received in the data plane) must not affect in any way the cHW component that deals (among other things) with management etc.

Last but not least, from my (admittedly, outdated) experience when. almost 20 years ago, I  have been designing management communication stacks for the traditional (SONET/SDH) transport nodes, the operators consider loss of management communication with such a node as a critical issue in spite of all available OAM. Unless this attitude has undergone a drastic change, I would suspect that a node with reduddant data plane and non-redundant control plane would not be the first choice for a small transport node...

 This is the reason that MPLS-TP forwarding and dataplane OAM must run IP free.

[[Sasha]] As you've said in your presentation in the Routing Area Open at this IETF meeting, one has to be pragmatic in standards. Trying to purge MPLS-TP of any reliance on IP looks to me like going far beyond pragmatism.

This requirement was one of the primary inputs from the ITU and I am very surprised that people are raising questions at this stage.

Regards,

Malcolm

31/03/2011 04:12 PM

To
        "Santiago Alvarez (saalvare)" <[email-masked]>, mpls <[email-masked]>, Alexander Vainshtein <[email-masked]>
cc

Subject
        Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free?

Hi,

Thanks,
Venkat.
On Thu, Mar 31, 2011 at 3:59 PM, Santiago Alvarez (saalvare) <[email-masked]<mailto:[email-masked]>> wrote:
MPLS-TP nodes would need an IP host stack to be able to source/sink IP traffic for management (e.g. SNMP).  An LSR should not have an IP routing function with the exception of a LER where IP acts as a client. That IP routing/forwarding function should be defined in RFC 1812.

Cheers.

SA

--

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alexander Vainshtein
Sent: Thursday, March 31, 2011 10:31 AM
To: Luca Martini (lmartini)
Cc: [email-masked]<mailto:[email-masked]>
Subject: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free?

Luca and all,

MPLS-TP nodes presumably have to be managed (especially if they are supposed to operate independent of any control plane). And personally I do not believe they are going to be managed by connecting a local terminal via a serial cable to each of these nodes (of course you are free to disagree:)).

Of course we can pretend that we do not know which network protocol will run on top of the MCN (and some people have been arguing that we should select the OSI stack for that purpose in the early days of the MPLS-TP work); but I would expect that within the IETF refusal to use IP in this role should not be taken too seriously:). The recent work  on SNMP MIBs architecture for MPLS-TP looks to me as an additional confirmation.

My 2c,

     Sasha

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

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Sat, 2 Apr 2011 09:33:48 +0100

Colleagues,

I wasn't in the MPLS WG session so do not have the full context of the discussion but as the editor of RFC5654 maybe I can help with the context of what RFC5654 says regarding IP. The wording of the IP related requirements (e.g. requirement 36) was much debated and the wording in the final RFC was very carefully chosen.

The requirement as stated is that MPLS-TP nodes & networks must be able to be operated and configured without individual nodes being required to have an IP forwarding capability. There is not a requirement in RFC5654 for MPLS-TP nodes to be able to be operated and configured in the complete absence of IP.

In other words it is reasonable to assume MPLS-TP boxes MUST be able to source & sink IP packets with a source/destination IP address that is assigned to that MPLS-TP node/box for operation/configuration (i.e. management) but that must be possible without requiring that MPLS-TP boxes are capable of performing IP routing or forwarding of packets with a destination IP address that is assigned to a different node in the network.

HTH
Ben

On 1 Apr 2011, at 13:33, Andrew G. Malis wrote:

> Malcolm,
> 
> I 'm not aware of anything in the IETF specifications that's inconsistent with this requirement, which is clear in section 2.3 in RFC 5654 and section 2.1.4 in RFC 5860 (and perhaps elsewhere as well).
> 
> Cheers,
> Andy
> 
> True that in most cases an IP stack is present somewhere in most nodes to support a management interface.  However, this does not mean that high bandwidth or high reliability access is provided to that stack from the cards that support the forwarding plane functionality.  Typically in small transport nodes the card supporting the management interface has a low bandwidth and is non-redundant since if that card fails the forwarding plane is not affected (including OAM and protection).  This is the reason that MPLS-TP forwarding and dataplane OAM must run IP free. 
> 
> MPLS-TP nodes presumably have to be managed (especially if they are supposed to operate independent of any control plane). And personally I do not believe they are going to be managed by connecting a local terminal via a serial cable to each of these nodes (of course you are free to disagreeJ).  
> 
>   
> Of course we can pretend that we do not know which network protocol will run on top of the MCN (and some people have been arguing that we should select the OSI stack for that purpose in the early days of the MPLS-TP work); but I would expect that within the IETF refusal to use IP in this role should not be taken too seriouslyJ. The recent work  on SNMP MIBs architecture for MPLS-TP looks to me as an additional confirmation.
> 
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 2 Apr 2011 20:21:15 +0300

Ben,
Lots of thanks for a prompt and clarifying response.

To make things a bit more clear, the context for my question at the mike and the consequent email thread was Luca's draft on aggregation of PW status (https://datatracker.ietf.org/doc/draft-martini-pwe3-status-aggregation-protocol/?include_text=1) and associated presentation (http://www.ietf.org/proceedings/80/slides/mpls-21.ppt).

The proposed protocol was supposed to run on top of G-ACh/GAL in the tunnel LSP between a pair of PEs and would take care of such issues as reliable delivery, fragmentation of messages etc. Congestion avoidance and security have not been mentioned, but I would expect them to appear in some future versions (e.g., in response to the comments from the Transport and/or Security Directorates:-).

That is why I said that using TCP/IP on top of G-ACh/GAL as the bearer of such a protocol looked a perfectly natural thing to do.  Of course this would not require any IP forwarding capabilities.

Hopefully this note would be useful.

Regards,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Benjamin Niven-Jenkins [[email-masked]]
Sent: Saturday, April 02, 2011 11:33 AM
To: Andrew G.Malis
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Do we need to reinvent TCP/IP,      or what does it really mean that MPLS-TP is IP-free?

Colleagues,

HTH
Ben