[Idr] draft-ietf-idr-rfc4893bis-00.txt / draft-ietf-idr-error-handling-00

<bruno.decraene@orange.com> Mon, 05 December 2011 11:40 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4261C21F8B81 for <idr@ietfa.amsl.com>; Mon, 5 Dec 2011 03:40:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.248
X-Spam-Level:
X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mJJwE9jOtGY for <idr@ietfa.amsl.com>; Mon, 5 Dec 2011 03:40:10 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9700921F8B7A for <idr@ietf.org>; Mon, 5 Dec 2011 03:40:09 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A7111340005; Mon, 5 Dec 2011 12:40:07 +0100 (CET)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 92D8B140001; Mon, 5 Dec 2011 12:40:07 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Dec 2011 12:40:07 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCB342.A2C78EF8"
Date: Mon, 05 Dec 2011 12:40:06 +0100
Message-ID: <FE8F6A65A433A744964C65B6EDFDC24002A9FD8C@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <4ED7FD2D.9000009@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-idr-rfc4893bis-00.txt / draft-ietf-idr-error-handling-00
Thread-Index: AcywdtuTrNS0xUVDR1+LpWaIQUsDmACxixpA
References: <7E27D7DD-8A61-43E8-904E-DEDB3B2D2C92@kumari.net><14DD6B3A-B114-4F42-B6D0-37CC377D28C5@juniper.net><4EC06F20.9020906@cisco.com><4897DDFA-095B-45BA-82F1-2FBC45747BA0@kumari.net><CAL9jLaYgu-OFgF2LOKCQXJ+GuYJKEaGRrpfH-ViRzOwW68+Rtg@mail.gmail.com><5A106376-42BC-404B-8460-BBF415049943@kumari.net> <4ED7FD2D.9000009@cisco.com>
From: bruno.decraene@orange.com
To: enkechen@cisco.com
X-OriginalArrivalTime: 05 Dec 2011 11:40:07.0348 (UTC) FILETIME=[A328DF40:01CCB342]
Cc: idr@ietf.org
Subject: [Idr] draft-ietf-idr-rfc4893bis-00.txt / draft-ietf-idr-error-handling-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 05 Dec 2011 11:40:14 -0000

Hi Enke, all

 

1)

>   o For the AS4_PATH and AS4_AGGREGATOR, the action is "attribute
discard" as specified in the rfc4893bis.



Interesting.

draft-ietf-idr-error-handling-00 says that the action MUST be
"treat-as-withdraw" unless the attribute has no effect on route
selection or installation. AS4_PATH _has_ effect on route installation
(AS loop detection in AS4_PATH).

I understand the reasons for both, yet are we sure we want to do this?
(defines 2 different error handling behavior for the same attribute,
write two draft which somehow disagree, with current wording (MUST) it
will be hard for an implementation to ever be compliant with both
documents).

I don't have a strong opinion, just raising the point for discussion.

 

 

2) draft-ietf-idr-rfc4893bis-04

"6. Error Handling

 

   Given that the two-octet AS numbers dominate during the transition,

   and are carried in the AS_PATH attribute by an OLD BGP speaker, in

   this document the "attribute discard" approach is chosen to handle a

   malformed AS4_PATH attribute."

 

"Given that the two-octet AS numbers dominate during the transition"
IMHO, I don't think this is the best reason as for example in some part
of the some inter-network, four-octet AS number could dominate. IMHO a
better reason could be that if all the ASes forming the loop are
four-octet compliant, then AS4_PATH will not be used and hence there is
no problem with that attribute. Otherwise, the AS_PATH attribute will
catch the loop.

 

Regards,

Bruno

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of
Enke Chen
Sent: Thursday, December 01, 2011 11:18 PM
To: Warren Kumari
Cc: idr@ietf.org
Subject: Re: [Idr] draft-ietf-idr-as0-00 ?

 

Warren:
 
I do not agree with the new text in the draft:
 
----
   This document specifies that a BGP speaker MUST NOT originate or
   propagate a route with an AS number of zero.  If a BGP speaker
   receives a route which has an AS number of zero in the AS_PATH (or
   AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW.
   This same behavior applies to routes containing zero as the
   Aggregator or AS4 Aggregator.

-----

The presence of AS 0 is considered as an error.  The handling of the
error condition should be specific to that attribute.  That is:

   o For the AS4_PATH and AS4_AGGREGATOR, the action is "attribute
discard" as specified in the rfc4893bis.

   o For the AGGREGATOR, the action is also "attribute discard" as
specified in draft-ietf-idr-error-handling-00.txt


I still think and continue to recommend that you merely describe that AS
0 is an error condition in the draft, and let the error handling draft
do the rest, as I suggested before:




   An UPDATE message that contains the AS number of zero in the AS-PATH
attribute
   MUST be considered as malformed, and be handled by the procedures
specified in
   draft-ietf-idr-optional-transitive-04.txt


-- Enke

On 12/1/11 1:50 PM, Warren Kumari wrote: 

[ Changed subject to reflect new title ]
 
 
On Dec 1, 2011, at 3:38 PM, Christopher Morrow wrote:
 

	On Sat, Nov 19, 2011 at 5:57 PM, Warren Kumari
<warren@kumari.net> <mailto:warren@kumari.net>  wrote:

		 
		On Nov 13, 2011, at 8:30 PM, Enke Chen wrote:
		 

			Support, but with the following suggestions:
			 
			1) Nit: change "bgp listener" to "bgp speaker".

		 
		Thank you, done.
		 

			 
			2) The following language is not very precise.
Due to the incremental nature, we will need to remove the existing route
too.
			 
			-----
			   a BGP
			   listener MUST NOT accept an announcement
which has an AS number of
			   zero in the AS-PATH attribute, and SHOULD log
the fact that it has
			   done so.
			-----
			 
			   How about the following:
			 
			   An UPDATE message that contains the AS number
of zero in the AS-PATH attribute
			   MUST be considered as malformed, and be
handled by the procedures specified in
			 
			draft-ietf-idr-optional-transitive-04.txt
			 
			3) If this draft is adopted, we should also add
AS 0 as one of the error conditions in
			rfc4893bis.

		 
		John also provided some text for that section and Keyur
suggested that we log and treat as a WITHDRAW.
		 
		This would read as:
		"This document specifies that a BGP speaker MUST NOT
originate or propagate a route with an AS number of zero.  If a BGP
speaker receives a route which has an AS number of zero in the AS_PATH
attribute, it SHOULD be logged and treated as a WITHDRAW."
		 

	 
	a question came up recently (today) on nanog about how AS0
should be
	treated wrt AGGREGATOR attributes... Should this say use of AS0
	anywhere (make a list perhaps?) is verboten? (or was that
assumed
	already?)

 
Actually Keyur Patel already pointed out the Aggregator (and AS4
Aggregator) attribute issue, and I included text in the WG version of
the doc, which I posted recently (although I have just realized that I
entered the text as "Aggregator" and not "AGGREGATOR", same for AS4...)
 
Which reminds me -- would folk please review draft-ietf-idr-as0-00 (
http://tools.ietf.org/html/draft-ietf-idr-as0-00 ) and provide feedback?
I *think* that I incorporated everyones comments, although I
accidentally overwrote the changed version with an older version (never
edit a file in two editors at once :-)) and so may have missed some...
 
W
 

	 

		This avoids having a normative reverence to the
optional-transitive draft and is (IMO) a little clearer. It also saves
optional-transitive from referencing this, and so we avoid the
deadlock...
		 
		Thoughts?
		 
		W
		 
		 

			 
			Thanks.   -- Enke
			 
			 
			On 10/28/11 1:51 PM, John Scudder wrote:

				Folks,
				 
				Please send comments to the list prior
to the IDR meeting on November 15.
				 
				Thanks,
				 
				--John
				 
				On Oct 27, 2011, at 9:29 AM, Warren
Kumari wrote:
				 
				 

				Hello IDRites,
				 
				I would like to draw your attention to
draft-wkumari-idr-as0-01.txt  (
	
http://tools.ietf.org/html/draft-wkumari-idr-as0-01
				 ) - I am asking that this draft be
considered for WG adoption.
				 
				 
				I have already received some feedback,
mainly suggesting:
				 
				- Add a text for AS number 0 as a
reserved in Aggregator and AS4
				Aggregator attribute
				 
				- Add text for AS number 0 as a reserved
value in communities and
				extended communities. (RFC 1997 and
Four-octet AS Specific Extended
				Communities)
				 
				Also suggested was providing a little
more information on what to do it you do receive a route containing AS0
(more descriptive than just "MUST NOT accept" (for example, stating that
it should be "excluded from the Phase 2 decision function")).
				 
				Anyway, I would value your feedback and
input.
				 
				W
				 
				 
				 
	
_______________________________________________
				Idr mailing list
				 
				Idr@ietf.org
	
https://www.ietf.org/mailman/listinfo/idr

	
_______________________________________________
				Idr mailing list
				 
				Idr@ietf.org
	
https://www.ietf.org/mailman/listinfo/idr

			 
			 
			_______________________________________________
			Idr mailing list
			Idr@ietf.org
			https://www.ietf.org/mailman/listinfo/idr

		 
		_______________________________________________
		Idr mailing list
		Idr@ietf.org
		https://www.ietf.org/mailman/listinfo/idr