Re: [Idr] BGP-LS and the like ...

["Susan Hares" <[e-mail]>]

Eric: 

 

On your questions for #1,  The ARPANET’s original algorithm 

 

Used a “link metric, which was an instantaneous sample rather than an average, was a poor indicator of expected delay on a link as the quantity being sampled fluctuated fairly rapidly at all traffic levels.”  This is a quote from the reference academic paper link below (circa 1989).  

 

http://www2.cs.arizona.edu/classes/cs525/fall14/papers/ak89.pdf

 

I can send you links additional modern papers on the predictive algorithms that still consider this problem if  you wish.  

 

This early ARPANET lesson causes us to learn that feedback loops (even hints) that readjust the algorithms can cause fluctuations.  Does this apply to all algorithms?  No,  but this common wisdom is one of the reason the BGP error handling calls out the following  text in section 2. 

 

   o  Attribute discard: In this approach, the malformed attribute MUST

      be discarded and the UPDATE message continues to be processed.

      This approach MUST NOT be used except in the case of an attribute

      that has no effect on route selection or installation.

 

Other reasons can be algorithms specific to BGP (see RFC 7964, RFC3345].   If you suggest something that borders on this point, the burden of proof is on the inventors of the protocol and algorithm to show it is not going to cause problems. 

 

If you suggest that hints to the buffer algorithm do not cause fluctuations, then provide the discussion on the list that provides this proof.   There are two cases to consider:  normal buffer growth/reduction and edge cases that caused by errors in the central process.  The error scenarios to check that I can think of are: 

 

1)      Critical nodes that receive alternating hints for large/small, 

2)      Massive large hints for all nodes

On #2, the AS boundary for AS confederations or AS policies have known solutions for existing problems. 

 

You are arguing for is a new technology – segment routing enabled by BGP technology with the capability to have BGP peer topology as part of the segment routing.  A group of drafts defining this new technology should provide a cogent definition for the administrative boundary of segment routing in either the segment routing drafts.  This SR domain boundary should be detectable by management process.  

 

A positive solution would be to provide: a) a definition boundary one of the BGP drafts (or a segment routing drafts) and b) a Yang model that will provide the detection of the boundary.  

 

On, the 2015 prefix-sid mail – I will send a summary to the list. 

 

Sue Hares 

 

From: Eric C Rosen [mailto:[e-mail]] 
Sent: Monday, June 25, 2018 2:12 PM
To: Susan Hares; 'Ketan Talaulikar (ketant)'; 'Robert Raszuk'
Cc: 'idr@ietf. org'
Subject: Re: [Idr] BGP-LS and the like ...

 

On 6/25/2018 11:17 AM, Susan Hares wrote:



[Sue]: 

1st - If you provide a “hint”, then we get into a recursive problem of the hint accelerating the solution the controller provides.  See the earliest ARPANET where the hints of performance causes the solution to grow dramatically without bounds in an algorithm.   If it is suggesting how many local labels it is allocating, it is suggesting something that may impact. 


I don't understand this objection.    Typically, when a node receives a SAFI-4 update, and has to propagate that update on an EBGP session, it changes the label value and the next hop value before propagation.  The "hint" tells you what to change the label value to.  Without the hint, you make a local choice of what to change the label value to.  There is nothing here that is "growing without bounds" or causing a "recursive" problem.

Also, I don't understand what ARPANET phenomenon is being referenced ;-)




 

2nd - If you use a transitive BGP Prefix SID Attribute, then you are not within a single AS.   You cannot use the AS boundary to guarantee the administrative SR domain.   If the configured SR Domain ID is someplace (configuration, etc), then how do we check it to determine SR domain boundares. 

 


The problem here is that the notion of "AS boundary" as "administrative boundary" has long been obsolete.  The attribute under discussion is just one of a whole set of attributes that could benefit from a general "attribute scoping" solution, assuming someone could figure out a solution that is general enough to make sense and not too costly to deploy.  You can't expect this particular draft to address that problem.