[Idr] Does SRGB TLV in draft-ietf-idr-bgp-prefix-sid qualify for BGP Attibute discard?

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

Greetings: 

 

As IDR co-chair, I asked whether the discard attribute error handling (per RFC7606) for the BGP Prefix-SID attribute was appropriate.  This new mail list entry provides a place to comment on that point.  

 

Here’s the details: 

 

Section 3.2 paragraph starting with “The Originator SRGB TLV contains” states  



   The Originator SRGB TLV contains the SRGB of the node originating the

   prefix to which the BGP Prefix-SID is attached.  The Originator SRGB

   TLV MUST NOT be changed during the propagation of the BGP update.  It

   is used to build segment routing policies when different SRGBs are

   used in the fabric, for example

   ([I-D.ietf-spring-segment-routing-msdc <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-26#ref-I-D.ietf-spring-segment-routing-msdc> ]).

 

Does building segment routing policies were different SRGBs mean it changing policies regarding the SR segments installed?  Acee suggested these “routing policies” were hints on where labels were allocated for different SRGBs.  

 

To drill down further, I provided some comments below on the theories behind the error handling draft from my perspective and scenarios to consider.   I wished to unpack the “yes/no” answers into a constructive decision by the WG on the topic.  

 

As co-chair, I am fine with either an informed “yes/no” with details.   

 

Susan Hares  

 

 

Background on RFC7606 

------------------------------

The ARPANET’s original algorithm ran into a raise condition.  

 

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

 

This early ARPANET lesson causes us to learn that feedback loops (even hints) that readjust routing algorithms may 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].   

 

Anyone who suggests processing (such as SRGB TLV) that uses this information for routing/forwarding purposes needs to show why it is not going to cause problems. 

 

Scenarios to consider:

--------------------

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. 

 

 

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

 

On 6/26/2018 9:54 AM, Susan Hares wrote:



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


I am very familiar with this issue about feedback loops in the ARPAnet, but I don't understand what it has to do with the draft under discussion.








If you suggest that hints to the buffer algorithm do not cause fluctuations, then provide the discussion on the list that provides this proof.   


Are we still talking about the prefix-SID attribute draft?  It has nothing to do with buffer allocations.  Also, it has no feedback loops.

Or are you talking about the BGP-LS draft?  That draft just describes the distribution of information; if you're worried about feeback loops created by the use of that information, I think you need to go to the LSVR WG.  The BGP-LS stuff has nothing to do with the prefix-SID draft though.




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.  






Defining the admin boundary of an SR domain would be outside the scope of any BGP document.   

It would be nice if BGP had a simple way of restricting the distribution of attributes and/or communities and/or extended communities and/or large communities and/or super-duper communities to specified administrative domains.  Unfortunately, it doesn't.  But this is a long-standing problem that is generally dealt with on an ad hoc basis by policy.