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

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 1 Oct 2015 16:39:43 +0100

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 1 Oct 2015 17:53:06 +0200

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 <[email-masked]> wrote:

> 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.
>
> 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:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 1 Oct 2015 12:05:04 -0400

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:[email-masked]] On Behalf Of Adrian Farrel
Sent: Thursday, October 01, 2015 11:40 AM
To: 'Susan Hares'; 'Alia Atlas'
Cc: 'idr@ietf. org'; [email-masked]; 'Alia Atlas'
Subject: Re: [Idr] Alia's AD review of draft-ietf-idr-ls-distribution-10

Hello,

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
>The challenges are:
> How does the exporter know on which sessions to do BGP-LS and which not?

I agree with you that RR does not change the problem. 

> How does a receiver distinguish between normal BGP data and BGP-LS data?

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. 

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

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