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

From: "Susan Hares" <[email-masked]>
Date: Tue, 26 Jun 2018 12:14:31 -0400

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:[email-masked]] 
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.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 26 Jun 2018 18:24:21 +0200

Hi Sue,

I think there must be some disconnect and I think Eric was trying to
already point this out.

You say: "instantaneous sample rather than an average" - very true but this
have nothing to do with SRGBs analogy. SRGBs are static, very very static
values. We are simply pushing configuration by BGP here. At least on most
platforms those blocks are or can be configured by CLI once for good.

Cheers,
R.

On Tue, Jun 26, 2018 at 6:14 PM, Susan Hares <[email-masked]> wrote:

> 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:
>
>
>
>    ([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.
>
>
>
> 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).
>
>
>
> 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.
>
>
>
> 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:
>
>
>
> *From:* Eric C Rosen [mailto:[email-masked]]
> *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 ...
>
>
>
> 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.
>
>
>
>
> 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.
>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 26 Jun 2018 12:58:10 -0400

Robert: 

One may push these SRGB very rapidly given modern BGP processing and centralized processors.  What limits the rate of push? 

You have provided one answer for the question:  

“SRGB TLV impacts the routing/SR routing, but it is defined to be at the static configuration rate with a maximum rate (x per minute). Therefore, it qualifies for the BGP attribute discard.”

With this answer, the manageability section needs to indicate the rate of change as one of its assumptions. 

Thanks for the response, 

Susan Hares 

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

Hi Sue,

I think there must be some disconnect and I think Eric was trying to already point this out. 

You say: "instantaneous sample rather than an average" - very true but this have nothing to do with SRGBs analogy. SRGBs are static, very very static values. We are simply pushing configuration by BGP here. At least on most platforms those blocks are or can be configured by CLI once for good.

Cheers,

R.

 

 

Greetings: 

Here’s the details: 

Susan Hares  

Background on RFC7606 

Scenarios to consider:

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

 

Eric:

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 26 Jun 2018 13:16:50 -0400

On 6/26/2018 12:14 PM, Susan Hares wrote:
> 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.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 26 Jun 2018 14:40:16 -0400

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:[email-masked]] 
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?

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. 

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.

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 26 Jun 2018 15:07:02 -0400

On 6/26/2018 2:40 PM, Susan Hares wrote:
> 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). 

I'll leave that to the authors, but I think this falls under the 
category of "some familiarity with the normative references is presupposed".

> “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.”
>

I think I already explained why attribute-discard is a more appropriate 
policy than treat-as-withdraw for a malformed prefix-SID attribute.

Most BGP attributes have some effect on routing, the question is whether 
discarding a malformed attribute will result in inconsistent routing 
(loops).

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 26 Jun 2018 15:17:22 -0400

Eric: 

See inline responses. 

Sue 

From: Eric C Rosen [mailto:[email-masked]] 
Sent: Tuesday, June 26, 2018 3:07 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?

I'll leave that to the authors, but I think this falls under the category of "some familiarity with the normative references is presupposed".

[AFAIK, the normative references do not provide adequate information on the manageability and expectations on the timing for the BGP Peer segments. ] 

I think I already explained why attribute-discard is a more appropriate policy than treat-as-withdraw for a malformed prefix-SID attribute.  

[Sue]: The reason we are discussing attribute-discard on this separate thread is because I agree that it is more appropriate that treat-as-withdraw for the malformed prefix-SID attribute.  I would have made comments in 2015 if I thought it was the wrong approach. 

Most BGP attributes have some effect on routing, the question is whether discarding a malformed attribute will result in inconsistent routing (loops).

[Sue] Yes – this is the question I am trying to discuss.  I’ve provided scenarios where it might fail.

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 26 Jun 2018 15:39:19 -0400

On 6/26/2018 3:17 PM, Susan Hares wrote:
> AFAIK, the normative references do not provide adequate information on 
> the manageability and expectations on the timing for the BGP Peer 
> segments.

I think the normative references  make it clear that SIDs and SRGBs are 
not dynamically changing values.

> Most BGP attributes have some effect on routing, the question is 
> whether discarding a malformed attribute will result in inconsistent 
> routing (loops).

> provided scenarios where it might fail.

If you can provide a clear description of a scenario that results in 
inconsistent routing, that would be interesting.  However, I don't think 
you've described such a scenario yet (or I missed it somehow).

The real danger with all this traffic engineering stuff is not that an 
UPDATE might be malformed, but that it might be properly formed but have 
incorrect values.  But that's the nature of traffic engineering.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 29 Jun 2018 11:24:46 -0400

Eric: 

I think we are approaching a convergence on the need for a clear problem description and that a UPDATE that is not MALFORMED will cause problems. The restriction for attribute discard restriction on routing considered that issue. 

I will write-up a problem description for the SID and SRGBs and send it to the list.  This write-up will probably come on Tuesday (after the IETF deadline) due to my “day job” work.  

Thank you for your questions.

Susan Hares 

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

AFAIK, the normative references do not provide adequate information on the manageability and expectations on the timing for the BGP Peer segments.

I think the normative references  make it clear that SIDs and SRGBs are not dynamically changing values.

If you can provide a clear description of a scenario that results in inconsistent routing, that would be interesting.  However, I don't think you've described such a scenario yet (or I missed it somehow).  

The real danger with all this traffic engineering stuff is not that an UPDATE might be malformed, but that it might be properly formed but have incorrect values.  But that's the nature of traffic engineering.