Re: [Idr] Alvaro's AD Comments on draft-ietf-idr-ls-distribution

[Jeffrey Haas <[e-mail]>]

Adrian,

On Sun, Oct 04, 2015 at 09:57:17PM +0100, Adrian Farrel wrote:
> > > Why 200? Not sure where that came from. I have no evidence that 200
> > > is a problem and given that IDR has done quite a bit of implementation
> > > and interop without anyone screaming, I assume this is OK.
> > >https://www.ietf.org/id/draft-ietf-idr-ls-distribution-impl-04.txt doesn't
> > >mention any problems. Are you aware of implementations where this is a
> > >problem?
> > 
> > No, but implementation and interop (most likely in a controlled
> > environment) is very different than operation in the wild.  But I am sure
> > that you (and everyone else listed as an author) obviously knows that.
> 
> I think it is tremendously difficult to work out / predict what a reasonable
> default value is for operation in  real network. I'd be happy to not give any
> guidance because of that, but history says that if we don't suggest a default we
> will be caned by the IESG. You can't win :-)
> 
> We have picked a value we believe will not be a problem. But it is art not
> science.

It is very much art rather than science.  The properties we are looking for
include:
- Distribute LS changes "fast enough"
- Don't propagate thrash; i.e. don't be too fast for some stuff.
- Remember that the cost in BGP is often borne by the receiver rather than
  the sender.

Constants will almost always be wrong at some point in time, so best we can
suggest is an initial value that will eventually be ignored by posterity.

> > >> 6.2.2 (Fault Management). "If an implementation of BGP-LS detects a
> > >> malformed attribute, then it SHOULD use the 'Attribute Discard' action.."
> > >> Doesn't this mean that the information may be useless, completely missing,
> > >> or in the best case incomplete?  Aren't we better off just resetting the
> > >> session or at least requesting a route refresh?
> > >
> > > I don't think we are assuming corruption. So the malformed attribute
> > > comes as the result of an implementation difference or a bug at the
> > > sender.
> > 
> > That would still result in the receiver not having the information.  The
> > cause doesn¹t seem to matter in this case, the end result does.
> 
> Absolutely.
> So you have to choose between having most of the info from the network minus
> some pieces that you couldn't parse, or resetting the session and having no
> information about the network.
> Perhaps we should be "raising an alert to the operator" when this happens? (rate
> limits may apply)

Resetting the session is almost always the wrong thing to do.  Thankfully
the desired behaviors, including operational, are already covered in RFC 7606:

:   Because of these potential issues, a BGP speaker must provide
:   debugging facilities to permit issues caused by a malformed attribute
:   to be diagnosed.  At a minimum, such facilities must include logging
:   an error listing the NLRI involved and containing the entire
:   malformed UPDATE message when such an attribute is detected.  The
:   malformed UPDATE message should be analyzed, and the root cause
:   should be investigated.

> > I was mostly wondering if the information is anywhere close to 4k or not.
> > The implementation report doesn¹t say anything either. :-(
> 
> OK. I see your point. The problem presumably exists for the IGPs as well (maybe
> more for OSPF than for ISIS).
> 
> Anyone in the DR WG want to do the math?

Not particularly.  I think this is a case where we'd really want the IGP
experts to give us ideas of max message sizes and then we'd double-check
BGP-LS.

That said, draft-ietf-idr-bgp-extended-messages is intended to help with
these sorts of situations.  (Although that's not broadly implemented yet.)

-- Jeff