Subject: [Idr] Fwd: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

From: Rob Shakir <[email-masked]>
Date: Thu, 27 Dec 2012 18:44:28 +0000

Hi IDR!

FYI -- please find an updated relating to a new version of draft-ietf-grow-ops-reqs-for-bgp-error-handling.

Any comments very welcome (to me or grow@).

Seasons greetings!
r.

Begin forwarded message:

> From: <[email-masked]>
> Subject: Re: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt
> Date: 27 December 2012 18:41:50 GMT
> To: <[email-masked]>, <[email-masked]>
> Cc: [email-masked]
> 
> On 27/12/2012 18:35, "[email-masked]" <[email-masked]>
> wrote:
> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Global Routing Operations Working Group
>> of the IETF.
>> 
>> 	Title           : Operational Requirements for Enhanced Error Handling
>> Behaviour in BGP-4
>> 	Author(s)       : Rob Shakir
>> 	Filename        : draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt
>> 	Pages           : 19
>> 	Date            : 2012-12-27
> 
> Hi GROW!
> 
> This update is a fairly major re-spin of the BGP Error Handling
> requirements draft. The technical content should be as per the previous
> revisions however, following the ietf/RtgDir last call comments, I have
> made the following changes:
> 
> * Made the amendments that were discussed and there was no disagreement
> with from our meeting in Atlanta -- this is essentially renaming the
> Critical/Semantic error types to Critical/Non-Critical.
> 
> * Significant de-duplication within the text including merging the
> operational monitoring/toolset discussions into the error handling
> sections.
> 
> * Adoption of rfc2119 language throughout to clarify the requirements.
> 
> * Removal of some of the discussion around more detailed justifications
> for why particular decisions were made. I think this was useful through
> the discussion phase of this draft, but it seems like GROW/IDR have
> converged on a relatively stable set of requirements, so I have trimmed
> back some of this discussion.
> 
> I'd really welcome any further comments on this before we re-submit for
> publication. To eke these out - Peter/Chris - can you kick off a WGLC for
> this draft please? :-)
> 
> Seasons greetings!
> r.
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: "Chris Hall" <[email-masked]>
Date: Sat, 29 Dec 2012 11:09:03 -0000

Jakob Heitz wrote (on Fri 28-Dec-2012 at 21:35 +0000):
....
> All we can hope for after a malformed update is a
> temporary mitigation until human intervention can
> fix the problem.
>
> IMO, the goal of error handling is to limit the
> damage, not to cure the problem.

>From previous discussions it appears that to "limit the damage" you
would avoid session-reset at all costs.  Yes ?

Seems to me the goal of "Enhanced Error Handling" is, simply, to be
"not as bad as session-reset".

Where all NLRI in a message can be identified, treat-as-withdraw seems
to me to be not as bad as session-reset.

But: "Once you have a malformed update, NOTHING is certain."  So,
there is some risk of "lost NLRI" when tolerating (not resetting the
session) malformed updates.

I don't know if "lost NLRI" can cause problems which are worse than
session-reset.  I cannot find anything in
draft-ietf-grow-ops-reqs-for-bgp-error-handling-06 or
draft-ietf-idr-error-handling-03 which addresses the issue.  (Though
draft-ietf-idr-error-handling-03 waxes lyrical on "Why not discard
UPDATE messages ?")  

If the strategy is to treat-as-withdraw where you can, and continue
with whatever "lost NLRI" there may be, then that's simple enough.
But if that is the strategy, why do the drafts not say so ?  The
"ops-reqs" draft sets out to define Critical and Non-Critical errors
in terms of the inability/ability to extract NLRI, which is not
obviously consistent with this strategy.

It may be that "lost NLRI" are, indeed, potentially (in theory) worse
than session-reset, but that the risk is (in practice) reduced to a
tolerable level if a certain amount of care is taken to extract NLRI
-- falling back to session-reset if that process fails.  This seems to
me to be quite a sophisticated position -- too sophisticated to be
simply implied by what the drafts do not specify.

On the other hand, if "lost NLRI" are not as bad as session-reset,
then:

  a) when parsing the NLRI themselves, why not treat-as-
     withdraw everything up to the point where a prefix
     length overruns the NLRI collection ?

  b) when parsing MP_XXX attributes, why worry about
     duplicates ?  Why not treat-as-withdraw everything
     in sight ?

  c) when parsing the message layer, why worry about
     consistency of message length and withdrawn
     routes and attributes length ?

     Since "lost NLRI" are tolerable, why worry about
     losing some IPv4 Unicast NLRI ?

  d) the presence of 16 x 0xFF is surely sufficient
     to signal the start of a BGP Message.  So, when
     starting to read a message (after having read
     message length octets for the previous one),
     why not scan forwards looking for 16 x 0xFF ?

I suspect the drafts do not go this far because there are unspoken
assumptions about what is worse than session-reset; either that, or
because the issue of "lost NLRI" has been glossed over.  Neither of
which, I suggest, are very satisfactory.

Chris