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

From: "John G. Scudder" <[email-masked]>
Date: Tue, 28 Aug 2012 12:45:02 -0400

Chris Hall has been having problems getting mail through to the list so he asked me to forward the below. I've set Reply-To accordingly (though I'm not sure it'll make it through the list software).

--John

From: Chris Hall <[email-masked]>
Subject: re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt
Date: August 22, 2012 9:35:07 AM EDT
To: "[email-masked]" <[email-masked]>

I have been working on Quagga bgpd with this draft in mind, but I am
stuck.

The Quagga code scans the attributes and checks that they are
correctly "framed":

 1) the sum of the attribute lengths is the same as the
    Total Path Attributes Length

 2) each Attribute Flags octet is valid for the type

 3) each Attribute Length is valid for the type

 4) no Attribute type is repeated

There isn't much redundancy in the "lexical" structure of the
attributes, but this exploits the extra "semantic" information to
reduce the odds of accepting a broken set of attributes.

If there is then some problem with the contents of some attribute,
then one can pick out any (valid) MP_REACH and MP_UNREACH and
"treat-as-withdraw".

So far so good.  But what if the attributes are not correctly "framed"
?  I believe the "RIPE NCC and Duke University BGP Experiment"
triggered such a problem.

If I can see MP_REACH and/or MP_UNREACH "upstream" of the first
"framing" problem, then I can "treat-as-withdraw".  If those are the
first attributes, as recommended, then if they are present, then
that's straightforward.

My problem is: if I cannot see an MP_REACH or MP_UNREACH, how do I
know whether that's because there isn't one, or because the "framing"
problem has rendered it invisible ?

It would help if there was a Capability -- "will send MP_REACH and/or
MP_UNREACH as the first attributes, in that order".  Now, if those are
properly framed, we know what's going on.  If the first attribute
following those attributes is properly framed, we have more
confidence.

Failing that, all I can think of is various "you know and I know"
heuristics to guess whether it is safe to "treat-as-withdraw".  Or,
only apply "treat-as-withdraw" if the attributes are correctly framed,
but not otherwise -- which seems to exclude an important case.  I'm
stuck.

Seems to me, that an UPDATEv2 message type would help here -- by
making the validity/presence of NLRI quite separate from the mish-mash
of Attributes.  (It could also imply AS4, but that's another story).
Sorting MP_REACH/MP_UNREACH to the front of the attributes is almost
equivalent, but an UPDATEv2 would be more direct.

I note that the draft invalidates tests (2) and (4) above.  I think
this is a retrograde step: removing some useful redundancy.

Chris