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

Jeffrey Haas <> Mon, 05 October 2015 19:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 305B41B4B69 for <>; Mon, 5 Oct 2015 12:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.578
X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n8VJnLq99q6R for <>; Mon, 5 Oct 2015 12:30:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6BAC41B42C5 for <>; Mon, 5 Oct 2015 12:30:51 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 712ED1E4DC; Mon, 5 Oct 2015 15:34:45 -0400 (EDT)
Date: Mon, 5 Oct 2015 15:34:45 -0400
From: Jeffrey Haas <>
To: Adrian Farrel <>
Message-ID: <>
References: <022901d0fdc9$0ea4ce80$2bee6b80$> <> <02bd01d0fee7$5678c440$036a4cc0$>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <02bd01d0fee7$5678c440$036a4cc0$>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Idr] Alvaro's AD Comments on draft-ietf-idr-ls-distribution
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Oct 2015 19:30:53 -0000


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

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