Re: [Idr] Alia's AD review of draft-ietf-idr-ls-distribution-10

Robert Raszuk <robert@raszuk.net> Thu, 01 October 2015 15:53 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C28E1B2D7B; Thu, 1 Oct 2015 08:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 rsDsT_tAWTXY; Thu, 1 Oct 2015 08:53:08 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22191B2D95; Thu, 1 Oct 2015 08:53:07 -0700 (PDT)
Received: by wiclk2 with SMTP id lk2so35071400wic.1; Thu, 01 Oct 2015 08:53:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Lf/VoJgPJ7/GO6pfS5mAyQtzlA7IULW/VpjHX5kyMHM=; b=vkGRXXTzmwdMjDItbLDKQ6+OF7PHlQoVqy3I/QIIvrKU79PaoLPYFLAXoCh83DVqis iOu7XEvpidnjB6KXMz19PGr+YoTqZguC3B8OHdxkxxLv41MfVfm9X9l8xDUU0KAaIweJ GUKDszeteLbraWQz0aFS76KtDX7kJU8MC2l/to3Jx50XM9L2UlISDyqyQehT9zAWQFPa 2hv9bFt82WrY7thiOdgO/cCIIk6/u+kGSgiU5bz0jA4gxvbnAerrfE9hSkPD4ATQSSWf 0h+Z3oXxAtYP0lauBsfyrluElsMkm5BAIaqto1999FksC6rqw7uygU073xik2u3GXRMB 9ujA==
MIME-Version: 1.0
X-Received: by 10.194.246.161 with SMTP id xx1mr11270107wjc.26.1443714786395; Thu, 01 Oct 2015 08:53:06 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.194.114.199 with HTTP; Thu, 1 Oct 2015 08:53:06 -0700 (PDT)
In-Reply-To: <00b901d0fc5f$65446c20$2fcd4460$@olddog.co.uk>
References: <03e701d0faff$b9e484b0$2dad8e10$@olddog.co.uk> <CAG4d1rfoqnfq89rByefqXfCVBc1Sx6iW0Fx-87F4me-q291OCw@mail.gmail.com> <01f701d0fba7$5a00daa0$0e028fe0$@ndzh.com> <00b901d0fc5f$65446c20$2fcd4460$@olddog.co.uk>
Date: Thu, 01 Oct 2015 17:53:06 +0200
X-Google-Sender-Auth: 6tGFKnUOrox6ahqFUg36Y9czsEw
Message-ID: <CA+b+ERnRWXU95cJsJ_moHJzrN7T=SFNLO3CDNN=_NQtMR7Q04Q@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: Adrian Farrel <adrian@olddog.co.uk>
Content-Type: multipart/alternative; boundary="089e016818280013a405210d0b2f"
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/bbUtwwqiJtkj8Wxxvz5e9TgR9yY>
Cc: "idr@ietf. org" <idr@ietf.org>, draft-ietf-idr-ls-distribution@ietf.org, Alia Atlas <akatlas@juniper.net>, Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] Alia's AD review of draft-ietf-idr-ls-distribution-10
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2015 15:53:10 -0000

Adrian,

If you read section 3.2 you realize that BGP-LS uses a new SAFI (71)
therefor most of your questions automatically get's addressed.

Moreover if you go down the same section 3.2 you find out that defined new
SAFI also mandates new BGP capability hence there is no issue on receiving
side either.

As far as "stretching" one may say L3VPN with SAFI 128 can can stretch SAFI
1 speaking BGP router .. however this is up to the deployment model.

Likely and that is what I have heard authors advocating is to use separate
virtual or physical overlay for distributing BGP-LS hence if operator's
endorse this model practically it would have no impact with any other BGP
SAFIs what so ever.

Cheers,
Robert.




On Thu, Oct 1, 2015 at 5:39 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hello,
>
> > One procedural and one technical question.  Did you intend a date of
> June 4, 2015?  If so, why?
>
> Not sure to what you are referring. Perhaps you're pointing at the most
> recently posted revision? If so, that was Hannes on, erm, 4th June.
>
> I have only sent email so far and not posted an update. i still need to
> work through Alvaro's review before I can do that. May be a few more days,
> but hopeful before the next 4th June.
>
> > Technical:  Do you believe that sections 6.1.1 and sections 6.1.5 are
> sufficient to describe
> > what happens if the extra NLRI do not get sent the private
> infrastructure of route-reflectors
> > Sections include below from -11.
>
> Actually, my level of anticipation is different from other authors :-)
> I don't see why this is necessarily a RR function. Any BGP speaker with
> access to the network topology (e.g., an ASBR) and with suitable policy
> configured, could export as BGP-LS.
> The challenges are:
> - How does the exporter know on which sessions to do BGP-LS and which not?
>   I think an RR has the same problem.
> - How does a receiver distinguish between normal BGP data and BGP-LS data?
>   Possibly it should not be receiving both, but if it does, it can look at
> the NLRI.
> - Will BGP-LS over-stretch a BGP-speaking router?
>   Possibly (in which case use an RR) and possibly not. Depends on
> implementation.
> - Will BGP-LS updates swamp other BGP updates?
>   Just like IGP-TE updates, this is all about thresholds and policy. IMHO,
> an
>   implementation should provide knobs for this and an operator should
> choose
>   whether to offload to an RR.
>
> Probably could add some scribbles about this.
>
> Adrian
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>