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

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

Eric:

 

The context was whether SRGB TLV in BGP PREFIX-SID qualified for the attribute discard (per RFC7606) error handling.

 

I’m open to either “yes” or “no” to this question - as long as the answer comes a discussion regarding the impact of label stack availability on TE algorithms or segment routing policies used to build segment routes in a network.   See the statements from bgp-prefix-sid below. 

 

I started a new thread on this topic that you are welcome to join. 

 

Sue Hares 

 

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

See statements by draft-ietf-idr-bgp-prefix-sid-26:

 

      If a prefix segment is to be included in an MPLS label stack,

      e.g., for traffic engineering purposes, the knowledge of the SRGB

      of the originator of the prefix is required in order to compute

      the local label used by the originator.

 

Section 3.2 





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

 

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.