Re: Wildcard bindings for S-PMSIs
Yakov Rekhter <yakov@juniper.net> Wed, 29 July 2009 05:57 UTC
Return-Path: <yakov@juniper.net>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D19E3A6A45 for <l3vpn@core3.amsl.com>; Tue, 28 Jul 2009 22:57:26 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxJNaLx6ul-8 for <l3vpn@core3.amsl.com>; Tue, 28 Jul 2009 22:57:25 -0700 (PDT)
Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id E09CF3A6809 for <l3vpn@ietf.org>; Tue, 28 Jul 2009 22:57:24 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSm/kxSjI6q2hvzQ73hHI5r67m8vDSQM5@postini.com; Tue, 28 Jul 2009 22:57:26 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 28 Jul 2009 22:51:02 -0700
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 22:51:01 -0700
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 22:51:01 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jul 2009 22:51:00 -0700
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n6T5p0d00842; Tue, 28 Jul 2009 22:51:00 -0700 (PDT) (envelope-from yakov@juniper.net)
Message-ID: <200907290551.n6T5p0d00842@magenta.juniper.net>
To: erosen@cisco.com
Subject: Re: Wildcard bindings for S-PMSIs
In-Reply-To: <16640.1248362475@erosen-linux>
References: <16640.1248362475@erosen-linux>
X-MH-In-Reply-To: Eric Rosen <erosen@cisco.com> message dated "Thu, 23 Jul 2009 11:21:15 -0400."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <87930.1248846660.1@juniper.net>
Date: Tue, 28 Jul 2009 22:51:00 -0700
From: Yakov Rekhter <yakov@juniper.net>
X-OriginalArrivalTime: 29 Jul 2009 05:51:00.0793 (UTC) FILETIME=[8D32FA90:01CA1010]
Cc: l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2009 05:57:26 -0000
Eric, > I have read draft-rekhter-mvpn-wildcard-spmsi-00.txt with interest. I am > glad to see others in the WG show interest in the use of "wild cards", as > this capability has been documented for quite some time in > draft-rosen-l3vpn-mvpn-mspmsi, sections 4, 5, and 6. Just for the record, the authors of MVPN and BGP-MVPN specs discussed the use of wildcards well before you published draft-rosen-l3vpn-mvpn-msmsi. > Mostly draft-rekhter is compatible with draft-rosen, though the former > specifies only a subset of what is specified in the latter. There are a Yes, draft-rekhter specifies only a subset of what is specified in draft-rosen, as the latter specifies not just the use of wild cards, but plenty of other stuff as well. However, if we focus on just the wildcard part of draft-rosen, then your claim that draft-rekhter "specifies only a subset of what is specified" in draft-rosen is incorrect. More on this below. > couple of substantive, though minor, differences which should be discussed > by the WG. > > - - In draft-rosen, a (*,G) wild card is only legal when G is in the ASM group > address range. In draft-rekhter, this restriction is not imposed, > > My thinking here is that if G is not an ASM group, there is no real use > for (*,G) and its appearance is most likely an error. However, if anyone > knows of a practical application for (*,G) wild card when G is an SSM > group, it would be interesting to learn of it. In draft-rekhter a (*, G) wildcard is legal when G is either in the ASM range, or in the Bidir range. Both are useful. > - - In draft-rosen, procedures are defined for using the (*,*) wild card only > when the S-PMSI is instantiated by a bidirectional P-tunnel. In > draft-rekhter, the (*,*) wild card is allowed when the S-PMSI is > instantiated by a unidirectional P-tunnel. > > On reflection, this does seem like it could be useful, especially if > there is no I-PMSI and one is using a BGP control plane. You just provided an example that shows that contrary to your claim, what is in draft-rekhter is *more* than "only a subset" of what is in draft-rosen. > - - In draft-rekhter, it is suggested (though not stated explicitly) that the > wild cards are useful for assigning BIDIR-PIM C-flows to S-PMSIs that are > instantiated by unidirectional P-tunnels. This is omitted from > draft-rosen. Now you provided yet another example that shows that contrary to your claim, what is in draft-rekhter is *more* than "only a subset" of what is in draft-rosen. Yet another example that shows that contrary to your claim, what is in draft-rekhter is *more* than "only a subset" of what is in draft-rosen is the ability to bind (C-S, C-G) flows flowing on C-SPT to a (C-*, C-G) S-PMSI. Moreover, (C-S, C-*) S-PMSI in the -01 version of the draft is yet another example that shows that contrary to your claim, what is in draft-rekhter is *more* than "only a subset" of what is in draft-rosen. > Perhaps the use of wild cards in this manner may be useful > if BIDIR-PIM is supported using the procedures of section 11.1 of draft- > ietf-l3vpn-2547bis-mcast-08. So, we agreed on that. > I don't think it would be useful if > BIDIR-PIM is supported using the procedures of section 11.2 of draft-ietf- > l3vpn-2547bis-mcast-08. This needs to be clarified. While you "don't think it would be useful if BIDIR-PIM is supported using the procedures of section 11.2", I think to the contrary. Namely that the wildcard is useful for assigninng BIDIR-PIM C-flows to S-PMSIs that are instantiated by unidirectional P-tunnels using the procedures of section 11.2. > These are good points to discuss, but generally if one publishes a draft > that is largely a subset of an existing draft, one is expected at least to > reference the existing draft, to point out the differences, and to explain > why a new draft might be needed. Your claim about "a subset", as illustrated above, is incorrect. > I don't see any other substantive differences, or indeed any major > disagreement. Draft-rehkter has copied the encoding for the S-PMSI A-D > routes from draft-rosen. Wrt the encoding, both draft-rekhter and draft-rosen rely on the encoding specified in BGP-MVPN. Both draft-rosen and draft-rekhter use the 0/0 prefix encoding to indicate the "match all" semantics. Use of the 0/0 prefix encoding to indicate the "match all semantics" well predates draft-rosen. > The main difference is that draft-rekhter has a > much more limited scope: Your claim that "draft-rekhter has a much more limited scope", is incorrect, as draft-rekhter covers quite a few cases that are not in draft-rosen. > - - The spec in draft-rekhter only covers the case where BGP is the PE-PE > control plane, while the spec in draft-rosen covers both that case and the > case where PIM is the PE-PE control plane. (And for the case where PIM is > the PE-PE control plane, also covers the use of the S-PMSI Join messages.) > > - - The spec in draft-rekhter does not cover the use of wild cards with > bidirectional P-tunnels. This is because according to 6.4.4 of draft-ietf-l3vpn-2547bis-mcast-08.txt: Specification of the procedures for assigning C-flows to mLDP MP2MP LSPs that serve as P-tunnels is outside the scope of this document. > The text in draft-rekhter that justifies the use of wild cards is not > cut-and-pasted from draft-rosen, but doesn't seem to say anything > significantly different. Wrt "doesn't seem to say anything significantly different", I disagree, as the text in draft-rekhter is specified in terms of the changes to the currently specified procedures in BGP-MVPN for handling S-PMSI, while the text in draft-rosen does *not*. Yakov.
- Wildcard bindings for S-PMSIs Eric Rosen
- RE: Wildcard bindings for S-PMSIs NAPIERALA, MARIA H, ATTLABS
- Re: Wildcard bindings for S-PMSIs Yakov Rekhter
- Re: Wildcard bindings for S-PMSIs Eric Rosen
- Re: Wildcard bindings for S-PMSIs robert