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

From: venkatesan mahalingam <[email-masked]>
Date: Fri, 1 Apr 2011 10:42:09 -0400

Hi,
If we don't have the host IP stack on every node in the -TP network, we may
have to follow the management channel as given in the RFC 5960, 2.5.
 Management Channel.

IMO, this channel can be used to configure the remote Non-IP systems using
management messages.

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

   - *To*: Malcolm.BETTS at zte.com.cn <[email-masked]>
   - *Subject*: Re: [mpls] Do we need to reinvent TCP/IP, or what does it
   really mean that MPLS-TP is IP-free?
   - *From*: "Andrew G. Malis" <agmalis at gmail.com <[email-masked]>
   - *Date*: Fri, 1 Apr 2011 14:33:37 +0200
   - *Cc*: mpls at ietf.org <[email-masked]>
   - *Delivered-to*: mpls at core3.amsl.com <[email-masked]>
   - *Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com;
   s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date
   :message-id:subject:to:cc:content-type;
   bh=bjqA6TpB6I/UtFLt1OCY7A+KBR1Ig5fychX3zycyvlg=;
   b=ExEd83DDhYBZH29xY6sDJ7ef/WER6z4kllFXzqFE26K1G0Fsi+0JQX0RL/G07yA4rE
   59drblmNaG1nzzQP7C2VFHQYefKh/7FJetoKOL8uevob1YM8+YPmeACWNg2TCAtL3Nll
   kvbpaVyG1cqlhLBNxYbIhtWPKRkWJZdkKC26I=
   - *Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
   h=mime-version:in-reply-to:references:from:date:message-id:subject:to
   :cc:content-type;
   b=vq0Qb3PjTymhN1C52aGhGke5gGa7UkohGaS64VxPcn/Lp6KplQ947kTEpQr3lnxn6Z
   XaXyUSP+bHOId0dDk3hWA7So+trvLKH4bz1WXnaqQ98MwhHuQgVrWI7XLmW4cSCxpchm
   N9XRkqtPWJ4l4t3aCaePTZGuF+a6lUtQ+lvYM=
   - *In-reply-to*: <OF6D81D565.7BAC9316-ON85257865.0026AEAF-85257865.0028D20F
   at zte.com.cn<[email-masked]>
   - *List-archive*: <http://www.ietf.org/mail-archive/web/mpls>
   - *List-help*:
<mailto:[email-masked]?subject=help<[email-masked]?subject=help>
   - *List-id*: Multi-Protocol Label Switching WG <mpls.ietf.org>
   - *List-post*: <mailto:[email-masked] <[email-masked]>>
   - *List-subscribe*: <https://www.ietf.org/mailman/listinfo/mpls>, <
   mailto:[email-masked]?subject=subscribe<[email-masked]?subject=subscribe>
   - *List-unsubscribe*: <https://www.ietf.org/mailman/listinfo/mpls>, <
   mailto:[email-masked]?subject=unsubscribe<[email-masked]?subject=unsubscribe>
   - *References*: <AANLkTi=0kyD+QhCdWL2E6bHbtO0r3A-ZQx=VovS7TajS at
   mail.gmail.com<[email-masked]>>
   <OF6D81D565.7BAC9316-ON85257865.0026AEAF-85257865.0028D20F at
zte.com.cn<[email-masked]>

------------------------------
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, <Malcolm.BETTS at zte.com.cn> wrote:

>
> 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 <venkatflex at gmail.com>*
> Sent by: mpls-bounces at ietf.org
>
> 31/03/2011 04:12 PM
> To
> "Santiago Alvarez (saalvare)" <saalvare at cisco.com>, mpls <mpls at
> ietf.org>, Alexander Vainshtein <alexander.vainshtein at ecitele.com>
> 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) <*saalvare at
> cisco.com* <saalvare at cisco.com>> 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:* *mpls-bounces at ietf.org* <mpls-bounces at ietf.org> [mailto:*mpls-bounces
> at ietf.org* <mpls-bounces at ietf.org>] *On Behalf Of *Alexander
> Vainshtein*
> Sent:* Thursday, March 31, 2011 10:31 AM*
> To:* Luca Martini (lmartini)*
> Cc:* *mpls at ietf.org* <mpls at ietf.org>*
> 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*
> **mpls at ietf.org* <mpls at ietf.org>*
> **https://www.ietf.org/mailman/listinfo/mpls*<https://www.ietf.org/mailman/listinfo/mpls>
>
> _______________________________________________
> mpls mailing list
> mpls at ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>