Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01

Lizhong Jin <lizho.jin@gmail.com> Fri, 18 November 2011 15:24 UTC

Return-Path: <lizho.jin@gmail.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 F418521F8922 for <mpls@ietfa.amsl.com>; Fri, 18 Nov 2011 07:24:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.774
X-Spam-Level:
X-Spam-Status: No, score=-2.774 tagged_above=-999 required=5 tests=[AWL=0.824, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 ZSG8K9WeZvLu for <mpls@ietfa.amsl.com>; Fri, 18 Nov 2011 07:24:48 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF8621F89B8 for <mpls@ietf.org>; Fri, 18 Nov 2011 07:24:47 -0800 (PST)
Received: by ghrr14 with SMTP id r14so841773ghr.31 for <mpls@ietf.org>; Fri, 18 Nov 2011 07:24:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=9sq/YQj612PINaYSIqE5o3kkX2QEck3gw6NxBMQ+sOg=; b=aVkbAe8KDcfL5i+mjX2TqRDgG9MF9LmMLEhAKLywRAFYk9BBDMLVff2TCESWMdeN/C Xta/pfQwFd8NA1/JGcOjrgRukhuiPDfP09zRVaMhXSDQjAiQxiHZ8i/4QRytMfJmKzSE myLc3liKx4VuKc+MYgoF6X4/7HDIl/wkiRbcE=
MIME-Version: 1.0
Received: by 10.229.3.133 with SMTP id 5mr375871qcn.212.1321629887264; Fri, 18 Nov 2011 07:24:47 -0800 (PST)
Received: by 10.224.67.81 with HTTP; Fri, 18 Nov 2011 07:24:47 -0800 (PST)
Date: Fri, 18 Nov 2011 23:24:47 +0800
Message-ID: <CAH==cJxFr5Nhd3HpHK8M_HpsKVxvs1tDgentyo9OuUW=J7QXFA@mail.gmail.com>
From: Lizhong Jin <lizho.jin@gmail.com>
To: ice@cisco.com, quintin.zhao@huawei.com
Content-Type: multipart/alternative; boundary="001636833ee8f4778204b203ef4e"
Cc: mpls@ietf.org
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01
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: Fri, 18 Nov 2011 15:24:49 -0000

Hi,
I agree with Ice's summary. I don't think it is very difficult to choose
the option of signaling MT-ID within FEC.

Thanks
Lizhong




> ------------------------------
>
> Message: 2
> Date: Thu, 17 Nov 2011 23:34:50 +0800
> From: IJsbrand Wijnands <ice@cisco.com>
> To: Quintin Zhao <quintin.zhao@huawei.com>
> Cc: mpls@ietf.org
> Subject: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01
> Message-ID: <CB27A6F3-E74A-4FD3-92AA-35C03C39B4D9@cisco.com>
> Content-Type: text/plain; charset=us-ascii
>
> Dear Quintin,
>
> During the MPLS WG presentation you asked for feedback on the different
> options to signal the MT-ID. See below;
>
> I've worked on this with Kamran Raza and we came to the conclusion there
> is really only one good option to signal the MT-ID, and that is within the
> FEC. This is true for LDP, and very much true for mLDP. We documented the
> preferred solution for mLDP, which would also apply to LDP. See;
>
> draft-iwijnand-mpls-mldp-multi-topology-00.txt
>
> Below is a summary of the reasons;
>
> - The LDP spec allows for multiple FEC's to be signaled in a single label
> mapping. If you don't add the MT-ID into the FEC its becomes difficult to
> match the MT-ID the right FEC, so you can't mix and match FEC elements, for
> example for IPv4 and IPv6. For the same reason Address Family is part of
> the FEC.
>
> - The MT-ID is something that is directly related to the Prefix/Root
> address encoded in the FEC, so it makes sense to combine them.
>
> - LDP messages and specifications that use FEC (e.g. Typed Wildcard,
> End-of-LIB) will automatically be extended for MT. There is no need to
> specify for which messages (map, withdraw, release etc..) the MT-ID applies.
>
> - If you are doing mLDP Live-Live using MTR (or MRT) and the 2 LSPs
> merge/overlap for some reason, you potentially duplicate the traffic and
> prevent live-live from working. For that reason the MT-ID MUST be in the
> FEC to make sure the 2 LSPs are unique and will never accidentally merge.
>
> - With mLDP a router may receive label mappings from multiple downstream
> routers, each of them including a different MT-ID. At that point you would
> need come up with some selection logic on which MT-ID you need to select
> and signal upstream. If the MT-ID is part of the FEC, you don't have that
> problem.
>
>
> Thx,
>
> Ice & Kamran
>
>
> ------------------------------
>
> _______________________________________________