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

"Susan Hares" <shares@ndzh.com> Thu, 01 October 2015 16:05 UTC

Return-Path: <shares@ndzh.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 291131B2DB6; Thu, 1 Oct 2015 09:05:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.055
X-Spam-Level:
X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 xOe50DgfaSfk; Thu, 1 Oct 2015 09:05:12 -0700 (PDT)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66001B2DB4; Thu, 1 Oct 2015 09:05:09 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.33.104;
From: "Susan Hares" <shares@ndzh.com>
To: <adrian@olddog.co.uk>, "'Alia Atlas'" <akatlas@gmail.com>
References: <03e701d0faff$b9e484b0$2dad8e10$@olddog.co.uk> <CAG4d1rfoqnfq89rByefqXfCVBc1Sx6iW0Fx-87F4me-q291OCw@mail.gmail.com> <01f701d0fba7$5a00daa0$0e028fe0$@ndzh.com> <00b901d0fc5f$65446c20$2fcd4460$@olddog.co.uk>
In-Reply-To: <00b901d0fc5f$65446c20$2fcd4460$@olddog.co.uk>
Date: Thu, 1 Oct 2015 12:05:04 -0400
Message-ID: <00a001d0fc62$ef739b70$ce5ad250$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHbkGdHgyRBPdUUhxGhvIgGVZTRygJ2OsBFAdbTCdIBt2jUKZ4Re5fg
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/jdkU0sXtl72q1DoG7aQxYJyh5dQ>
Cc: "'idr@ietf. org'" <idr@ietf.org>, draft-ietf-idr-ls-distribution@ietf.org, 'Alia Atlas' <akatlas@juniper.net>
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 16:05:13 -0000

Adrian: 

Yes -  I was confused about your message and
draft-ietf-idr-ls-distribution-11.  It is my error.  

Sue 

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Thursday, October 01, 2015 11:40 AM
To: 'Susan Hares'; 'Alia Atlas'
Cc: 'idr@ietf. org'; draft-ietf-idr-ls-distribution@ietf.org; 'Alia Atlas'
Subject: Re: [Idr] Alia's AD review of draft-ietf-idr-ls-distribution-10

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.

I agree with you that RR does not change the 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.

Stating that the distinguishing is based on the NLRI indicates the NLRI must
be reviewed.
If you have both types of NLRI, you are looking at AFI/SAFI or NRLI
filtering.  This should be stated. 

>- Will BGP-LS over-stretch a BGP-speaking router?
> Possibly (in which case use an RR) and possibly not. Depends on
implementation.

What happens when it over stretches and how do you detect it. 
Is there any guidance for the operations people?  If so, please state it. 

>- 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.

In the end, this is my point. Describe the knobs that need to be there for
overload and detection. 

Best wishes, 
Sue 
______________________________________________