Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt

[Jeff Wheeler <[e-mail]>]

On Mon, Dec 10, 2012 at 12:52 PM, Chris Hall <[e-mail]> wrote:
>> . MP_REACH
>> . MP_UNREACH
>
> If the sender is unchanged (which I recall you were keen on) how is it
> certain that either or both these attributes will precede the first
> broken one ?

Actually RFC4271 Pg24 says: "The sender of an UPDATE message SHOULD
order path attributes within the UPDATE message in ascending order of
attribute type.  The receiver of an UPDATE message MUST be prepared to
handle path attributes within UPDATE messages that are out of order."
The same text is also in RFC1771.

So the MP_UN?REACH_NLRI Attribute type codes are 14 and 15 which is
larger than most things like as_path, aggregator, and so on.

I have not tried to collect any data on what implementations are
actually doing.  I could collect some by packet dumping my BGP
sessions on an IXP in a few weeks when I have a chance to setup the
necessary equipment to make the dump.  It would be much more helpful
if someone who runs a large IXP route-server could do this analysis,
but if no such person volunteers and the data would be useful, I will
do some work on this around the holiday or in early-January.

On Mon, Dec 10, 2012 at 12:21 PM, Chris Hall <[e-mail]> wrote:
> I haven't considered IGNORE because the draft appears to vote against
> that pretty strongly.

I think maybe some folks haven't imagined the failure modes of IGNORE
vs WITHDRAW, and what is actually possible to do with WITHDRAW
depending on the nature of the malformation.  Really, the
inconsistencies created by IGNORE are not too bad.  You would hope
Acme Router Co won't ship that as the default configuration of their
products and that networks won't just turn that knob on a routine
basis without understanding it.  However, in a pinch, it will actually
do only minimal damage to unrelated prefixes.

Honestly, if Messages would not pack so much unrelated changes
together, IGNORE would be fantastic.  Simply separating nominal BGP
withdraws from updates would make IGNORE quite safe.  I think many
people would argue that discouraging, or disallowing, a mixture of
withdraws and updates in a single Message will be costly, but in fact
it won't be.  You wouldn't even need to discourage or forbid this
though, vendors could choose to provide a knob to avoid mixing
withdraws and updates together with no changes to the BGP
specification.  This would be ideal but it's hard to imagine customers
actually requesting it as a feature, because vendors spent some years
convincing customers that larger TCP MSS was going to improve converge
performance, etc.

Anyway, at least vendors have this choice if they wanted to do it.
There are some consequences relating to the frequency of Message
transmissions but I do not think anyone really obeys that text because
it is stupid.

> Well, that's an interesting idea :-)  If the only important thing to
> extract from a broken set of attributes is the NLRI, then why not scan
> for it and assume that there is sufficient redundancy to effectively
> rule out false positives.  Interesting :-)

I don't know what other way would be sensible.  The other attribute
information is not needed to effect a withdraw, only the NLRIs
themselves.

The troubling thing is that false positives could be created.  For
example, if you had a broken MP attribute toward the end of the
Message (and the RFC effectively recommends that it be put toward the
end, see above) then you can make a really big mistake and think that
some MP NLRI are native NLRI.  This means your Internet IPv4 RIB gets
withdraws from prefixes that happened to be updated or withdrawn in a
VRF within the same Message.  That is why I mentioned that BGP is
continually being extended to do new things that it is not good at.

So you can see, the false positive problem is worth thinking about
in-depth.  I am sure that's why the draft wants to move the MP
attribute to the beginning of the Message instead of the end.  It is a
smart idea if everyone would actually do it, but it isn't helpful if
the peer doesn't.

-- 
Jeff S Wheeler <[e-mail]>
Sr Network Operator  /  Innovative Network Concepts