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

Vitkovský Adam <adam.vitkovsky@swan.sk> Tue, 17 June 2014 14:11 UTC

Return-Path: <adam.vitkovsky@swan.sk>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6901A0037 for <idr@ietfa.amsl.com>; Tue, 17 Jun 2014 07:11:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.347
X-Spam-Level:
X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdxqyHaLnDxi for <idr@ietfa.amsl.com>; Tue, 17 Jun 2014 07:11:11 -0700 (PDT)
Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BABB71A0117 for <idr@ietf.org>; Tue, 17 Jun 2014 07:11:10 -0700 (PDT)
From: Vitkovský Adam <adam.vitkovsky@swan.sk>
To: Jeffrey Haas <jhaas@pfrc.org>, Chris Hall <chris.hall@highwayman.com>
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-13.txt
Thread-Index: AQHPhzXdONcTVw9o/kqbHkQkJIcDk5tvPmsAgAAJYoCAAUbJAIADaEuAgAFhyaA=
Date: Tue, 17 Jun 2014 14:11:04 +0000
Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B019C5BA6@EX01.swan.local>
References: <20140613183222.27662.91400.idtracker@ietfa.amsl.com> <48D0139F-CD0E-474C-A557-E18E6100157A@juniper.net> <CA+b+ERny4PxsQxhvwE6XOtuStzbD9WmwO9TpUdmKFJ0bHhGVjw@mail.gmail.com> <009f01cf87df$48630760$d9291620$@highwayman.com> <20140616184725.GB31387@pfrc>
In-Reply-To: <20140616184725.GB31387@pfrc>
Accept-Language: sk-SK, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.40.93]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/idr/TfaSn1r7OGstYxlzIXKTzbUePNI
Cc: "'idr@ietf. org'" <idr@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-13.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jun 2014 14:11:12 -0000

I think we should leave the semantics out of it and Jeff I really like your sentence: 

> It may thus be worthwhile simplifying the section:
> "If the next hop field contains a semantically incorrect address within the
> context of deployed features and address family, treat as withdraw behavior
> should be used." 

However I would leave the martians out. 
We should not dictate what addresses may be used as NH in various BGP features - that would be for another document. 

We should focus on the syntactic correctness of the NH 
And I think Chris has some valid questions there: 

> UNLESS, that is, there are next-hop errors which should be deemed mortal.
> The NEXT_HOP attribute can be completely broken without affecting the
> Parsing of NLRI.  But for MP_REACH_NLRI:
> 
>   (1) noting that (a) the draft treats invalid prefix
>       lengths as mortal errors, because they cast doubt
>       on the Parsing of NLRI...
> 
>       ...and that (b) in an MP_REACH_NLRI, the start of
>       the NLRI is given by the next-hop-length....
> 
>       ...is an invalid next-hop-length a mortal error ?
> 
>   (2) some Next-Hop values could be deemed "nonsense",
>       meaning that their presence should be considered
>       a symptom of a much more serious underlying
>       error, so...
> 
>       ...are there any Next-Hop values that should be
>       deemed mortal errors ?
> 
> Chris


adam