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

["Chris Hall" <[e-mail]>]

On Sun, Dec 9, 2012 at 1:26 PM, Enke Chen <[e-mail]> wrote:
> Hi, Chris:
>
> As I replied before, the receiver knows from parsing the path
> attributes whether the MP_REACH_NLRI and/or MP_UNREACH_NLRI is
> the first attribute in an UPDATE message.  It does not need a
> new capability to make that determination.

Well, yes, there is no escaping the fact that... if the receiver can
see an MP_REACH_NLRI attribute and it is the first attribute, the
receiver can be pretty sure that the sender sent an MP_REACH_NLRI
attribute, and (what's more) they sent it first.

The capability, in this case, serves only to provide a warm feeling
that the sender is actually doing what they have committed themselves
to.

But that's not really the purpose of the capability...

...the difficulty/ambiguity I'm trying to get past is: what conclusion
can the receiver draw if they do *not* see an MP_REACH_NLRI attribute
anywhere, and the attributes are broken.  At present the receiver
cannot tell whether:

  a) the sender sent an MP_REACH_NLRI attribute which is
     buried under the debris of the broken attribute(s),

or:

  b) the sender did not send an MP_REACH_NLRI attribute
     at all at all.

The purpose of the capability is to allow the receiver to know that
the answer is (b), because the sender is promising to send
MP_REACH_NLRI and/or MP_UNREACH_NLRI before any other attribute(s),
and hence neither of those attributes can be obscured by some other
broken attribute.

[Well... I guess we have to consider the possibility that the sender
fails to live up to their promise -- in which case the answer could
still be (a) but the receiver would assume (b).  My feeling is that
this case is not worth worrying about...] 

Similarly MP_UNREACH_NLRI on its own, and in combination with
MP_REACH_NLRI.

Clearly, if an UPDATE contains only vanilla IPv4 Unicast in the body
of the message (ie, not in any NLRI attribute), then
"treat-as-withdraw" can be applied to all the NLRI no matter how
broken the attributes -- because the NLRI in the body of the message
are quite separate from the attributes.

Where the sender always sends any NLRI attributes as the first
attributes, they are effectively separated from the rest of the
attributes.  However, the receiver has to *know* that is what the
sender will do in order to take advantage of it -- since, otherwise,
the sender is allowed to send attributes in any order.

That's where the capability comes in.

Chris