IETF Logo Mail Archive

Re: [mpls] MPLS-RT review of draft-rekhter-mpls-pim-sm-over-mldp

IJsbrand Wijnands <ice@cisco.com> Wed, 25 September 2013 22:32 UTC

Return-Path: <ice@cisco.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 2AF4C21F9AE6 for <mpls@ietfa.amsl.com>; Wed, 25 Sep 2013 15:32:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 gyJYaF0OOQNC for <mpls@ietfa.amsl.com>; Wed, 25 Sep 2013 15:32:21 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id ACF9A21F922A for <mpls@ietf.org>; Wed, 25 Sep 2013 15:32:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1037; q=dns/txt; s=iport; t=1380148334; x=1381357934; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=PNvPGMSf7AEcX9TwmE9Zvt+XKNkGDGsd/sYV8NCTYEQ=; b=UUxPZEhjABwBW/nnsu9qAh+dTM0mIi/NDYTssm064ZkkQuBydCpwryIo HP0yMhVe9sqHj0FN4w24EfyhQU0ZZjRGoJkLneyV/RIc/iuGSv2aNyNC9 6fzBMIP+CfSN/+DjafCD5aYjsmO2BwLg2OIl9A8+JhkJWfs7uWPJtm0Sf A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjEFADtkQ1KQ/khM/2dsb2JhbABagwfBXoEgFnSCJQEBAQMBOj8FCwtGVwYuh2UGvEePHjMHgx2BAAOXfJF3gyY6
X-IronPort-AV: E=Sophos;i="4.90,981,1371081600"; d="scan'208";a="160004495"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 25 Sep 2013 22:31:48 +0000
Received: from ams-iwijnand-8711.cisco.com (ams-iwijnand-8711.cisco.com [10.55.191.146]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8PMVlou019233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Sep 2013 22:31:47 GMT
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: IJsbrand Wijnands <ice@cisco.com>
In-Reply-To: <201309252109.r8PL9AL06558@magenta.juniper.net>
Date: Thu, 26 Sep 2013 00:31:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CAC675E9-E3EC-4ECC-9D79-BB6592B1165A@cisco.com>
References: <52303B3B.1060308@pi.nu> <CAH==cJx01+gJCBsV4=bJnrcp5BXYMrTCyynKd3cxMjGx9fUWHQ@mail.gmail.com> <b9d501ceb9be$a444f330$ecced990$@gmail.com> <201309252109.r8PL9AL06558@magenta.juniper.net>
To: Yakov Rekhter <yakov@juniper.net>
X-Mailer: Apple Mail (2.1499)
Cc: mpls@ietf.org, draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org, mpls-chairs@tools.ietf.org, Lizhong Jin <lizho.jin@gmail.com>
Subject: Re: [mpls] MPLS-RT review of draft-rekhter-mpls-pim-sm-over-mldp
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: Wed, 25 Sep 2013 22:32:40 -0000

Yakov,

> I can not comment on whether it is "more natural to follow the mechanism 
> in draft-ietf-mpls-seamless-mcast".

I think the question is, is there a need for a solution that combines mLDP in-band signalling with BGP AD. What is the advantage of this solution compared to what is already defined in draft-ietf-mpls-seamless-mcast? I can see that it does not require Leaf auto-discovery routes, but is that an advantage? Moreover, most customers like mLDP in-band signalling because it does not depend on BGP AD.

> auto-discovery routes. Moreover, draft-rekhter-mpls-pim-sm-over-mldp
> spells out that in certain deployment scenarios even Source Active
> auto-discovery routes would not be used.

Do you mean like what is documented in draft-wijnands-mpls-mldp-in-band-wildcard-encoding-00 section 3? Is the solution in draft-wijnands not a better way to support that since it does not require new Opaque TLV encodings and covers both global table and VRF support?

Thx,

Ice.

v2.23.0 | Report a Bug | By Email