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

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

Ketan:

 

This is one reasonable answer.   I suggest the documents provide these answers to non-conflicts in order provide interoperable specifications.   

 

Sue Hares 

 

From: Ketan Talaulikar (ketant) [mailto:[e-mail]] 
Sent: Tuesday, June 26, 2018 12:50 PM
To: Susan Hares; 'Eric C Rosen'; 'Robert Raszuk'
Cc: 'idr@ietf. org'; Acee Lindem (acee)
Subject: RE: [Idr] BGP-LS and the like ...

 

Hi Sue,

 

If the application building the SR policies is receiving the topology feed via BGP-LS (which includes the SRGB), then the BGP Prefix SID draft does say that the SRGB learnt via BGP-LS is preferred. If the application also receives a conflicting value of SRGB from BGP via the SRGB TLV in the Prefix SID Attribute then this could be logged as an error but I am not sure we want to discard the entire BGP Prefix SID attribute in this case. The use-case for SRGB TLV is for this TE purpose where there might be a conflict (resolved via the preference indicated), but there is no such conflict for BGP-LU operations while using the Label Index TLV.

 

Thanks,

Ketan

 

From: Susan Hares <[e-mail]> 
Sent: 26 June 2018 21:58
To: 'Eric C Rosen' <[e-mail]>; Ketan Talaulikar (ketant) <[e-mail]>; 'Robert Raszuk' <[e-mail]>
Cc: 'idr@ietf. org' <[e-mail]>
Subject: RE: [Idr] BGP-LS and the like ...

 

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.