Re: [mpls] Way two progress two mldp draft with an technical overlap

Yakov Rekhter <yakov@juniper.net> Tue, 04 February 2014 21:59 UTC

Return-Path: <yakov@juniper.net>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB831A015A for <mpls@ietfa.amsl.com>; Tue, 4 Feb 2014 13:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2u0JhDev5QWq for <mpls@ietfa.amsl.com>; Tue, 4 Feb 2014 13:59:01 -0800 (PST)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id E294D1A012C for <mpls@ietf.org>; Tue, 4 Feb 2014 13:59:00 -0800 (PST)
Received: from mail78-co1-R.bigfish.com (10.243.78.244) by CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id 14.1.225.22; Tue, 4 Feb 2014 21:59:00 +0000
Received: from mail78-co1 (localhost [127.0.0.1]) by mail78-co1-R.bigfish.com (Postfix) with ESMTP id 63CCAD400E4; Tue, 4 Feb 2014 21:59:00 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.239.11; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: -1
X-BigFish: VPS-1(zz1432Idb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz31h2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h1155h)
Received-SPF: softfail (mail78-co1: transitioning domain of juniper.net does not designate 66.129.239.11 as permitted sender) client-ip=66.129.239.11; envelope-from=yakov@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ;
Received: from mail78-co1 (localhost.localdomain [127.0.0.1]) by mail78-co1 (MessageSwitch) id 1391551138189415_10358; Tue, 4 Feb 2014 21:58:58 +0000 (UTC)
Received: from CO1EHSMHS011.bigfish.com (unknown [10.243.78.250]) by mail78-co1.bigfish.com (Postfix) with ESMTP id 1F76C8C004A; Tue, 4 Feb 2014 21:58:58 +0000 (UTC)
Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by CO1EHSMHS011.bigfish.com (10.243.66.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 4 Feb 2014 21:58:57 +0000
Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 4 Feb 2014 13:58:57 -0800
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s14LwnL93027; Tue, 4 Feb 2014 13:58:49 -0800 (PST) (envelope-from yakov@juniper.net)
Message-ID: <201402042158.s14LwnL93027@magenta.juniper.net>
To: Loa Andersson <loa@pi.nu>
In-Reply-To: <52F11FD8.3000000@pi.nu>
References: <529F425C.1050808@pi.nu> <201312061405.rB6E5bL25339@magenta.juniper.net> <52A9958B.7040508@pi.nu> <201312121651.rBCGpYL46117@magenta.juniper.net> <52F11FD8.3000000@pi.nu>
X-MH-In-Reply-To: Loa Andersson <loa@pi.nu> message dated "Wed, 05 Feb 2014 01:14:00 +0800."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <88426.1391551128.1@juniper.net>
Date: Tue, 04 Feb 2014 13:58:49 -0800
From: Yakov Rekhter <yakov@juniper.net>
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "mpls@ietf.org" <mpls@ietf.org>, "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" <draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org>, "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" <draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject: Re: [mpls] Way two progress two mldp draft with an technical overlap
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 04 Feb 2014 21:59:04 -0000

Loa,

> >> Yacov,
> >>
> >> I can't see that this flies! In fact it is counter to the wg chair
> >> proposal. We intended to keep the overlap as small as possible,
> >> specify a function in the document that needs the function. We did
> >> not intend to increase the overlap, but keep it as small as possible.
> >>
> >> You have this already neatly specified in draft-rekhter- let it stay
> >> there.
> >
> > I am fine with keeping the encoding and the procedures for the two
> > new mLDP TLVs: Transit IPv4 Shared Tree TLV, and Transit IPv6 Shared
> > Tree TLV in draft-rekhter-mpls-pim-sm-over-mldp.
> >
> > However, I have a question on the following:
> >
> >    2.  Assuming that the drafts are adopted, complete
> >    draft-wijnands-mpls-in-band-wildcard-encoding as the
> >    normative protocol specification of the piece within the
> >    overlap.
> >
> > What do you define as "the overlap" ?
> >
> > Yakov.
> 
> Yakov and Ice,
> 
> I'm sorry that I left the two draft hanging in a no mans land for
> such a long time, other than traveling, being busy with other working
> group issues, and having to do a couple of restarts there are no excuse.
> 
> Yakov,
> 
> It is my understanding that the overlap is summed up in the following
> text from draft-rekhter:
> 
>    "This document also identifies the deployment scenarios where BGP
>     Source Active auto-discovery routes will not be used."
> 
> More specifically, the overlap is the case where the service provider
> has provisioned the network in such a way that the RP for a particular
> group G is always between the receivers and the sources.  If the
> network is provisioned that way, the ingress PE for (S,G) is always
> the same as the ingress PE for the RP, so the SA A-D routes are never
> needed.
> 
> Draft-rekhter should be scoped to the case where the network is not
> known to be provisioned in this way.

Could you please propose the text that you'd like meto insert in
draft-rekhter ?

Yakov.