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

From: "Santiago Alvarez (saalvare)" <[email-masked]>
Date: Thu, 31 Mar 2011 12:59:23 -0700

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

---

From: venkatesan mahalingam <[email-masked]>
Date: Thu, 31 Mar 2011 16:12:04 -0400

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:

> 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
> 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.
>
>
>
> 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).
>
>
>
>
> nods can be expected o have addresses on the MCN) while RFC 5718 provides
> the required infrastructure for the MCN over G-ACH.
>
>
>
> 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
>
>