Re: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document

All,

	I am all for using BGP as a general purpose protocol. It is unfortunate that we have to have the same types of discussions every time a draft is introduced that uses BGP in a non-traditional manner. We need a top down view or better said a framework of the how BGP as a protocol should behave when being used for different applications ( I am tired of listening to myself say that!!! ). This draft addresses a valid problem space and IMO the IETF has allowed for many non-traditional applications to become WG drafts without the required specifications some of which Rob clearly lays out below.  Not sure how to proceed ? Comments In-Line..

Jim Uttaro

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rob Shakir
Sent: Thursday, August 09, 2012 6:09 AM
To: John Scudder
Cc: idr@ietf.org List
Subject: Re: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document

Hi Authors, IDR, Chairs,

Reviewing the slides that were sent to the list earlier, and based on comments that I have made numerous times during idr meetings I would like to raise a concern regarding this draft (and would therefore currently not support its adoption). Whilst I am supportive of the general concept that is presented, and see its utility, I think that there are general robustness and scaling concerns.

The current consideration of these issues in the draft seems relatively limited to "Frequency of Link-State NLRI updates could interfere with regular BGP prefix distribution." with a following comment on RR infrastructure - however, the deployment cases would seem to indicate that the device originating this information is not necessarily dedicated to the purpose (in networks with numerous areas, it is unlikely that deploying a dedicated device per area is commercially viable). It would seem to me that this means that the impact to the PE device must also be considered

[Jim U>] I had thought that the ABR would provide the needed information of each non-zero area. That being said, if we had to use our PEs that would not be a sunny day scenario, are there addl consideration in re PEs being in different AS domains aligned with different non-zero areas?

Whilst it is fine to say that the IGP damps some events when there are repeated flaps and this may limit the number of LS UPDATEs required, this seems to consider the 'happy' state of the network - if I have significant IGP instability that I cannot damp (look at link stability in some regions of the world for reference - there may not be a repeated single event, but rather a number of links displaying instability), or large network failures (e.g., a number of devices reloading) I would assert that the information that is being distributed by this mechanism is secondary to other tasks that the BGP process is doing. In these events, if it is not single "entries" that are being updated, then I do not think that an RFD-alike approach helps suppress the activity. 
[Jim U>] Agreed.. We would want to bring up critical services first.

This lack of control has a number of areas of concern for me:
	- We had a debate around the OPERATIONAL message as to whether this is "as important" as routing information. There was therefore some consideration as to how some of these mechanisms interact (or at least ensuring that there was the flexibility/guidance for implementations to protect itself). I think that this has the same discussion to be had - is an LS UPDATE as important as a IPv4/IPv6/VPNv4/VPNv6 UPDATE? (i.e., should this mechanism adversely affect convergence time for routing information, given that it is competing for the same network and computational resources - I would assert that it should not.)
	- If LS is a separate <AFI,SAFI> this is fine - but again, is it right to have fate-sharing between this information and routing information in terms of session liveliness? Whilst clearly the fact LS is carried in a separate <AFI,SAFI> would enable multi-session to segregate this information - but this is not noted as a prerequisite in the draft (and no standardised multi-session mechanism exists...).

[Jim U>] I would like to see protection for the BGP signaled services I.e L3VPN, L2VPN etc... as mentioned above this is the same concern for many other apps that are using BGP i.e RT Constrain, flowspec etc... 

Clearly, these are wider 'architectural' issues with carrying non-routing information within BGP - but since there is no framework for this form of information in BGP, then they need to be addressed on a case-by-case basis when considering individual drafts - hence my objection.
[Jim U>] This is the crux of the matter.. We need a framework for using BGP for these non-traditional applications.. How do we move the dial on this..I have tried but so far no luck.. 

Fundamentally, I don't think that the problem space highlighted does not exist, or that the solution is not the right one - just that it currently presents a stability concern to existing network deployments which may result in instability or failures, and I do not find this acceptable.

Kind regards,
r.

On 30 Jul 2012, at 21:58, "John G. Scudder" <jgs@juniper.net> wrote:

> Folks,
> 
> We have received a request from the authors to adopt draft-gredler-idr-ls-distribution as an IDR WG document. Please send your comments to the list.  The deadline for comments is August 14, 2012 at noon EDT.
> 
> Thanks,
> 
> --John
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr