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

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> 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:
>
>
>
> 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.
>