Re: [mpls] MPLS-RT review of draft-jjb-mpls-rsvp-te-hsmp-lsp

Sriganesh Kini <sriganesh.kini@ericsson.com> Thu, 19 July 2012 00:25 UTC

Return-Path: <sriganesh.kini@ericsson.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FF511E80E8 for <mpls@ietfa.amsl.com>; Wed, 18 Jul 2012 17:25:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VU2e7PIpFn1U for <mpls@ietfa.amsl.com>; Wed, 18 Jul 2012 17:25:10 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9815D11E80CC for <mpls@ietf.org>; Wed, 18 Jul 2012 17:25:10 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6J0PvZB016362; Wed, 18 Jul 2012 19:25:59 -0500
Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.11]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 18 Jul 2012 20:25:55 -0400
From: Sriganesh Kini <sriganesh.kini@ericsson.com>
To: Ross Callon <rcallon@juniper.net>, "eosborne@cisco.com" <eosborne@cisco.com>, Nic Leymann <N.Leymann@telekom.de>
Content-Class: urn:content-classes:message
Date: Wed, 18 Jul 2012 20:25:54 -0400
Thread-Topic: MPLS-RT review of draft-jjb-mpls-rsvp-te-hsmp-lsp
Thread-Index: Ac1gT7jVackrh7o9R3Gsa12wCTnrggE8aUfGAADsN1w=
Message-ID: <892E1155-AFD2-4AFE-9C12-337E45FA218C@mimectl>
References: <DF7F294AF4153D498141CBEFADB17704C712E8A79D@EMBX01-WF.jnpr.net>
In-Reply-To: <DF7F294AF4153D498141CBEFADB17704C712E8A79D@EMBX01-WF.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-mimectl: Produced By Microsoft Exchange V8.3.105.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mpls@ietf.org" <mpls@ietf.org>, "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>, "lizhong.jin@zte.com.cn" <lizhong.jin@zte.com.cn>
Subject: Re: [mpls] MPLS-RT review of draft-jjb-mpls-rsvp-te-hsmp-lsp
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jul 2012 00:25:11 -0000

Hi Manav and other authors,

Thanks for the additional pointers that you sent to help understand the draft. It certainly helped.

However before I make a detailed review, I wanted to better understand the motivation of this draft. If I understood correctly, the HSMP LSP is co-routing unicast traffic from PE-x to PE-y with multicast traffic in the reverse direction i.e, PE-y to PE-x. However these are independent services and will have different TE characteristics. I don't see how co-routing that traffic helps to solve the TE problem, when that is the primary requirement of the network design. In fact it may make it even harder.

I agree that some labels entries may be saved by having a MP2P construct for the unicast traffic. However note that even for unicast traffic the TE characteristics for traffic from PE-x to PE-y can be different than traffic from PE-z to PE-y. An MP2P LSP is less likely to provide a solution for that problem and when it additionally gets constrained to be co-routed with another P2MP LSP that is satisfying TE requirements of another service then it is even less likely to do so.

Another possible advantage of HSMP seems to be that there is some saving in signaling since forward and reverse direction labels are signaled at the same time. However IMO these savings are not big enough. At least not big enough that independent services must be constrained to be co-routed.

Note that I am not saying that VPLS does not have problems, nor am I saying that P2MP LSPs should not be used in VPLS. My primary question is about the motivation for the co-routing when TE is a requirement and the associated problems I described above for HSMP.

Let me know if I have understood anything incorrectly.

Thanks
- Sri
________________________________
From: Ross Callon [rcallon@juniper.net]
Sent: Thursday, July 12, 2012 9:59 AM
To: Sriganesh Kini; eosborne@cisco.com; Nic Leymann
Cc: Loa Andersson; George Swallow (swallow); Ross Callon; Martin Vigoureux; lizhong.jin@zte.com.cn; frederic.jounay@orange.ch; Bhatia, Manav (Manav)
Subject: MPLS-RT review of draft-jjb-mpls-rsvp-te-hsmp-lsp

Sriganesh, Eric, Nic;

You have been selected as an MPLS Review team reviewers for
draft-jjb-mpls-rsvp-te-hsmp-lsp

Note to authors: You have been CC’d on this email so that you can know that
this review is going on. However, please do not review your own document.

Reviews should comment on whether the document is coherent, is it useful
(ie, is it likely to be actually useful in operational networks), and is
the document technically sound?  We are interested in knowing whether the
document is ready to be considered for WG adoption (ie, it doesn’t have to
be perfect at this point, but should be a good start).

Reviews should be sent to the document authors, WG co-chairs and secretary,
and CC’d to the MPLS WG email list. If necessary, comments may be sent
privately to only the WG chairs.

Are you able to review this draft by July 27, 2012 (ie, prior to the IETF
meeting in Vancouver)?

Thanks, Ross
(as MPLS WG chair)