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

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

Eric: 

 

If these facts regarding the non-dynamic nature of the changes, then indicate this in the draft-ietf-idr-bgp-prefix-sid draft (or another SR draft and point to it). 

 

With I2RS changes and the latest NETCONF/YANG NMDA changes, configuration changes can occur very quickly. 

 

On the interaction with routing, you are indicating a routing interaction:  

 

“If you do discard-attribute, the prefix is still reachable via the ordinary non-traffic-engineered routing; this does not cause any loops or oscillations, as the ordinary routing is not impacted.” 

 

You are discussing changes that fluctuate SR routing and ordinary routing. 

 

 

Sue Hares 

 

From: Eric C Rosen [mailto:[e-mail]] 
Sent: Tuesday, June 26, 2018 1:17 PM
To: Susan Hares; 'Ketan Talaulikar (ketant)'; 'Robert Raszuk'
Cc: 'idr@ietf. org'
Subject: Re: Does SRGB TLV in draft-ietf-idr-bgp-prefix-sid qualify for BGP Attibute discard?

 

On 6/26/2018 12:14 PM, Susan Hares wrote:



Does building segment routing policies were different SRGBs mean it changing policies regarding the SR segments installed?  


If you don't know the appropriate set of SIDs and SRGBs, then you can't make use of certain policies, and you have to use the "ordinary" (non-traffic-engineered) routing.  

But there is no feedback loop at all.  SIDs and SRGBs do not change dynamically.  And if they do change (due to configuration/provisioning changes), they don't cause changes in the sets of policies that are deployed or in the ordinary routing.




Acee suggested these “routing policies” were hints on where labels were allocated for different SRGBs. 


I don't think Acee said anything like that.  




As IDR co-chair, I asked whether the discard attribute error handling (per RFC7606) for the BGP Prefix-SID attribute was appropriate.


Whether you do treat-as-withdraw or discard-attribute, a malformed prefix-SID attribute is likely to prevent you from using a particular policy.  If you do discard-attribute, the prefix is still reachable via the ordinary non-traffic-engineered routing; this does not cause any loops or oscillations, as the ordinary routing is not impacted.  If you do treat-as-withdraw, the prefix is not going to be reachable at all.  So this seems like a clear case where discard-attribute is the preferred error handling procedure for a malformed attribute.