From christopher.morrow@gmail.com Thu Dec 1 12:38:49 2011 Return-Path: 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 4219221F9428 for ; Thu, 1 Dec 2011 12:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 qGdctUAE5ajb for ; Thu, 1 Dec 2011 12:38:48 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDAA21F9427 for ; Thu, 1 Dec 2011 12:38:48 -0800 (PST) Received: by iaek3 with SMTP id k3so519390iae.31 for ; Thu, 01 Dec 2011 12:38:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oq83YrozXzb09gTbhI5EBoqZ3Vl2tNI+Hadhhqx94iM=; b=GjnYLptxfzz6FqlqLSBfByecYsYbFOr5VwazFgT7BxGL7qFBlNJ1VeexgJMQzaPtQ6 Q4sNd35/UAQcxV8AjPLj0Ra4NwDym029svx79onoSoYKeNy3abOPDD+WhA2PRd1/J/Ia +HwAXPxxQ6Y5WERwugbCuFKcPd629GJygXMsE= MIME-Version: 1.0 Received: by 10.43.65.79 with SMTP id xl15mr10294891icb.6.1322771927847; Thu, 01 Dec 2011 12:38:47 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.253.19 with HTTP; Thu, 1 Dec 2011 12:38:47 -0800 (PST) In-Reply-To: <4897DDFA-095B-45BA-82F1-2FBC45747BA0@kumari.net> 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> Date: Thu, 1 Dec 2011 15:38:47 -0500 X-Google-Sender-Auth: 1BCe2ZUZrxY-DaDG901p5dpupSg Message-ID: From: Christopher Morrow To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idr@ietf.org Subject: Re: [Idr] Accept draft-wkumari-idr-as0-01.txt ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 20:38:49 -0000 On Sat, Nov 19, 2011 at 5:57 PM, Warren Kumari 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. =A0Due to the incremental= nature, we will need to remove the existing route too. >> >> ----- >> =A0 =A0a BGP >> =A0 =A0listener MUST NOT accept an announcement which has an AS number o= f >> =A0 =A0zero in the AS-PATH attribute, and SHOULD log the fact that it ha= s >> =A0 =A0done so. >> ----- >> >> =A0 =A0How about the following: >> >> =A0 =A0An UPDATE message that contains the AS number of zero in the AS-P= ATH attribute >> =A0 =A0MUST 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 propaga= te a route with an AS number of zero. =A0If a BGP speaker receives a route = which has an AS number of zero in the AS_PATH attribute, it SHOULD be logge= d 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?) > This avoids having a normative reverence to the optional-transitive draft= and is (IMO) a little clearer. It also saves optional-transitive from refe= rencing this, and so we avoid the deadlock... > > Thoughts? > > W > > >> >> Thanks. =A0 -- 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 1= 5. >>> >>> 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 = =A0( >>>> http://tools.ietf.org/html/draft-wkumari-idr-as0-01 >>>> =A0) - 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 i= t you do receive a route containing AS0 =A0(more descriptive than just "MUS= T NOT accept" (for example, stating that it should be "excluded from the Ph= ase 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 From warren@kumari.net Thu Dec 1 13:50:54 2011 Return-Path: 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 D90E41F0CB7 for ; Thu, 1 Dec 2011 13:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 y7plbubbk0aA for ; Thu, 1 Dec 2011 13:50:53 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 17F2A1F0C91 for ; Thu, 1 Dec 2011 13:50:52 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id C89001B40424; Thu, 1 Dec 2011 16:50:51 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Thu, 1 Dec 2011 16:50:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5A106376-42BC-404B-8460-BBF415049943@kumari.net> 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> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-as0-00 ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 21:50:54 -0000 [ 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 = wrote: >>=20 >> On Nov 13, 2011, at 8:30 PM, Enke Chen wrote: >>=20 >>> Support, but with the following suggestions: >>>=20 >>> 1) Nit: change "bgp listener" to "bgp speaker". >>=20 >> Thank you, done. >>=20 >>>=20 >>> 2) The following language is not very precise. Due to the = incremental nature, we will need to remove the existing route too. >>>=20 >>> ----- >>> 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. >>> ----- >>>=20 >>> How about the following: >>>=20 >>> 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 >>>=20 >>> draft-ietf-idr-optional-transitive-04.txt >>>=20 >>> 3) If this draft is adopted, we should also add AS 0 as one of the = error conditions in >>> rfc4893bis. >>=20 >> John also provided some text for that section and Keyur suggested = that we log and treat as a WITHDRAW. >>=20 >> 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." >>=20 >=20 > 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 >=20 >> 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... >>=20 >> Thoughts? >>=20 >> W >>=20 >>=20 >>>=20 >>> Thanks. -- Enke >>>=20 >>>=20 >>> On 10/28/11 1:51 PM, John Scudder wrote: >>>> Folks, >>>>=20 >>>> Please send comments to the list prior to the IDR meeting on = November 15. >>>>=20 >>>> Thanks, >>>>=20 >>>> --John >>>>=20 >>>> On Oct 27, 2011, at 9:29 AM, Warren Kumari wrote: >>>>=20 >>>>=20 >>>>> Hello IDRites, >>>>>=20 >>>>> 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. >>>>>=20 >>>>>=20 >>>>> I have already received some feedback, mainly suggesting: >>>>>=20 >>>>> - Add a text for AS number 0 as a reserved in Aggregator and AS4 >>>>> Aggregator attribute >>>>>=20 >>>>> - Add text for AS number 0 as a reserved value in communities and >>>>> extended communities. (RFC 1997 and Four-octet AS Specific = Extended >>>>> Communities) >>>>>=20 >>>>> 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")). >>>>>=20 >>>>> Anyway, I would value your feedback and input. >>>>>=20 >>>>> W >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Idr mailing list >>>>>=20 >>>>> Idr@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/idr >>>> _______________________________________________ >>>> Idr mailing list >>>>=20 >>>> Idr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/idr >>>=20 >>>=20 >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 From enkechen@cisco.com Thu Dec 1 14:16:14 2011 Return-Path: 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 A016421F9378 for ; Thu, 1 Dec 2011 14:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 7MBc32V3z-t0 for ; Thu, 1 Dec 2011 14:16:13 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id CD9A521F936D for ; Thu, 1 Dec 2011 14:16:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=14257; q=dns/txt; s=iport; t=1322777773; x=1323987373; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=DEjQWbqkpx/VjlVlKUsfh17wdeekbmosV5UE7CTBj/8=; b=Ejpi1L833CpsVq3pQGfeQComrflR4cjCbyV343T/NxqNm2LLpI6bRorX 9P/VSWpE20T023bXWL4MWqCm+AR/OlSmpovTff6cYUIhEI6KI+H4zIJvu YAVkHl/r/HdEi3zzZNr/xwT+SbVWnlEUTw5yCogZcqtU9YIYt6tbZEm63 Q=; X-IronPort-AV: E=Sophos;i="4.71,280,1320624000"; d="scan'208,217";a="4110095" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 01 Dec 2011 22:16:11 +0000 Received: from dhcp-171-71-139-230.cisco.com (dhcp-171-71-139-230.cisco.com [171.71.139.230]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB1MG9Ac002177; Thu, 1 Dec 2011 22:16:10 GMT Message-ID: <4ED7FD2D.9000009@cisco.com> Date: Thu, 01 Dec 2011 14:18:21 -0800 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Warren Kumari 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> <5A106376-42BC-404B-8460-BBF415049943@kumari.net> In-Reply-To: <5A106376-42BC-404B-8460-BBF415049943@kumari.net> Content-Type: multipart/alternative; boundary="------------010901010702000202060603" Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-as0-00 ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 22:16:14 -0000 This is a multi-part message in MIME format. --------------010901010702000202060603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 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 --------------010901010702000202060603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
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> 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


        

        

      

      

    

    

  


--------------010901010702000202060603--

From warren@kumari.net  Thu Dec  1 14:44:11 2011
Return-Path: 
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 E19371F0C74 for ; Thu,  1 Dec 2011 14:44:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 1ge9Aq+lPM3v for ; Thu,  1 Dec 2011 14:44:11 -0800 (PST)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE3B1F0C38 for ; Thu,  1 Dec 2011 14:44:10 -0800 (PST)
Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id B5C001B407B8; Thu,  1 Dec 2011 17:44:09 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari 
In-Reply-To: <4ED7FD2D.9000009@cisco.com>
Date: Thu, 1 Dec 2011 17:44:08 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <58A7CE0B-0208-4D1E-BEB8-C9243D0BED1F@kumari.net>
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>  <5A106376-42BC-404B-8460-BBF415049943@kumari.net> <4ED7FD2D.9000009@cisco.com>
To: Enke Chen 
X-Mailer: Apple Mail (2.1084)
Cc: idr@ietf.org
Subject: Re: [Idr] draft-ietf-idr-as0-00 ?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 22:44:12 -0000

On Dec 1, 2011, at 5:18 PM, Enke Chen wrote:

> Warren:
>=20
> I do not agree with the new text in the draft:
>=20
> ----
>    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.
>=20
> -----
>=20
> The presence of AS 0 is considered as an error.  The handling of the =
error condition should be specific to that attribute.  That is:
>=20
>    o For the AS4_PATH and AS4_AGGREGATOR, the action is "attribute =
discard" as specified in the rfc4893bis.
>=20
>    o For the AGGREGATOR, the action is also "attribute discard" as =
specified in draft-ietf-idr-error-handling-00.txt
>=20
>=20
> 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:
>=20
>    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

Sure -- I was trying to avoid having this draft gate on publication of =
the idr-optional-transitive draft, but (of course) am happy to do =
whatever the WG wants (hint to WG: please let me know what you want :-P)

W

>=20
>=20
> -- Enke




> On 12/1/11 1:50 PM, Warren Kumari wrote:
>> [ Changed subject to reflect new title ]
>>=20
>>=20
>> On Dec 1, 2011, at 3:38 PM, Christopher Morrow wrote:
>>=20
>>=20
>>> On Sat, Nov 19, 2011 at 5:57 PM, Warren Kumari 
>>>  wrote:
>>>=20
>>>> On Nov 13, 2011, at 8:30 PM, Enke Chen wrote:
>>>>=20
>>>>=20
>>>>> Support, but with the following suggestions:
>>>>>=20
>>>>> 1) Nit: change "bgp listener" to "bgp speaker".
>>>>>=20
>>>> Thank you, done.
>>>>=20
>>>>=20
>>>>> 2) The following language is not very precise.  Due to the =
incremental nature, we will need to remove the existing route too.
>>>>>=20
>>>>> -----
>>>>>    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.
>>>>> -----
>>>>>=20
>>>>>    How about the following:
>>>>>=20
>>>>>    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
>>>>>=20
>>>>> draft-ietf-idr-optional-transitive-04.txt
>>>>>=20
>>>>> 3) If this draft is adopted, we should also add AS 0 as one of the =
error conditions in
>>>>> rfc4893bis.
>>>>>=20
>>>> John also provided some text for that section and Keyur suggested =
that we log and treat as a WITHDRAW.
>>>>=20
>>>> 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."
>>>>=20
>>>>=20
>>> 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?)
>>>=20
>> 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...)
>>=20
>> Which reminds me -- would folk please review draft-ietf-idr-as0-00 (=20=

>> 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...
>>=20
>> W
>>=20
>>=20
>>>> 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...
>>>>=20
>>>> Thoughts?
>>>>=20
>>>> W
>>>>=20
>>>>=20
>>>>=20
>>>>> Thanks.   -- Enke
>>>>>=20
>>>>>=20
>>>>> On 10/28/11 1:51 PM, John Scudder wrote:
>>>>>=20
>>>>>> Folks,
>>>>>>=20
>>>>>> Please send comments to the list prior to the IDR meeting on =
November 15.
>>>>>>=20
>>>>>> Thanks,
>>>>>>=20
>>>>>> --John
>>>>>>=20
>>>>>> On Oct 27, 2011, at 9:29 AM, Warren Kumari wrote:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> Hello IDRites,
>>>>>>>=20
>>>>>>> I would like to draw your attention to =
draft-wkumari-idr-as0-01.txt  (
>>>>>>>=20
>>>>>>> http://tools.ietf.org/html/draft-wkumari-idr-as0-01
>>>>>>>=20
>>>>>>>  ) - I am asking that this draft be considered for WG adoption.
>>>>>>>=20
>>>>>>>=20
>>>>>>> I have already received some feedback, mainly suggesting:
>>>>>>>=20
>>>>>>> - Add a text for AS number 0 as a reserved in Aggregator and AS4
>>>>>>> Aggregator attribute
>>>>>>>=20
>>>>>>> - Add text for AS number 0 as a reserved value in communities =
and
>>>>>>> extended communities. (RFC 1997 and Four-octet AS Specific =
Extended
>>>>>>> Communities)
>>>>>>>=20
>>>>>>> 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")).
>>>>>>>=20
>>>>>>> Anyway, I would value your feedback and input.
>>>>>>>=20
>>>>>>> W
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> Idr mailing list
>>>>>>>=20
>>>>>>>=20
>>>>>>> Idr@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>>> _______________________________________________
>>>>>> Idr mailing list
>>>>>>=20
>>>>>>=20
>>>>>> Idr@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>>=20
>>>>> _______________________________________________
>>>>> Idr mailing list
>>>>>=20
>>>>> Idr@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>> _______________________________________________
>>>> Idr mailing list
>>>>=20
>>>> Idr@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/idr
>=20


From jakob.heitz@ericsson.com  Thu Dec  1 14:49:35 2011
Return-Path: 
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 804C31F0CBF for ; Thu,  1 Dec 2011 14:49:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 137INeV1hNgF for ; Thu,  1 Dec 2011 14:49:34 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id AA7E31F0CBE for ; Thu,  1 Dec 2011 14:49:34 -0800 (PST)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pB1MnV8k003674; Thu, 1 Dec 2011 16:49:34 -0600
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 1 Dec 2011 17:49:31 -0500
From: Jakob Heitz 
To: Warren Kumari , Enke Chen 
Date: Thu, 1 Dec 2011 17:49:30 -0500
Thread-Topic: [Idr] draft-ietf-idr-as0-00 ?
Thread-Index: AcywesOLY1CN8Q6dQCC+4UTUQeIY0gAAH0Bg
Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A474CDCAD@EUSAACMS0701.eamcs.ericsson.se>
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>  <5A106376-42BC-404B-8460-BBF415049943@kumari.net> <4ED7FD2D.9000009@cisco.com> <58A7CE0B-0208-4D1E-BEB8-C9243D0BED1F@kumari.net>
In-Reply-To: <58A7CE0B-0208-4D1E-BEB8-C9243D0BED1F@kumari.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org" 
Subject: Re: [Idr] draft-ietf-idr-as0-00 ?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 22:49:35 -0000

I agree.
draft-ietf-idr-optional-transitive-04 has been recently revised and renamed
draft-ietf-idr-error-handling.

--
Jakob Heitz.

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Warre=
n Kumari
Sent: Thursday, December 01, 2011 2:44 PM
To: Enke Chen
Cc: idr@ietf.org
Subject: Re: [Idr] draft-ietf-idr-as0-00 ?


On Dec 1, 2011, at 5:18 PM, Enke Chen wrote:

> Warren:
>=20
> I do not agree with the new text in the draft:
>=20
> ----
>    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.
>=20
> -----
>=20
> The presence of AS 0 is considered as an error.  The handling of the erro=
r condition should be specific to that attribute.  That is:
>=20
>    o For the AS4_PATH and AS4_AGGREGATOR, the action is "attribute discar=
d" as specified in the rfc4893bis.
>=20
>    o For the AGGREGATOR, the action is also "attribute discard" as specif=
ied in draft-ietf-idr-error-handling-00.txt
>=20
>=20
> 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 t=
he rest, as I suggested before:
>=20
>    An UPDATE message that contains the AS number of zero in the AS-PATH a=
ttribute
>    MUST be considered as malformed, and be handled by the procedures spec=
ified in
>    draft-ietf-idr-optional-transitive-04.txt

Sure -- I was trying to avoid having this draft gate on publication of the =
idr-optional-transitive draft, but (of course) am happy to do whatever the =
WG wants (hint to WG: please let me know what you want :-P)

W

>=20
>=20
> -- Enke




> On 12/1/11 1:50 PM, Warren Kumari wrote:
>> [ Changed subject to reflect new title ]
>>=20
>>=20
>> On Dec 1, 2011, at 3:38 PM, Christopher Morrow wrote:
>>=20
>>=20
>>> On Sat, Nov 19, 2011 at 5:57 PM, Warren Kumari 
>>>  wrote:
>>>=20
>>>> On Nov 13, 2011, at 8:30 PM, Enke Chen wrote:
>>>>=20
>>>>=20
>>>>> Support, but with the following suggestions:
>>>>>=20
>>>>> 1) Nit: change "bgp listener" to "bgp speaker".
>>>>>=20
>>>> Thank you, done.
>>>>=20
>>>>=20
>>>>> 2) The following language is not very precise.  Due to the incrementa=
l nature, we will need to remove the existing route too.
>>>>>=20
>>>>> -----
>>>>>    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.
>>>>> -----
>>>>>=20
>>>>>    How about the following:
>>>>>=20
>>>>>    An UPDATE message that contains the AS number of zero in the AS-PA=
TH attribute
>>>>>    MUST be considered as malformed, and be handled by the procedures =
specified in
>>>>>=20
>>>>> draft-ietf-idr-optional-transitive-04.txt
>>>>>=20
>>>>> 3) If this draft is adopted, we should also add AS 0 as one of the er=
ror conditions in
>>>>> rfc4893bis.
>>>>>=20
>>>> John also provided some text for that section and Keyur suggested that=
 we log and treat as a WITHDRAW.
>>>>=20
>>>> This would read as:
>>>> "This document specifies that a BGP speaker MUST NOT originate or prop=
agate 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 logg=
ed and treated as a WITHDRAW."
>>>>=20
>>>>=20
>>> 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?)
>>>=20
>> Actually Keyur Patel already pointed out the Aggregator (and AS4 Aggrega=
tor) attribute issue, and I included text in the WG version of the doc, whi=
ch I posted recently (although I have just realized that I entered the text=
 as "Aggregator" and not "AGGREGATOR", same for AS4...)
>>=20
>> Which reminds me -- would folk please review draft-ietf-idr-as0-00 (=20
>> http://tools.ietf.org/html/draft-ietf-idr-as0-00
>>  ) and provide feedback?
>> I *think* that I incorporated everyones comments, although I accidentall=
y overwrote the changed version with an older version (never edit a file in=
 two editors at once :-)) and so may have missed some...
>>=20
>> W
>>=20
>>=20
>>>> This avoids having a normative reverence to the optional-transitive dr=
aft and is (IMO) a little clearer. It also saves optional-transitive from r=
eferencing this, and so we avoid the deadlock...
>>>>=20
>>>> Thoughts?
>>>>=20
>>>> W
>>>>=20
>>>>=20
>>>>=20
>>>>> Thanks.   -- Enke
>>>>>=20
>>>>>=20
>>>>> On 10/28/11 1:51 PM, John Scudder wrote:
>>>>>=20
>>>>>> Folks,
>>>>>>=20
>>>>>> Please send comments to the list prior to the IDR meeting on Novembe=
r 15.
>>>>>>=20
>>>>>> Thanks,
>>>>>>=20
>>>>>> --John
>>>>>>=20
>>>>>> On Oct 27, 2011, at 9:29 AM, Warren Kumari wrote:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> Hello IDRites,
>>>>>>>=20
>>>>>>> I would like to draw your attention to draft-wkumari-idr-as0-01.txt=
  (
>>>>>>>=20
>>>>>>> http://tools.ietf.org/html/draft-wkumari-idr-as0-01
>>>>>>>=20
>>>>>>>  ) - I am asking that this draft be considered for WG adoption.
>>>>>>>=20
>>>>>>>=20
>>>>>>> I have already received some feedback, mainly suggesting:
>>>>>>>=20
>>>>>>> - Add a text for AS number 0 as a reserved in Aggregator and AS4
>>>>>>> Aggregator attribute
>>>>>>>=20
>>>>>>> - Add text for AS number 0 as a reserved value in communities and
>>>>>>> extended communities. (RFC 1997 and Four-octet AS Specific Extended
>>>>>>> Communities)
>>>>>>>=20
>>>>>>> Also suggested was providing a little more information on what to d=
o it you do receive a route containing AS0  (more descriptive than just "MU=
ST NOT accept" (for example, stating that it should be "excluded from the P=
hase 2 decision function")).
>>>>>>>=20
>>>>>>> Anyway, I would value your feedback and input.
>>>>>>>=20
>>>>>>> W
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> Idr mailing list
>>>>>>>=20
>>>>>>>=20
>>>>>>> Idr@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>>> _______________________________________________
>>>>>> Idr mailing list
>>>>>>=20
>>>>>>=20
>>>>>> Idr@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>>=20
>>>>> _______________________________________________
>>>>> Idr mailing list
>>>>>=20
>>>>> Idr@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>> _______________________________________________
>>>> Idr mailing list
>>>>=20
>>>> Idr@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/idr
>=20

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

From jeff.tantsura@ericsson.com  Thu Dec  1 14:51:53 2011
Return-Path: 
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 449C911E8141 for ; Thu,  1 Dec 2011 14:51:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 HJoHxujpadyB for ; Thu,  1 Dec 2011 14:51:50 -0800 (PST)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id E0E7611E8129 for ; Thu,  1 Dec 2011 14:51:49 -0800 (PST)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pB1MpmxC030511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Dec 2011 16:51:49 -0600
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 1 Dec 2011 17:51:48 -0500
From: Jeff Tantsura 
To: Enke Chen , Warren Kumari 
Date: Thu, 1 Dec 2011 17:51:47 -0500
Thread-Topic: [Idr] draft-ietf-idr-as0-00 ?
Thread-Index: Acywdu+jhz14xfHFTSSkgTz3lWFsWgABJ+fw
Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C2562C4@EUSAACMS0701.eamcs.ericsson.se>
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>  <5A106376-42BC-404B-8460-BBF415049943@kumari.net> <4ED7FD2D.9000009@cisco.com>
In-Reply-To: <4ED7FD2D.9000009@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_0ED867EB33AB2B45AAB470D5A64CDBF6181C2562C4EUSAACMS0701e_"
MIME-Version: 1.0
Cc: "idr@ietf.org" 
Subject: Re: [Idr] draft-ietf-idr-as0-00 ?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 22:51:53 -0000

--_000_0ED867EB33AB2B45AAB470D5A64CDBF6181C2562C4EUSAACMS0701e_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1

Let's keep error condition and error handling separately

Regards,
Jeff

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke =
Chen
Sent: Thursday, December 01, 2011 2: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 specifie=
d 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 att=
ribute

   MUST be considered as malformed, and be handled by the procedures specif=
ied 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  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 natu=
re, 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 att=
ribute

   MUST be considered as malformed, and be handled by the procedures specif=
ied 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 co=
nditions in

rfc4893bis.



John also provided some text for that section and Keyur suggested that we l=
og 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 whic=
h has an AS number of zero in the AS_PATH attribute, it SHOULD be logged an=
d 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 o=
verwrote the changed version with an older version (never edit a file in tw=
o editors at once :-)) and so may have missed some...



W





This avoids having a normative reverence to the optional-transitive draft a=
nd is (IMO) a little clearer. It also saves optional-transitive from refere=
ncing 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 a=
ccept" (for example, stating that it should be "excluded from the Phase 2 d=
ecision 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






--_000_0ED867EB33AB2B45AAB470D5A64CDBF6181C2562C4EUSAACMS0701e_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
+1
 
Let’s keep error condition an=
d error handling separately
 
Regards,
Jeff
 
From: idr-bo=
unces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke Chen<=
br>Sent: Thursday, December 01, 2011 2:18 PM
To: Warren Ku=
mari
Cc: idr@ietf.org
Subject: Re: [Idr] draft-ietf-idr=
-as0-00 ?
 =

Warren:
 
I d=
o not agree with the new text in the draft:
 =
;
----
   This document spec=
ifies that a BGP speaker MUST NOT originate or
 &=
nbsp; 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) attrib=
ute, it SHOULD be logged and treated as a WITHDRAW.
&n=
bsp;  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 tha=
t 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 &=
quot;attribute discard" as specified in draft-ietf-idr-error-handling-=
00.txt


I still think and continue to recommend that you merely d=
escribe that AS 0 is an error condition in the draft, and let the error han=
dling draft do the rest, as I suggested before:


<=
pre>   An UPDATE message that contains the AS number of zero in t=
he AS-PATH attribute
   MUST be considered a=
s 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 De=
c 1, 2011, at 3:38 PM, Christopher Morrow wrote:
=
 
On Sat, Nov 19, 2011 at 5:57 PM, Warren Kumari <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" t=
o "bgp speaker".
 
Thank you, done.
 
=

 =

2) The following language is not very precise.  Due t=
o the incremental nature, we will need to remove the existing route too.
 
-----
&=
nbsp;  a BGP
   listener MUST NOT accep=
t an announcement which has an AS number of
 &nbs=
p; zero in the AS-PATH attribute, and SHOULD log the fact that it has<=
/o:p>
   done so.
-----=

 
   How about the following=
:
 
   An UPDATE m=
essage 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
&n=
bsp;
3) If this draft is adopted, we should also add AS 0 a=
s one of the error conditions in
rfc4893bis.
 
John also provided som=
e text for that section and Keyur suggested that we log and treat as a WITH=
DRAW.
 
This would read as:<=
o:p>
"This document specifies that a BGP speaker MUST =
NOT originate or propagate a route with an AS number of zero.  If a BG=
P speaker receives a route which has an AS number of zero in the AS_PATH at=
tribute, 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 o=
f AS0
anywhere (make a list perhaps?) is verboten? (or=
 was that assumed
already?)
 
Actually Keyur Patel already pointed ou=
t 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 "A=
GGREGATOR", 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 acc=
identally overwrote the changed version with an older version (never edit a=
 file in two editors at once :-)) and so may have missed some...=

 
W
 
<=
o:p> 
This avoids having a normative reverence to the optional-transit=
ive 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 Nov=
ember 15.
 
Thanks,
 
--John
&=
nbsp;
On Oct 27, 2011, at 9:29 AM, Warren Kumari wrote:
 
 
Hello IDRites,
 
I would like to draw your at=
tention to draft-wkumari-idr-as0-01.txt  (
http://tools.ietf=
.org/html/draft-wkumari-idr-as0-01
 ) - I am askin=
g 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)
<=
o:p> 
Also suggested was providing a little more infor=
mation on what to do it you do receive a route containing AS0  (more d=
escriptive than just "MUST NOT accept" (for example, stating that=
 it should be "excluded from the Phase 2 decision function")).
 
Anyway, I would value your f=
eedback and input.
 
W<=
/o:p>
 
 
 
_______________________________________________
Idr mailing list
 <=
/pre>
Idr@ietf.org
=

https://www.ietf=
.org/mailman/listinfo/idr
___________=
____________________________________
Idr mailing list<=
o:p>
 
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
 
 
_______________________________________________
Idr mailing list
Id=
r@ietf.org
https://www.ietf.org/mailman/listinfo/idr
 
___________________________=
____________________
Idr mailing list
=

Idr@ietf.org
=
https://www.ietf.org/=
mailman/listinfo/idr
 
 
&=
nbsp;
=

--_000_0ED867EB33AB2B45AAB470D5A64CDBF6181C2562C4EUSAACMS0701e_--

From danny@tcb.net  Thu Dec  1 17:57:31 2011
Return-Path: 
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 AAD4E1F0C87 for ; Thu,  1 Dec 2011 17:57:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 O8qWBAcCbAkE for ; Thu,  1 Dec 2011 17:57:31 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0221F0C82 for ; Thu,  1 Dec 2011 17:57:31 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id 00BAE3681BC; Thu,  1 Dec 2011 18:57:30 -0700 (MST)
Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 01 Dec 2011 18:57:30 -0700 (MST) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=61080; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Danny McPherson 
In-Reply-To: <4ED7FD2D.9000009@cisco.com>
Date: Thu, 1 Dec 2011 20:56:20 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <48E559E7-B92D-429F-868F-57DC3BD19AF7@tcb.net>
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>  <5A106376-42BC-404B-8460-BBF415049943@kumari.net> <4ED7FD2D.9000009@cisco.com>
To: Enke Chen , Warren Kumari 
X-Mailer: Apple Mail (2.1084)
Cc: "idr@ietf.org List" 
Subject: Re: [Idr] draft-ietf-idr-as0-00 ?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 02 Dec 2011 01:57:31 -0000

I agre with Enke here as well...

-danny


On Dec 1, 2011, at 5:18 PM, Enke Chen wrote:

>=20
> 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:
>=20
>    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
>=20
>=20


From dbg@net-geek.org  Fri Dec  2 05:13:03 2011
Return-Path: 
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 784E921F9910 for ; Fri,  2 Dec 2011 05:13:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.129
X-Spam-Level: 
X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875]
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 vkRf5dWp34X6 for ; Fri,  2 Dec 2011 05:13:03 -0800 (PST)
Received: from malpaso.ru (malpaso.ru [89.108.121.39]) by ietfa.amsl.com (Postfix) with ESMTP id D8E4D21F9846 for ; Fri,  2 Dec 2011 05:13:02 -0800 (PST)
Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=[172.26.204.69]) by malpaso.ru with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1RWSv9-0004cY-6G; Fri, 02 Dec 2011 17:12:56 +0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Daniel Ginsburg 
In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se>
Date: Fri, 2 Dec 2011 17:12:48 +0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org>
References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se>
To: Jeff Tantsura , Warren Kumari 
X-Mailer: Apple Mail (2.1084)
Cc: idr@ietf.org, nanog@nanog.org
Subject: [Idr] draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 02 Dec 2011 13:13:03 -0000

Hi,

This is true that "no-aggregator-id" knob zeroes out the AGGREGATOR =
attribute.

The knob, as far as I was able to find out, dates back to gated and =
there's a reason why it was introduced - it helps to avoid unnecessary =
updates. Assume that an aggregate route is generated by two (or more) =
speakers in the network. These two aggregates differ only in AGGREGATOR =
attribute. One of the aggregates is preferred within the network (due to =
IGP metric, for instance, or any other reasons) and is announced out. =
Now if something changes within the network and the other instance of =
the aggregate becomes preferred, the network has to issue an outward =
update different from the previous only in AGGREGATOR attribute, which =
is completely superfluous.

If the network employs the "no-aggregator-id" knob to zero out the =
AGGREGATOR attribute, both instances of the aggregate route are =
completely equivalent, and no redundant outward updates have to be send =
if one instance becomes better than another due to some internal event, =
which nobody in the Internet cares about.

In other words, the "no-aggregator-id" knob has valid operational =
reasons to be used. And, IMHO, the draft-ietf-idr-as0-00 should not =
prohibit AS0 in AGGREGATOR attribute.

On 02.12.2011, at 1:56, Jeff Tantsura wrote:

> Hi,
>=20
> Let me take it over from now on, I'm the IP Routing/MPLS Product =
Manager at Ericsson responsible for all routing protocols.
> There's nothing wrong in checking ASN in AGGREGATOR, we don't really =
want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 =
(draft-ietf-idr-as0-00) came into the worlds.
>=20
> To my knowledge - the only vendor which allows changing ASN in =
AGGREGATOR is Juniper, see "no-aggregator-id", in the past I've tried to =
talk to Yakov about it, without any results though.=20
> So for those who have it configured - please rethink whether you =
really need it.
>=20
> As for SEOS - understanding that this badly affects our customers and =
not having draft-ietf-idr-error-handling fully implemented yet, we will =
temporarily disable this check in our code.
> Patch will be made available.
>=20
> Please contact me for any further clarifications.
>=20
> Regards,
> Jeff
>=20
> P.S. Warren has recently  included AGGREGATOR in the draft, please see
>=20
> 2. Behavior
>   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.
>=20


From jeff.tantsura@ericsson.com  Sat Dec  3 00:21:40 2011
Return-Path: 
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 7BD3921F8E38 for ; Sat,  3 Dec 2011 00:21:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, 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 rTb+RHK5sKMC for ; Sat,  3 Dec 2011 00:21:39 -0800 (PST)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id D365E21F8E31 for ; Sat,  3 Dec 2011 00:21:39 -0800 (PST)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pB38LZwS021722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Dec 2011 02:21:36 -0600
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sat, 3 Dec 2011 03:21:35 -0500
From: Jeff Tantsura 
To: Daniel Ginsburg , Warren Kumari 
Date: Sat, 3 Dec 2011 03:21:33 -0500
Thread-Topic: draft-ietf-idr-as0-00  (bgp update destroying transit on redback routers ?)
Thread-Index: Acyw9CSfi+VCcj6wQpS4Cam5+Cfc3QAnGVPw
Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C2EDF8A@EUSAACMS0701.eamcs.ericsson.se>
References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se> <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org>
In-Reply-To: <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org" , "nanog@nanog.org" 
Subject: Re: [Idr] draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 03 Dec 2011 08:21:40 -0000

Hi Daniel,

I do understand the use of it however have my doubts about usability as suc=
h, I'd really like to see anyone using it for the reason below.
All of updates with ASN 0 I have seen in the past few years were there due =
to software bugs, not explicit configuration - same as this one.

Warren/ idr -  I do support addition of AGGREGATOR in the draft

Regards,
Jeff

P.S. Jeffrey/John -  this draft makes use of "no-aggregator-id"  de facto i=
lligal, are you (your customers) OK with it?=20
Thanks!

-----Original Message-----
From: Daniel Ginsburg [mailto:dbg@net-geek.org]=20
Sent: Friday, December 02, 2011 5:13 AM
To: Jeff Tantsura; Warren Kumari
Cc: nanog@nanog.org; idr@ietf.org
Subject: draft-ietf-idr-as0-00 (bgp update destroying transit on redback ro=
uters ?)

Hi,

This is true that "no-aggregator-id" knob zeroes out the AGGREGATOR attribu=
te.

The knob, as far as I was able to find out, dates back to gated and there's=
 a reason why it was introduced - it helps to avoid unnecessary updates. As=
sume that an aggregate route is generated by two (or more) speakers in the =
network. These two aggregates differ only in AGGREGATOR attribute. One of t=
he aggregates is preferred within the network (due to IGP metric, for insta=
nce, or any other reasons) and is announced out. Now if something changes w=
ithin the network and the other instance of the aggregate becomes preferred=
, the network has to issue an outward update different from the previous on=
ly in AGGREGATOR attribute, which is completely superfluous.

If the network employs the "no-aggregator-id" knob to zero out the AGGREGAT=
OR attribute, both instances of the aggregate route are completely equivale=
nt, and no redundant outward updates have to be send if one instance become=
s better than another due to some internal event, which nobody in the Inter=
net cares about.

In other words, the "no-aggregator-id" knob has valid operational reasons t=
o be used. And, IMHO, the draft-ietf-idr-as0-00 should not prohibit AS0 in =
AGGREGATOR attribute.

On 02.12.2011, at 1:56, Jeff Tantsura wrote:

> Hi,
>=20
> Let me take it over from now on, I'm the IP Routing/MPLS Product Manager =
at Ericsson responsible for all routing protocols.
> There's nothing wrong in checking ASN in AGGREGATOR, we don't really want=
 see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-0=
0) came into the worlds.
>=20
> To my knowledge - the only vendor which allows changing ASN in AGGREGATOR=
 is Juniper, see "no-aggregator-id", in the past I've tried to talk to Yako=
v about it, without any results though.=20
> So for those who have it configured - please rethink whether you really n=
eed it.
>=20
> As for SEOS - understanding that this badly affects our customers and not=
 having draft-ietf-idr-error-handling fully implemented yet, we will tempor=
arily disable this check in our code.
> Patch will be made available.
>=20
> Please contact me for any further clarifications.
>=20
> Regards,
> Jeff
>=20
> P.S. Warren has recently  included AGGREGATOR in the draft, please see
>=20
> 2. Behavior
>   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.
>=20


From brian.peter.dickson@gmail.com  Sat Dec  3 09:22:58 2011
Return-Path: 
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 340EB21F9290 for ; Sat,  3 Dec 2011 09:22:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 F0q9GRNeC0hv for ; Sat,  3 Dec 2011 09:22:57 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 56AA321F91AB for ; Sat,  3 Dec 2011 09:22:57 -0800 (PST)
Received: by wgbdr13 with SMTP id dr13so2832628wgb.13 for ; Sat, 03 Dec 2011 09:22:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=k8Tdlr3ZVfIPuHvb+pF0n5KOiN6lllj7dWA7d5XJgGY=; b=aw4fkUFRPx67fZBkZ+zA7baPuGbwDn0C+Idb0Ex2FUAINKI7+Qi/ykWdeHVhxs8HEq RVb49zUTu5cmfBcCdNahZeC6eq1hbVGmWr/liNm6HUQ4d6+hxF2mTPERE8KsTNcgjg9j zF29ZtP+4sAEF+jG1/1qFY/7k1bBj9e56u+5A=
MIME-Version: 1.0
Received: by 10.227.209.82 with SMTP id gf18mr10160694wbb.8.1322932976487; Sat, 03 Dec 2011 09:22:56 -0800 (PST)
Received: by 10.223.101.134 with HTTP; Sat, 3 Dec 2011 09:22:56 -0800 (PST)
In-Reply-To: <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org>
References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se> <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org>
Date: Sat, 3 Dec 2011 12:22:56 -0500
Message-ID: 
From: Brian Dickson 
To: Daniel Ginsburg 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: idr@ietf.org, nanog@nanog.org
Subject: Re: [Idr] draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 03 Dec 2011 17:22:58 -0000

Can anyone familiar with this knob and its usage, answer a question:

Would anything break, in terms of use of that knob, if instead of
"zeroing" the AGGREGATOR, the local AS (as seen from the outside
world, in the case of confederations) were used?

Would the functionality of the knob, in reducing updates, be preserved?

Would routes be considered malformed or would it trigger any other bad beha=
vior?

Perhaps this is a way of resolving the conflict between this knob and
the AS0 draft?

Brian

On Fri, Dec 2, 2011 at 8:12 AM, Daniel Ginsburg  wrote:
> Hi,
>
> This is true that "no-aggregator-id" knob zeroes out the AGGREGATOR attri=
bute.
>
> The knob, as far as I was able to find out, dates back to gated and there=
's a reason why it was introduced - it helps to avoid unnecessary updates. =
Assume that an aggregate route is generated by two (or more) speakers in th=
e network. These two aggregates differ only in AGGREGATOR attribute. One of=
 the aggregates is preferred within the network (due to IGP metric, for ins=
tance, or any other reasons) and is announced out. Now if something changes=
 within the network and the other instance of the aggregate becomes preferr=
ed, the network has to issue an outward update different from the previous =
only in AGGREGATOR attribute, which is completely superfluous.
>
> If the network employs the "no-aggregator-id" knob to zero out the AGGREG=
ATOR attribute, both instances of the aggregate route are completely equiva=
lent, and no redundant outward updates have to be send if one instance beco=
mes better than another due to some internal event, which nobody in the Int=
ernet cares about.
>
> In other words, the "no-aggregator-id" knob has valid operational reasons=
 to be used. And, IMHO, the draft-ietf-idr-as0-00 should not prohibit AS0 i=
n AGGREGATOR attribute.
>
> On 02.12.2011, at 1:56, Jeff Tantsura wrote:
>
>> Hi,
>>
>> Let me take it over from now on, I'm the IP Routing/MPLS Product Manager=
 at Ericsson responsible for all routing protocols.
>> There's nothing wrong in checking ASN in AGGREGATOR, we don't really wan=
t see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-=
00) came into the worlds.
>>
>> To my knowledge - the only vendor which allows changing ASN in AGGREGATO=
R is Juniper, see "no-aggregator-id", in the past I've tried to talk to Yak=
ov about it, without any results though.
>> So for those who have it configured - please rethink whether you really =
need it.
>>
>> As for SEOS - understanding that this badly affects our customers and no=
t having draft-ietf-idr-error-handling fully implemented yet, we will tempo=
rarily disable this check in our code.
>> Patch will be made available.
>>
>> Please contact me for any further clarifications.
>>
>> Regards,
>> Jeff
>>
>> P.S. Warren has recently =A0included AGGREGATOR in the draft, please see
>>
>> 2. Behavior
>> =A0 This document specifies that a BGP speaker MUST NOT originate or
>> =A0 propagate a route with an AS number of zero. =A0If a BGP speaker
>> =A0 receives a route which has an AS number of zero in the AS_PATH (or
>> =A0 AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW.
>> =A0 This same behavior applies to routes containing zero as the
>> =A0 Aggregator or AS4 Aggregator.
>>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

From internet-drafts@ietf.org  Mon Dec  5 01:10:59 2011
Return-Path: 
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 E9B4E21F8B1D; Mon,  5 Dec 2011 01:10:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.575
X-Spam-Level: 
X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 AHv8itbtTolJ; Mon,  5 Dec 2011 01:10:58 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B9821F8AF3; Mon,  5 Dec 2011 01:10:58 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64
Message-ID: <20111205091058.29351.8292.idtracker@ietfa.amsl.com>
Date: Mon, 05 Dec 2011 01:10:58 -0800
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-reserved-extended-communities-02.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 09:10:59 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Inter-Domain Routing Working Group of=
 the IETF.

	Title           : Assigned BGP extended communities
	Author(s)       : Bruno Decraene
                          Pierre Francois
	Filename        : draft-ietf-idr-reserved-extended-communities-02.txt
	Pages           : 5
	Date            : 2011-12-05

   This document defines two IANA registries in order to assign
   transitive and non-transitive extended communities from.  These are
   similar to the existing well-known BGP communities defined in RFC
   1997 but provide an easier control of inter-AS community
   advertisement as a community could be chosen as transitive or non-
   transitive across ASes.

   For that purpose, this document defines the use of the reserved AS
   number 0 for the transitive and non-transitive generic four-octet AS
   specific extended community types.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-reserved-extended-commun=
ities-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-reserved-extended-communi=
ties-02.txt


From bruno.decraene@orange.com  Mon Dec  5 01:15:31 2011
Return-Path: 
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 359EA21F861E for ; Mon,  5 Dec 2011 01:15:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 44Wig2uzp6z0 for ; Mon,  5 Dec 2011 01:15:30 -0800 (PST)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id D448A21F863E for ; Mon,  5 Dec 2011 01:15:29 -0800 (PST)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 688CC8D0001 for ; Mon,  5 Dec 2011 10:16:35 +0100 (CET)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 5F8A18B8002 for ; Mon,  5 Dec 2011 10:16:35 +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 10:15:28 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 5 Dec 2011 10:15:27 +0100
Message-ID: 
In-Reply-To: <20111205091058.29351.8292.idtracker@ietfa.amsl.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] I-D Action:draft-ietf-idr-reserved-extended-communities-02.txt
Thread-Index: AcyzLeObKj2/fw9cRuOczd5tBWXkYgAACcMQ
X-Priority: 5
Priority: Non-Urgent
Importance: low
References: <20111205091058.29351.8292.idtracker@ietfa.amsl.com>
From: 
To: 
X-OriginalArrivalTime: 05 Dec 2011 09:15:28.0603 (UTC) FILETIME=[6E397AB0:01CCB32E]
Subject: Re: [Idr] I-D Action:draft-ietf-idr-reserved-extended-communities-02.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 09:15:31 -0000

Hi all,

Just refreshing the draft. No technical change:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-reserved-extended-com=
m
unities-02.txt

Regards,
Bruno

>-----Original Message-----
>From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of
internet-
>drafts@ietf.org
>Sent: Monday, December 05, 2011 10:11 AM
>To: i-d-announce@ietf.org
>Cc: idr@ietf.org
>Subject: [Idr] I-D
Action:draft-ietf-idr-reserved-extended-communities-02.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the Inter-Domain Routing Working Group of
the
>IETF.
>
>	Title           : Assigned BGP extended communities
>	Author(s)       : Bruno Decraene
>                          Pierre Francois
>	Filename        :
draft-ietf-idr-reserved-extended-communities-02.txt
>	Pages           : 5
>	Date            : 2011-12-05
>
>   This document defines two IANA registries in order to assign
>   transitive and non-transitive extended communities from.  These are
>   similar to the existing well-known BGP communities defined in RFC
>   1997 but provide an easier control of inter-AS community
>   advertisement as a community could be chosen as transitive or non-
>   transitive across ASes.
>
>   For that purpose, this document defines the use of the reserved AS
>   number 0 for the transitive and non-transitive generic four-octet AS
>   specific extended community types.
>
>
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-idr-reserved-extended-
>communities-02.txt
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>This Internet-Draft can be retrieved at:
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-reserved-extended-
>communities-02.txt
>
>_______________________________________________
>Idr mailing list
>Idr@ietf.org
>https://www.ietf.org/mailman/listinfo/idr

From bruno.decraene@orange.com  Mon Dec  5 03:40:14 2011
Return-Path: 
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 ; 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 ; 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 ; 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, 5 Dec 2011 12:40:06 +0100
Message-ID: 
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><5A106376-42BC-404B-8460-BBF415049943@kumari.net> <4ED7FD2D.9000009@cisco.com>
From: 
To: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 11:40:14 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB342.A2C78EF8
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi Enke, all

=20

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.

=20

=20

2) draft-ietf-idr-rfc4893bis-04

"6. Error Handling

=20

   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."

=20

"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.

=20

Regards,

Bruno

=20

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 ?

=20

Warren:
=20
I do not agree with the new text in the draft:
=20
----
   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:=20

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

	On Sat, Nov 19, 2011 at 5:57 PM, Warren Kumari
   wrote:

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

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

		=20
		Thank you, done.
		=20

			=20
			2) The following language is not very precise.
Due to the incremental nature, we will need to remove the existing route
too.
			=20
			-----
			   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.
			-----
			=20
			   How about the following:
			=20
			   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
			=20
			draft-ietf-idr-optional-transitive-04.txt
			=20
			3) If this draft is adopted, we should also add
AS 0 as one of the error conditions in
			rfc4893bis.

		=20
		John also provided some text for that section and Keyur
suggested that we log and treat as a WITHDRAW.
		=20
		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."
		=20

	=20
	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?)

=20
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...)
=20
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...
=20
W
=20

	=20

		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...
		=20
		Thoughts?
		=20
		W
		=20
		=20

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

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

				Hello IDRites,
				=20
				I would like to draw your attention to
draft-wkumari-idr-as0-01.txt  (
=09
http://tools.ietf.org/html/draft-wkumari-idr-as0-01
				 ) - I am asking that this draft be
considered for WG adoption.
				=20
				=20
				I have already received some feedback,
mainly suggesting:
				=20
				- Add a text for AS number 0 as a
reserved in Aggregator and AS4
				Aggregator attribute
				=20
				- Add text for AS number 0 as a reserved
value in communities and
				extended communities. (RFC 1997 and
Four-octet AS Specific Extended
				Communities)
				=20
				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")).
				=20
				Anyway, I would value your feedback and
input.
				=20
				W
				=20
				=20
				=20
=09
_______________________________________________
				Idr mailing list
				=20
				Idr@ietf.org
=09
https://www.ietf.org/mailman/listinfo/idr

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

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

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

	=20

=20

=20


------_=_NextPart_001_01CCB342.A2C78EF8
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


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> =
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".
 
<=
pre>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-option=
al-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.ie=
tf.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
&nb=
sp;
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)
&nbs=
p;
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/m=
ailman/listinfo/idr
_______________=
________________________________
Idr mailing =
list
 
Idr@ietf.org
https://www.ietf.org/m=
ailman/listinfo/idr
 
 
________________________________=
_______________
Idr mailing =
list
Idr@ietf.org
https://www.ietf.org/m=
ailman/listinfo/idr
 
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/m=
ailman/listinfo/idr
 
 
 

------_=_NextPart_001_01CCB342.A2C78EF8--

From bruno.decraene@orange.com  Mon Dec  5 03:40:15 2011
Return-Path: 
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 7B7BA21F8B7A for ; Mon,  5 Dec 2011 03:40:15 -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=[AWL=-0.000, 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 4NJST2K2TGeD for ; Mon,  5 Dec 2011 03:40:12 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF0E21F8B7D for ; Mon,  5 Dec 2011 03:40:11 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B9254B58002; Mon,  5 Dec 2011 12:50:49 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id AA449B58001; Mon,  5 Dec 2011 12:50:49 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Dec 2011 12:40:11 +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.A4C10254"
Date: Mon, 5 Dec 2011 12:40:09 +0100
Message-ID: 
In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF6181C2562C4@EUSAACMS0701.eamcs.ericsson.se>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] draft-ietf-idr-as0-00 ?
Thread-Index: Acywdu+jhz14xfHFTSSkgTz3lWFsWgABJ+fwAK8MWGA=
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><5A106376-42BC-404B-8460-BBF415049943@kumari.net><4ED7FD2D.9000009@cisco.com> <0ED867EB33AB2B45AAB470D5A64CDBF6181C2562C4@EUSAACMS0701.eamcs.ericsson.se>
From: 
To: , , 
X-OriginalArrivalTime: 05 Dec 2011 11:40:11.0133 (UTC) FILETIME=[A56A6AD0:01CCB342]
Cc: idr@ietf.org
Subject: Re: [Idr] draft-ietf-idr-as0-00 ?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 11:40:15 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCB342.A4C10254
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

I agree with Enke.

=20

> Let's keep error condition and error handling separately

+1

=20

=20

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

=20

+1

=20

Let's keep error condition and error handling separately

=20

Regards,

Jeff

=20

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

=20

Warren:
=20
I do not agree with the new text in the draft:
=20
----
   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:=20

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

	On Sat, Nov 19, 2011 at 5:57 PM, Warren Kumari
   wrote:

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

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

		=20
		Thank you, done.
		=20

			=20
			2) The following language is not very precise.
Due to the incremental nature, we will need to remove the existing route
too.
			=20
			-----
			   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.
			-----
			=20
			   How about the following:
			=20
			   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
			=20
			draft-ietf-idr-optional-transitive-04.txt
			=20
			3) If this draft is adopted, we should also add
AS 0 as one of the error conditions in
			rfc4893bis.

		=20
		John also provided some text for that section and Keyur
suggested that we log and treat as a WITHDRAW.
		=20
		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."
		=20

	=20
	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?)

=20
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...)
=20
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...
=20
W
=20

	=20

		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...
		=20
		Thoughts?
		=20
		W
		=20
		=20

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

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

				Hello IDRites,
				=20
				I would like to draw your attention to
draft-wkumari-idr-as0-01.txt  (
=09
http://tools.ietf.org/html/draft-wkumari-idr-as0-01
				 ) - I am asking that this draft be
considered for WG adoption.
				=20
				=20
				I have already received some feedback,
mainly suggesting:
				=20
				- Add a text for AS number 0 as a
reserved in Aggregator and AS4
				Aggregator attribute
				=20
				- Add text for AS number 0 as a reserved
value in communities and
				extended communities. (RFC 1997 and
Four-octet AS Specific Extended
				Communities)
				=20
				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")).
				=20
				Anyway, I would value your feedback and
input.
				=20
				W
				=20
				=20
				=20
=09
_______________________________________________
				Idr mailing list
				=20
				Idr@ietf.org
=09
https://www.ietf.org/mailman/listinfo/idr

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

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

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

	=20

=20

=20


------_=_NextPart_001_01CCB342.A4C10254
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


I agree with Enke.
 
> Let’s keep error condition and error handling =
separately
+1
 
 
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of =
Jeff Tantsura
Sent: Thursday, December 01, 2011 11:52 =
PM
To: Enke Chen; Warren Kumari
Cc: =
idr@ietf.org
Subject: Re: [Idr] draft-ietf-idr-as0-00 =
?
 
+1
 
Let’s keep error condition and error handling =
separately
 
Regards,
Jeff=

 
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of =
Enke Chen
Sent: Thursday, December 01, 2011 2: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> =
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<=
/pre>
 
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.ie=
tf.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
<=
span lang=3DEN-US> ) - 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/m=
ailman/listinfo/idr
_______________________________________________
Idr mailing =
list
 
Idr@ietf.org
https://www.ietf.org/m=
ailman/listinfo/idr
 
 
_______________________________________________
Idr mailing =
list
Idr@ietf.org
https://www.ietf.org/m=
ailman/listinfo/idr
 
_______________________________________________
Idr mailing =
list
Idr@ietf.org
https://www.ietf.org/m=
ailman/listinfo/idr
 
 
 

------_=_NextPart_001_01CCB342.A4C10254--

From bruno.decraene@orange.com  Mon Dec  5 05:17:31 2011
Return-Path: 
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 75DF521F8BA0 for ; Mon,  5 Dec 2011 05:17:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Lp8sA+li3IM5 for ; Mon,  5 Dec 2011 05:17:30 -0800 (PST)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id BBA7021F8B94 for ; Mon,  5 Dec 2011 05:17:30 -0800 (PST)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B27B58C0001 for ; Mon,  5 Dec 2011 14:18:36 +0100 (CET)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 968F38B8002 for ; Mon,  5 Dec 2011 14:18:36 +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 14:17:29 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 5 Dec 2011 14:17:29 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-idr-error-handling-00
Thread-Index: AcyzUD0Xuv8TA6jEQemnW3bYz++6HA==
From: 
To: 
X-OriginalArrivalTime: 05 Dec 2011 13:17:29.0854 (UTC) FILETIME=[3D9089E0:01CCB350]
Subject: [Idr] draft-ietf-idr-error-handling-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 13:17:31 -0000

Hi,

Please find below one minor editorial comment


2. Revision to Base Specification

"  When a path attribute in an UPDATE message is determined to be
   malformed, the UPDATE message containing that attribute MUST be
   treated as [withdraw].=20
   In the case of an attribute which has no effect on route selection or
installation, the
   malformed attribute MAY instead be discarded [...]."

I'm not sure how much a "MAY" may overrule a "MUST".

I would propose the following rewording:
"When a path attribute in an UPDATE message is determined to be
   malformed, the UPDATE message containing that attribute MUST either
be
   treated as withdraw or as "attribute discard". If the attribute as an
effect on route selection or installation, it MUST be treated as
withdraw."

Regards,
Bruno

=20

From kotikalapudi.sriram@nist.gov  Mon Dec  5 05:33:50 2011
Return-Path: 
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 19ED521F8AE9 for ; Mon,  5 Dec 2011 05:33:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 SIILovenHTE7 for ; Mon,  5 Dec 2011 05:33:49 -0800 (PST)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 98F4921F8AAC for ; Mon,  5 Dec 2011 05:33:49 -0800 (PST)
Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 5 Dec 2011 08:33:46 -0500
Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 5 Dec 2011 08:33:08 -0500
From: "Sriram, Kotikalapudi" 
To: "idr@ietf.org" 
Date: Mon, 5 Dec 2011 08:33:07 -0500
Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? 
Thread-Index: AQHMs1JsUv5PkkxtUEy2u4/QcmIr0g==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 13:33:50 -0000

Yes, support.

Nits:
Acronym RTC appears in the I-D name (draft-l3vpn-legacy-rtc-00).
RTC (as an acronym) has not been used or formally defined in the document.

Sriram

----------------------------------------
>Folks,
>
>We have received a request from the authors to adopt draft-l3vpn-legacy-rtc-00 as an IDR WG document.  Please send your comments to the list.  The deadline for comments is December 5, 2011 at noon EST.

>Thanks,

>--John


From jakob.heitz@ericsson.com  Mon Dec  5 07:08:20 2011
Return-Path: 
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 1945121F899D for ; Mon,  5 Dec 2011 07:08:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 n5BEF+OEEPIl for ; Mon,  5 Dec 2011 07:08:19 -0800 (PST)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id ECF4521F849D for ; Mon,  5 Dec 2011 07:08:18 -0800 (PST)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pB5F834f026203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Dec 2011 09:08:11 -0600
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 5 Dec 2011 10:08:06 -0500
From: Jakob Heitz 
To: "bruno.decraene@orange.com" 
Date: Mon, 5 Dec 2011 10:09:25 -0500
Thread-Topic: [Idr] draft-ietf-idr-as0-00 ?
Thread-Index: AcyzX7Cm9JpSjVfoQK+IXoY0fqEqlA==
Message-ID: 
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>  <5A106376-42BC-404B-8460-BBF415049943@kumari.net> <4ED7FD2D.9000009@cisco.com> <0ED867EB33AB2B45AAB470D5A64CDBF6181C2562C4@EUSAACMS0701.eamcs.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "idr@ietf.org" 
Subject: Re: [Idr] draft-ietf-idr-as0-00 ?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Dec 2011 15:08:20 -0000

KzENCg0KLS0NCkpha29iIEhlaXR6Lg0KDQoNCk9uIERlYyA1LCAyMDExLCBhdCAzOjQxIEFNLCAi
YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNv
bT4iIDxicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFu
Z2UuY29tPj4gd3JvdGU6DQoNCkkgYWdyZWUgd2l0aCBFbmtlLg0KDQo+IExldOKAmXMga2VlcCBl
cnJvciBjb25kaXRpb24gYW5kIGVycm9yIGhhbmRsaW5nIHNlcGFyYXRlbHkNCisxDQoNCg0KRnJv
bTogaWRyLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnPiBbbWFp
bHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmVmZiBUYW50c3VyYQ0KU2Vu
dDogVGh1cnNkYXksIERlY2VtYmVyIDAxLCAyMDExIDExOjUyIFBNDQpUbzogRW5rZSBDaGVuOyBX
YXJyZW4gS3VtYXJpDQpDYzogaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+DQpTdWJq
ZWN0OiBSZTogW0lkcl0gZHJhZnQtaWV0Zi1pZHItYXMwLTAwID8NCg0KKzENCg0KTGV04oCZcyBr
ZWVwIGVycm9yIGNvbmRpdGlvbiBhbmQgZXJyb3IgaGFuZGxpbmcgc2VwYXJhdGVseQ0KDQpSZWdh
cmRzLA0KSmVmZg0KDQpGcm9tOiBpZHItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWRyLWJvdW5j
ZXNAaWV0Zi5vcmc+IFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBF
bmtlIENoZW4NClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwMSwgMjAxMSAyOjE4IFBNDQpUbzog
V2FycmVuIEt1bWFyaQ0KQ2M6IGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPg0KU3Vi
amVjdDogUmU6IFtJZHJdIGRyYWZ0LWlldGYtaWRyLWFzMC0wMCA/DQoNCg0KV2FycmVuOg0KDQoN
Cg0KSSBkbyBub3QgYWdyZWUgd2l0aCB0aGUgbmV3IHRleHQgaW4gdGhlIGRyYWZ0Og0KDQoNCg0K
LS0tLQ0KDQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGF0IGEgQkdQIHNwZWFrZXIgTVVT
VCBOT1Qgb3JpZ2luYXRlIG9yDQoNCiAgIHByb3BhZ2F0ZSBhIHJvdXRlIHdpdGggYW4gQVMgbnVt
YmVyIG9mIHplcm8uICBJZiBhIEJHUCBzcGVha2VyDQoNCiAgIHJlY2VpdmVzIGEgcm91dGUgd2hp
Y2ggaGFzIGFuIEFTIG51bWJlciBvZiB6ZXJvIGluIHRoZSBBU19QQVRIIChvcg0KDQogICBBUzRf
UEFUSCkgYXR0cmlidXRlLCBpdCBTSE9VTEQgYmUgbG9nZ2VkIGFuZCB0cmVhdGVkIGFzIGEgV0lU
SERSQVcuDQoNCiAgIFRoaXMgc2FtZSBiZWhhdmlvciBhcHBsaWVzIHRvIHJvdXRlcyBjb250YWlu
aW5nIHplcm8gYXMgdGhlDQoNCiAgIEFnZ3JlZ2F0b3Igb3IgQVM0IEFnZ3JlZ2F0b3IuDQotLS0t
LQ0KDQpUaGUgcHJlc2VuY2Ugb2YgQVMgMCBpcyBjb25zaWRlcmVkIGFzIGFuIGVycm9yLiAgVGhl
IGhhbmRsaW5nIG9mIHRoZSBlcnJvciBjb25kaXRpb24gc2hvdWxkIGJlIHNwZWNpZmljIHRvIHRo
YXQgYXR0cmlidXRlLiAgVGhhdCBpczoNCg0KICAgbyBGb3IgdGhlIEFTNF9QQVRIIGFuZCBBUzRf
QUdHUkVHQVRPUiwgdGhlIGFjdGlvbiBpcyAiYXR0cmlidXRlIGRpc2NhcmQiIGFzIHNwZWNpZmll
ZCBpbiB0aGUgcmZjNDg5M2Jpcy4NCg0KICAgbyBGb3IgdGhlIEFHR1JFR0FUT1IsIHRoZSBhY3Rp
b24gaXMgYWxzbyAiYXR0cmlidXRlIGRpc2NhcmQiIGFzIHNwZWNpZmllZCBpbiBkcmFmdC1pZXRm
LWlkci1lcnJvci1oYW5kbGluZy0wMC50eHQNCg0KDQpJIHN0aWxsIHRoaW5rIGFuZCBjb250aW51
ZSB0byByZWNvbW1lbmQgdGhhdCB5b3UgbWVyZWx5IGRlc2NyaWJlIHRoYXQgQVMgMCBpcyBhbiBl
cnJvciBjb25kaXRpb24gaW4gdGhlIGRyYWZ0LCBhbmQgbGV0IHRoZSBlcnJvciBoYW5kbGluZyBk
cmFmdCBkbyB0aGUgcmVzdCwgYXMgSSBzdWdnZXN0ZWQgYmVmb3JlOg0KDQoNCiAgIEFuIFVQREFU
RSBtZXNzYWdlIHRoYXQgY29udGFpbnMgdGhlIEFTIG51bWJlciBvZiB6ZXJvIGluIHRoZSBBUy1Q
QVRIIGF0dHJpYnV0ZQ0KDQogICBNVVNUIGJlIGNvbnNpZGVyZWQgYXMgbWFsZm9ybWVkLCBhbmQg
YmUgaGFuZGxlZCBieSB0aGUgcHJvY2VkdXJlcyBzcGVjaWZpZWQgaW4NCg0KICAgZHJhZnQtaWV0
Zi1pZHItb3B0aW9uYWwtdHJhbnNpdGl2ZS0wNC50eHQNCg0KLS0gRW5rZQ0KDQpPbiAxMi8xLzEx
IDE6NTAgUE0sIFdhcnJlbiBLdW1hcmkgd3JvdGU6DQoNClsgQ2hhbmdlZCBzdWJqZWN0IHRvIHJl
ZmxlY3QgbmV3IHRpdGxlIF0NCg0KDQoNCg0KDQpPbiBEZWMgMSwgMjAxMSwgYXQgMzozOCBQTSwg
Q2hyaXN0b3BoZXIgTW9ycm93IHdyb3RlOg0KDQoNCg0KT24gU2F0LCBOb3YgMTksIDIwMTEgYXQg
NTo1NyBQTSwgV2FycmVuIEt1bWFyaSA8d2FycmVuQGt1bWFyaS5uZXQ+PG1haWx0bzp3YXJyZW5A
a3VtYXJpLm5ldD4gd3JvdGU6DQoNCg0KDQpPbiBOb3YgMTMsIDIwMTEsIGF0IDg6MzAgUE0sIEVu
a2UgQ2hlbiB3cm90ZToNCg0KDQoNClN1cHBvcnQsIGJ1dCB3aXRoIHRoZSBmb2xsb3dpbmcgc3Vn
Z2VzdGlvbnM6DQoNCg0KDQoxKSBOaXQ6IGNoYW5nZSAiYmdwIGxpc3RlbmVyIiB0byAiYmdwIHNw
ZWFrZXIiLg0KDQoNCg0KVGhhbmsgeW91LCBkb25lLg0KDQoNCg0KDQoNCjIpIFRoZSBmb2xsb3dp
bmcgbGFuZ3VhZ2UgaXMgbm90IHZlcnkgcHJlY2lzZS4gIER1ZSB0byB0aGUgaW5jcmVtZW50YWwg
bmF0dXJlLCB3ZSB3aWxsIG5lZWQgdG8gcmVtb3ZlIHRoZSBleGlzdGluZyByb3V0ZSB0b28uDQoN
Cg0KDQotLS0tLQ0KDQogICBhIEJHUA0KDQogICBsaXN0ZW5lciBNVVNUIE5PVCBhY2NlcHQgYW4g
YW5ub3VuY2VtZW50IHdoaWNoIGhhcyBhbiBBUyBudW1iZXIgb2YNCg0KICAgemVybyBpbiB0aGUg
QVMtUEFUSCBhdHRyaWJ1dGUsIGFuZCBTSE9VTEQgbG9nIHRoZSBmYWN0IHRoYXQgaXQgaGFzDQoN
CiAgIGRvbmUgc28uDQoNCi0tLS0tDQoNCg0KDQogICBIb3cgYWJvdXQgdGhlIGZvbGxvd2luZzoN
Cg0KDQoNCiAgIEFuIFVQREFURSBtZXNzYWdlIHRoYXQgY29udGFpbnMgdGhlIEFTIG51bWJlciBv
ZiB6ZXJvIGluIHRoZSBBUy1QQVRIIGF0dHJpYnV0ZQ0KDQogICBNVVNUIGJlIGNvbnNpZGVyZWQg
YXMgbWFsZm9ybWVkLCBhbmQgYmUgaGFuZGxlZCBieSB0aGUgcHJvY2VkdXJlcyBzcGVjaWZpZWQg
aW4NCg0KDQoNCmRyYWZ0LWlldGYtaWRyLW9wdGlvbmFsLXRyYW5zaXRpdmUtMDQudHh0DQoNCg0K
DQozKSBJZiB0aGlzIGRyYWZ0IGlzIGFkb3B0ZWQsIHdlIHNob3VsZCBhbHNvIGFkZCBBUyAwIGFz
IG9uZSBvZiB0aGUgZXJyb3IgY29uZGl0aW9ucyBpbg0KDQpyZmM0ODkzYmlzLg0KDQoNCg0KSm9o
biBhbHNvIHByb3ZpZGVkIHNvbWUgdGV4dCBmb3IgdGhhdCBzZWN0aW9uIGFuZCBLZXl1ciBzdWdn
ZXN0ZWQgdGhhdCB3ZSBsb2cgYW5kIHRyZWF0IGFzIGEgV0lUSERSQVcuDQoNCg0KDQpUaGlzIHdv
dWxkIHJlYWQgYXM6DQoNCiJUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGF0IGEgQkdQIHNwZWFr
ZXIgTVVTVCBOT1Qgb3JpZ2luYXRlIG9yIHByb3BhZ2F0ZSBhIHJvdXRlIHdpdGggYW4gQVMgbnVt
YmVyIG9mIHplcm8uICBJZiBhIEJHUCBzcGVha2VyIHJlY2VpdmVzIGEgcm91dGUgd2hpY2ggaGFz
IGFuIEFTIG51bWJlciBvZiB6ZXJvIGluIHRoZSBBU19QQVRIIGF0dHJpYnV0ZSwgaXQgU0hPVUxE
IGJlIGxvZ2dlZCBhbmQgdHJlYXRlZCBhcyBhIFdJVEhEUkFXLiINCg0KDQoNCg0KDQphIHF1ZXN0
aW9uIGNhbWUgdXAgcmVjZW50bHkgKHRvZGF5KSBvbiBuYW5vZyBhYm91dCBob3cgQVMwIHNob3Vs
ZCBiZQ0KDQp0cmVhdGVkIHdydCBBR0dSRUdBVE9SIGF0dHJpYnV0ZXMuLi4gU2hvdWxkIHRoaXMg
c2F5IHVzZSBvZiBBUzANCg0KYW55d2hlcmUgKG1ha2UgYSBsaXN0IHBlcmhhcHM/KSBpcyB2ZXJi
b3Rlbj8gKG9yIHdhcyB0aGF0IGFzc3VtZWQNCg0KYWxyZWFkeT8pDQoNCg0KDQpBY3R1YWxseSBL
ZXl1ciBQYXRlbCBhbHJlYWR5IHBvaW50ZWQgb3V0IHRoZSBBZ2dyZWdhdG9yIChhbmQgQVM0IEFn
Z3JlZ2F0b3IpIGF0dHJpYnV0ZSBpc3N1ZSwgYW5kIEkgaW5jbHVkZWQgdGV4dCBpbiB0aGUgV0cg
dmVyc2lvbiBvZiB0aGUgZG9jLCB3aGljaCBJIHBvc3RlZCByZWNlbnRseSAoYWx0aG91Z2ggSSBo
YXZlIGp1c3QgcmVhbGl6ZWQgdGhhdCBJIGVudGVyZWQgdGhlIHRleHQgYXMgIkFnZ3JlZ2F0b3Ii
IGFuZCBub3QgIkFHR1JFR0FUT1IiLCBzYW1lIGZvciBBUzQuLi4pDQoNCg0KDQpXaGljaCByZW1p
bmRzIG1lIC0tIHdvdWxkIGZvbGsgcGxlYXNlIHJldmlldyBkcmFmdC1pZXRmLWlkci1hczAtMDAg
KCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1hczAtMDAgKSBhbmQg
cHJvdmlkZSBmZWVkYmFjaz8NCg0KSSAqdGhpbmsqIHRoYXQgSSBpbmNvcnBvcmF0ZWQgZXZlcnlv
bmVzIGNvbW1lbnRzLCBhbHRob3VnaCBJIGFjY2lkZW50YWxseSBvdmVyd3JvdGUgdGhlIGNoYW5n
ZWQgdmVyc2lvbiB3aXRoIGFuIG9sZGVyIHZlcnNpb24gKG5ldmVyIGVkaXQgYSBmaWxlIGluIHR3
byBlZGl0b3JzIGF0IG9uY2UgOi0pKSBhbmQgc28gbWF5IGhhdmUgbWlzc2VkIHNvbWUuLi4NCg0K
DQoNClcNCg0KDQoNCg0KDQpUaGlzIGF2b2lkcyBoYXZpbmcgYSBub3JtYXRpdmUgcmV2ZXJlbmNl
IHRvIHRoZSBvcHRpb25hbC10cmFuc2l0aXZlIGRyYWZ0IGFuZCBpcyAoSU1PKSBhIGxpdHRsZSBj
bGVhcmVyLiBJdCBhbHNvIHNhdmVzIG9wdGlvbmFsLXRyYW5zaXRpdmUgZnJvbSByZWZlcmVuY2lu
ZyB0aGlzLCBhbmQgc28gd2UgYXZvaWQgdGhlIGRlYWRsb2NrLi4uDQoNCg0KDQpUaG91Z2h0cz8N
Cg0KDQoNClcNCg0KDQoNCg0KDQoNCg0KVGhhbmtzLiAgIC0tIEVua2UNCg0KDQoNCg0KDQpPbiAx
MC8yOC8xMSAxOjUxIFBNLCBKb2huIFNjdWRkZXIgd3JvdGU6DQoNCkZvbGtzLA0KDQoNCg0KUGxl
YXNlIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QgcHJpb3IgdG8gdGhlIElEUiBtZWV0aW5nIG9u
IE5vdmVtYmVyIDE1Lg0KDQoNCg0KVGhhbmtzLA0KDQoNCg0KLS1Kb2huDQoNCg0KDQpPbiBPY3Qg
MjcsIDIwMTEsIGF0IDk6MjkgQU0sIFdhcnJlbiBLdW1hcmkgd3JvdGU6DQoNCg0KDQoNCg0KSGVs
bG8gSURSaXRlcywNCg0KDQoNCkkgd291bGQgbGlrZSB0byBkcmF3IHlvdXIgYXR0ZW50aW9uIHRv
IGRyYWZ0LXdrdW1hcmktaWRyLWFzMC0wMS50eHQgICgNCg0KaHR0cDovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtd2t1bWFyaS1pZHItYXMwLTAxDQoNCiApIC0gSSBhbSBhc2tpbmcgdGhhdCB0
aGlzIGRyYWZ0IGJlIGNvbnNpZGVyZWQgZm9yIFdHIGFkb3B0aW9uLg0KDQoNCg0KDQoNCkkgaGF2
ZSBhbHJlYWR5IHJlY2VpdmVkIHNvbWUgZmVlZGJhY2ssIG1haW5seSBzdWdnZXN0aW5nOg0KDQoN
Cg0KLSBBZGQgYSB0ZXh0IGZvciBBUyBudW1iZXIgMCBhcyBhIHJlc2VydmVkIGluIEFnZ3JlZ2F0
b3IgYW5kIEFTNA0KDQpBZ2dyZWdhdG9yIGF0dHJpYnV0ZQ0KDQoNCg0KLSBBZGQgdGV4dCBmb3Ig
QVMgbnVtYmVyIDAgYXMgYSByZXNlcnZlZCB2YWx1ZSBpbiBjb21tdW5pdGllcyBhbmQNCg0KZXh0
ZW5kZWQgY29tbXVuaXRpZXMuIChSRkMgMTk5NyBhbmQgRm91ci1vY3RldCBBUyBTcGVjaWZpYyBF
eHRlbmRlZA0KDQpDb21tdW5pdGllcykNCg0KDQoNCkFsc28gc3VnZ2VzdGVkIHdhcyBwcm92aWRp
bmcgYSBsaXR0bGUgbW9yZSBpbmZvcm1hdGlvbiBvbiB3aGF0IHRvIGRvIGl0IHlvdSBkbyByZWNl
aXZlIGEgcm91dGUgY29udGFpbmluZyBBUzAgIChtb3JlIGRlc2NyaXB0aXZlIHRoYW4ganVzdCAi
TVVTVCBOT1QgYWNjZXB0IiAoZm9yIGV4YW1wbGUsIHN0YXRpbmcgdGhhdCBpdCBzaG91bGQgYmUg
ImV4Y2x1ZGVkIGZyb20gdGhlIFBoYXNlIDIgZGVjaXNpb24gZnVuY3Rpb24iKSkuDQoNCg0KDQpB
bnl3YXksIEkgd291bGQgdmFsdWUgeW91ciBmZWVkYmFjayBhbmQgaW5wdXQuDQoNCg0KDQpXDQoN
Cg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQoNCklkciBtYWlsaW5nIGxpc3QNCg0KDQoNCklkckBpZXRmLm9yZzxtYWlsdG86SWRyQGll
dGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpJZHIgbWFp
bGluZyBsaXN0DQoNCg0KDQpJZHJAaWV0Zi5vcmc8bWFpbHRvOklkckBpZXRmLm9yZz4NCg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0KDQoNCg0KDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpJZHIgbWFpbGluZyBs
aXN0DQoNCklkckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KSWRyIG1haWxpbmcgbGlzdA0KDQpJZHJAaWV0
Zi5vcmc8bWFpbHRvOklkckBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9pZHINCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYub3JnPG1haWx0bzpJ
ZHJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K

From internet-drafts@ietf.org  Mon Dec  5 16:31:53 2011
Return-Path: 
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 BF71411E80D1; Mon,  5 Dec 2011 16:31:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.578
X-Spam-Level: 
X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 YpVRxM2wW5V2; Mon,  5 Dec 2011 16:31:53 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A1111E80C1; Mon,  5 Dec 2011 16:31:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64
Message-ID: <20111206003153.3158.68168.idtracker@ietfa.amsl.com>
Date: Mon, 05 Dec 2011 16:31:53 -0800
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-dynamic-cap-14.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Dec 2011 00:31:53 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Inter-Domain Routing Working Group of=
 the IETF.

	Title           : Dynamic Capability for BGP-4
	Author(s)       : Enke Chen
                          Srihari R. Sangli
	Filename        : draft-ietf-idr-dynamic-cap-14.txt
	Pages           : 7
	Date            : 2011-12-05

   This document defines a new BGP capability termed "Dynamic
   Capability", which would allow the dynamic update of capabilities
   over an established BGP session. This capability would facilitate
   non-disruptive capability changes by BGP speakers.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-dynamic-cap-14.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-dynamic-cap-14.txt


From stephane.litkowski@orange.com  Tue Dec  6 02:59:58 2011
Return-Path: 
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 F151921F8B21 for ; Tue,  6 Dec 2011 02:59:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
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 0oVmIrZarNKt for ; Tue,  6 Dec 2011 02:59:58 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D0A1E21F8B0F for ; Tue,  6 Dec 2011 02:59:57 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 8DDB1324671; Tue,  6 Dec 2011 11:59:54 +0100 (CET)
Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 716DD35C055; Tue,  6 Dec 2011 11:59:54 +0100 (CET)
Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Dec 2011 11:59:54 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 6 Dec 2011 11:59:53 +0100
Message-ID: <15769_1323169194_4EDDF5AA_15769_19867_1_4FC3556A36EE3646A09DAA60429F53350769DE77@PUEXCBL0.nanterre.francetelecom.fr>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)
Thread-Index: Acyx4DwplQR0rIFxT3yUB+O/FN824wCJVVFA
References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se><26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org> 
From: 
To: "Brian Dickson" , "Daniel Ginsburg" 
X-OriginalArrivalTime: 06 Dec 2011 10:59:54.0662 (UTC) FILETIME=[2F7FF460:01CCB406]
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.6.95414
Cc: idr@ietf.org, nanog@nanog.org
Subject: Re: [Idr] draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Dec 2011 10:59:59 -0000

Hi all,

Just a quick feedback about "no-aggregator-id" option on Juniper.
Brian, it seems to work already as you proposed, it's zeroing only the rout=
er ID , not the AS. And IMHO, by zeroing only the router ID, the non duplic=
ate update behavior which was expected by the feature is working well.

Moreover this is how it is described in JUNOS doc :
"Set the router ID in the BGP aggregator path attribute to zero. (This is o=
ne of the path attributes included in BGP update messages.) Doing this prev=
ents different routing devices within an AS from creating aggregate routes =
that contain different AS paths"


Here is a lab example :

Without the knob :

Dec  6 11:52:27.697866 BGP SEND x.x.x.x+179 -> y.y.y.y+23415
Dec  6 11:52:27.697873 BGP SEND message type 2 (Update) length 56
Dec  6 11:52:27.697879 BGP SEND Update PDU length 56
Dec  6 11:52:27.699070 BGP SEND flags 0x40 code Origin(1): IGP
Dec  6 11:52:27.699078 BGP SEND flags 0x40 code ASPath(2) length 0: 
Dec  6 11:52:27.699084 BGP SEND flags 0x40 code NextHop(3): x.x.x.x
Dec  6 11:52:27.699089 BGP SEND flags 0x40 code LocalPref(5): 100
Dec  6 11:52:27.699095 BGP SEND flags 0xc0 code Aggregator(7): 64532 81.52.=
26.126
Dec  6 11:52:27.699108 BGP SEND         54.54.0.0/16

With the knob :

Dec  6 11:54:02.968636 BGP SEND x.x.x.x+179 -> y.y.y.y+23415
Dec  6 11:54:02.968643 BGP SEND message type 2 (Update) length 56
Dec  6 11:54:02.968649 BGP SEND Update PDU length 56
Dec  6 11:54:02.968655 BGP SEND flags 0x40 code Origin(1): IGP
Dec  6 11:54:02.968661 BGP SEND flags 0x40 code ASPath(2) length 0: 
Dec  6 11:54:02.968666 BGP SEND flags 0x40 code NextHop(3): x.x.x.x
Dec  6 11:54:02.968671 BGP SEND flags 0x40 code LocalPref(5): 100
Dec  6 11:54:02.968681 BGP SEND flags 0xc0 code Aggregator(7): 64532 0.0.0.0
Dec  6 11:54:02.968690 BGP SEND         54.54.0.0/16=20

Hope it helps,


-----Message d'origine-----
De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la part de Brian=
 Dickson
Envoy=E9 : samedi 3 d=E9cembre 2011 18:23
=C0 : Daniel Ginsburg
Cc : idr@ietf.org; nanog@nanog.org
Objet : Re: [Idr] draft-ietf-idr-as0-00 (bgp update destroying transit on r=
edback routers ?)

Can anyone familiar with this knob and its usage, answer a question:

Would anything break, in terms of use of that knob, if instead of "zeroing"=
 the AGGREGATOR, the local AS (as seen from the outside world, in the case =
of confederations) were used?

Would the functionality of the knob, in reducing updates, be preserved?

Would routes be considered malformed or would it trigger any other bad beha=
vior?

Perhaps this is a way of resolving the conflict between this knob and the A=
S0 draft?

Brian

On Fri, Dec 2, 2011 at 8:12 AM, Daniel Ginsburg  wrote:
> Hi,
>
> This is true that "no-aggregator-id" knob zeroes out the AGGREGATOR attri=
bute.
>
> The knob, as far as I was able to find out, dates back to gated and there=
's a reason why it was introduced - it helps to avoid unnecessary updates. =
Assume that an aggregate route is generated by two (or more) speakers in th=
e network. These two aggregates differ only in AGGREGATOR attribute. One of=
 the aggregates is preferred within the network (due to IGP metric, for ins=
tance, or any other reasons) and is announced out. Now if something changes=
 within the network and the other instance of the aggregate becomes preferr=
ed, the network has to issue an outward update different from the previous =
only in AGGREGATOR attribute, which is completely superfluous.
>
> If the network employs the "no-aggregator-id" knob to zero out the AGGREG=
ATOR attribute, both instances of the aggregate route are completely equiva=
lent, and no redundant outward updates have to be send if one instance beco=
mes better than another due to some internal event, which nobody in the Int=
ernet cares about.
>
> In other words, the "no-aggregator-id" knob has valid operational reasons=
 to be used. And, IMHO, the draft-ietf-idr-as0-00 should not prohibit AS0 i=
n AGGREGATOR attribute.
>
> On 02.12.2011, at 1:56, Jeff Tantsura wrote:
>
>> Hi,
>>
>> Let me take it over from now on, I'm the IP Routing/MPLS Product Manager=
 at Ericsson responsible for all routing protocols.
>> There's nothing wrong in checking ASN in AGGREGATOR, we don't really wan=
t see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-=
00) came into the worlds.
>>
>> To my knowledge - the only vendor which allows changing ASN in AGGREGATO=
R is Juniper, see "no-aggregator-id", in the past I've tried to talk to Yak=
ov about it, without any results though.
>> So for those who have it configured - please rethink whether you really =
need it.
>>
>> As for SEOS - understanding that this badly affects our customers and no=
t having draft-ietf-idr-error-handling fully implemented yet, we will tempo=
rarily disable this check in our code.
>> Patch will be made available.
>>
>> Please contact me for any further clarifications.
>>
>> Regards,
>> Jeff
>>
>> P.S. Warren has recently =A0included AGGREGATOR in the draft, please=20
>> see
>>
>> 2. Behavior
>> =A0 This document specifies that a BGP speaker MUST NOT originate or
>> =A0 propagate a route with an AS number of zero. =A0If a BGP speaker
>> =A0 receives a route which has an AS number of zero in the AS_PATH (or
>> =A0 AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW.
>> =A0 This same behavior applies to routes containing zero as the
>> =A0 Aggregator or AS4 Aggregator.
>>
>
> _______________________________________________
> 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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,=20
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;=20
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.=20
As emails may be altered, France Telecom - Orange shall not be liable if th=
is message was modified, changed or falsified.
Thank you.


From stephane.litkowski@orange.com  Tue Dec  6 06:02:38 2011
Return-Path: 
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 7F62121F8B23 for ; Tue,  6 Dec 2011 06:02:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
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 auxF61ndsfnW for ; Tue,  6 Dec 2011 06:02:37 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6169821F8B30 for ; Tue,  6 Dec 2011 06:02:37 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 5E5882DC518 for ; Tue,  6 Dec 2011 15:02:35 +0100 (CET)
Received: from puexcc41.nanterre.francetelecom.fr (unknown [10.168.74.60]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 45892238061 for ; Tue,  6 Dec 2011 15:02:35 +0100 (CET)
Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc41.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Dec 2011 15:02:35 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 6 Dec 2011 15:02:34 +0100
Message-ID: <22504_1323180155_4EDE207B_22504_2442_1_4FC3556A36EE3646A09DAA60429F53350769E00D@PUEXCBL0.nanterre.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)
Thread-Index: Acyx4DwplQR0rIFxT3yUB+O/FN824wCJVVFAAAaGGiA=
From: 
To: 
X-OriginalArrivalTime: 06 Dec 2011 14:02:35.0141 (UTC) FILETIME=[B4745350:01CCB41F]
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.6.123314
Subject: [Idr] TR: draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Dec 2011 14:02:38 -0000

Hi all,

Just a quick feedback about "no-aggregator-id" option on Juniper.
Brian, it seems to work already as you proposed, it's zeroing only the rout=
er ID , not the AS. And IMHO, by zeroing only the router ID, the non duplic=
ate update behavior which was expected by the feature is working well.

Moreover this is how it is described in JUNOS doc :
"Set the router ID in the BGP aggregator path attribute to zero. (This is o=
ne of the path attributes included in BGP update messages.) Doing this prev=
ents different routing devices within an AS from creating aggregate routes =
that contain different AS paths"


Here is a lab example :

Without the knob :

Dec  6 11:52:27.697866 BGP SEND x.x.x.x+179 -> y.y.y.y+23415 Dec  6 11:52:2=
7.697873 BGP SEND message type 2 (Update) length 56 Dec  6 11:52:27.697879 =
BGP SEND Update PDU length 56 Dec  6 11:52:27.699070 BGP SEND flags 0x40 co=
de Origin(1): IGP Dec  6 11:52:27.699078 BGP SEND flags 0x40 code ASPath(2)=
 length 0:  Dec  6 11:52:27.699084 BGP SEND flags 0x40 code NextHop(3=
): x.x.x.x Dec  6 11:52:27.699089 BGP SEND flags 0x40 code LocalPref(5): 10=
0 Dec  6 11:52:27.699095 BGP SEND flags 0xc0 code Aggregator(7): 64532 81.5=
2.26.126
Dec  6 11:52:27.699108 BGP SEND         54.54.0.0/16

With the knob :

Dec  6 11:54:02.968636 BGP SEND x.x.x.x+179 -> y.y.y.y+23415 Dec  6 11:54:0=
2.968643 BGP SEND message type 2 (Update) length 56 Dec  6 11:54:02.968649 =
BGP SEND Update PDU length 56 Dec  6 11:54:02.968655 BGP SEND flags 0x40 co=
de Origin(1): IGP Dec  6 11:54:02.968661 BGP SEND flags 0x40 code ASPath(2)=
 length 0:  Dec  6 11:54:02.968666 BGP SEND flags 0x40 code NextHop(3=
): x.x.x.x Dec  6 11:54:02.968671 BGP SEND flags 0x40 code LocalPref(5): 10=
0 Dec  6 11:54:02.968681 BGP SEND flags 0xc0 code Aggregator(7): 64532 0.0.=
0.0
Dec  6 11:54:02.968690 BGP SEND         54.54.0.0/16=20

Hope it helps,


-----Message d'origine-----
De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la part de Brian=
 Dickson Envoy=E9 : samedi 3 d=E9cembre 2011 18:23 =C0 : Daniel Ginsburg Cc=
 : idr@ietf.org; nanog@nanog.org Objet : Re: [Idr] draft-ietf-idr-as0-00 (b=
gp update destroying transit on redback routers ?)

Can anyone familiar with this knob and its usage, answer a question:

Would anything break, in terms of use of that knob, if instead of "zeroing"=
 the AGGREGATOR, the local AS (as seen from the outside world, in the case =
of confederations) were used?

Would the functionality of the knob, in reducing updates, be preserved?

Would routes be considered malformed or would it trigger any other bad beha=
vior?

Perhaps this is a way of resolving the conflict between this knob and the A=
S0 draft?

Brian

On Fri, Dec 2, 2011 at 8:12 AM, Daniel Ginsburg  wrote:
> Hi,
>
> This is true that "no-aggregator-id" knob zeroes out the AGGREGATOR attri=
bute.
>
> The knob, as far as I was able to find out, dates back to gated and there=
's a reason why it was introduced - it helps to avoid unnecessary updates. =
Assume that an aggregate route is generated by two (or more) speakers in th=
e network. These two aggregates differ only in AGGREGATOR attribute. One of=
 the aggregates is preferred within the network (due to IGP metric, for ins=
tance, or any other reasons) and is announced out. Now if something changes=
 within the network and the other instance of the aggregate becomes preferr=
ed, the network has to issue an outward update different from the previous =
only in AGGREGATOR attribute, which is completely superfluous.
>
> If the network employs the "no-aggregator-id" knob to zero out the AGGREG=
ATOR attribute, both instances of the aggregate route are completely equiva=
lent, and no redundant outward updates have to be send if one instance beco=
mes better than another due to some internal event, which nobody in the Int=
ernet cares about.
>
> In other words, the "no-aggregator-id" knob has valid operational reasons=
 to be used. And, IMHO, the draft-ietf-idr-as0-00 should not prohibit AS0 i=
n AGGREGATOR attribute.
>
> On 02.12.2011, at 1:56, Jeff Tantsura wrote:
>
>> Hi,
>>
>> Let me take it over from now on, I'm the IP Routing/MPLS Product Manager=
 at Ericsson responsible for all routing protocols.
>> There's nothing wrong in checking ASN in AGGREGATOR, we don't really wan=
t see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-=
00) came into the worlds.
>>
>> To my knowledge - the only vendor which allows changing ASN in AGGREGATO=
R is Juniper, see "no-aggregator-id", in the past I've tried to talk to Yak=
ov about it, without any results though.
>> So for those who have it configured - please rethink whether you really =
need it.
>>
>> As for SEOS - understanding that this badly affects our customers and no=
t having draft-ietf-idr-error-handling fully implemented yet, we will tempo=
rarily disable this check in our code.
>> Patch will be made available.
>>
>> Please contact me for any further clarifications.
>>
>> Regards,
>> Jeff
>>
>> P.S. Warren has recently =A0included AGGREGATOR in the draft, please=20
>> see
>>
>> 2. Behavior
>> =A0 This document specifies that a BGP speaker MUST NOT originate or
>> =A0 propagate a route with an AS number of zero. =A0If a BGP speaker
>> =A0 receives a route which has an AS number of zero in the AS_PATH (or
>> =A0 AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW.
>> =A0 This same behavior applies to routes containing zero as the
>> =A0 Aggregator or AS4 Aggregator.
>>
>
> _______________________________________________
> 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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou =
copies sans autorisation. Si vous avez recu ce message par erreur, veuillez=
 le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le=
s messages electroniques etant susceptibles d'alteration, France Telecom - =
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law; they should not be distributed, used=
 or copied without authorization. If you have received this email in error,=
 please notify the sender and delete this message and its attachments. As e=
mails may be altered, France Telecom - Orange shall not be liable if this m=
essage was modified, changed or falsified. Thank you.



From fazmemon@live.co.uk  Thu Nov 24 06:22:25 2011
Return-Path: 
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 D87FA21F8C20 for ; Thu, 24 Nov 2011 06:22:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level: 
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619]
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 Qmg4wIE3i+T9 for ; Thu, 24 Nov 2011 06:22:25 -0800 (PST)
Received: from bay0-omc3-s16.bay0.hotmail.com (bay0-omc3-s16.bay0.hotmail.com [65.54.190.154]) by ietfa.amsl.com (Postfix) with ESMTP id 74CFF21F8BA8 for ; Thu, 24 Nov 2011 06:22:25 -0800 (PST)
Received: from BAY152-DS17 ([65.54.190.189]) by bay0-omc3-s16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 24 Nov 2011 06:22:24 -0800
X-Originating-IP: [213.46.252.136]
X-Originating-Email: [fazmemon@live.co.uk]
Message-ID: 
From: Faz Memon 
To: 
References: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> 
In-Reply-To: 
Date: Thu, 24 Nov 2011 15:22:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGflrncnxKuaeF4JPW1RLKURuXbRgKp8ZuNAhmolXaV8B6i8A==
Content-Language: en-gb
X-OriginalArrivalTime: 24 Nov 2011 14:22:24.0641 (UTC) FILETIME=[7C7E9F10:01CCAAB4]
X-Mailman-Approved-At: Tue, 06 Dec 2011 12:35:25 -0800
Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG	document?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 14:23:56 -0000

support=20
> > -----Original Message-----
> > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf =
Of
> > Anton Elita
> > Sent: 23 November 2011 17:05
> > To: idr@ietf.org List
> > Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as =
IDR
> > WG document?
> >
> > Support
> >
> > --
> >  Anton Elita
> >  Tinet
> >
> >
> >
> >
> >
> > On Wed, Nov 16, 2011 at 10:06 AM, John Scudder 
> wrote:
> > > Folks,
> > >
> > > We have received a request from the authors to adopt
> > > draft-varlashkin-
> > bgp-nh-cost-02 as an IDR WG document. =A0Please send your comments =
to
> > the list.. =A0The deadline for comments is December 5, 2011 at noon =
EST.
> > >
> > > Thanks,
> > >
> > > --John
> > > _______________________________________________
> > > 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


From enkechen@cisco.com  Tue Dec  6 15:46:28 2011
Return-Path: 
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 9269021F8BE4 for ; Tue,  6 Dec 2011 15:46:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, 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 SQGOCFFvhUwv for ; Tue,  6 Dec 2011 15:46:28 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id F029D21F8BE8 for ; Tue,  6 Dec 2011 15:46:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=1317; q=dns/txt; s=iport; t=1323215188; x=1324424788; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=h71qR5I8eimn3hAGXy7Cgizh6cLRVJRLz0z0dz542+U=; b=axwHGmrcy3xkAy+1N0lEh+oYEO+vd99jrbrP6FxYvD0r5XN1QKU71RZY MwFquB1Fhm3PwY+2pCx8S+bBiPWHWgSskywosnSK0M3/x1YNmVvb4q2oj iWgtR7SL8ZpsHfjTnLhe/gfgMtwLP2UAgVi2d4GG63VlgqVeW6mBE4v33 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAFmo3k6rRDoG/2dsb2JhbABDql6BBYFyAQEBBAEBAQ8BJTYKAQwECxEDAQIBCRYPCQMCAQIBFSgIEwEFAgEBHodtlyEBnkkEiBqDGASILow4kkE
X-IronPort-AV: E=Sophos;i="4.71,309,1320624000"; d="scan'208";a="18179366"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 06 Dec 2011 23:46:27 +0000
Received: from dhcp-171-71-139-230.cisco.com (dhcp-171-71-139-230.cisco.com [171.71.139.230]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pB6NkRrA010707; Tue, 6 Dec 2011 23:46:27 GMT
Message-ID: <4EDEA9E0.4080201@cisco.com>
Date: Tue, 06 Dec 2011 15:48:48 -0800
From: Enke Chen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: shares@ndzh.com
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>  <5A106376-42BC-404B-8460-BBF415049943@kumari.net> <4ED7FD2D.9000009@cisco.com> <48E559E7-B92D-429F-868F-57DC3BD19AF7@tcb.net> <304373944-1323214859-cardhu_decombobulator_blackberry.rim.net-530292776-@b3.c6.bise6.blackberry>
In-Reply-To: <304373944-1323214859-cardhu_decombobulator_blackberry.rim.net-530292776-@b3.c6.bise6.blackberry>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf. org" , Danny McPherson 
Subject: Re: [Idr] draft-ietf-idr-as0-00 ?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Dec 2011 23:46:28 -0000

Sue,

Sure, we can certainly do that if that is what the chairs want us to do.

Basically,  we can list AS 0 as an additional error condition for the 
AS-PATH attribute.

-- Enke

On 12/6/11 3:40 PM, shares@ndzh.com wrote:
> Enke:
>
> Are you willing to incorporate the as 0 hanlong in your error draft?
>
> Sue
> Sent via BlackBerry by AT&T
>
> -----Original Message-----
> From: Danny McPherson
> Sender: idr-bounces@ietf.org
> Date: Thu, 1 Dec 2011 20:56:20
> To: Enke Chen; Warren Kumari
> Cc: idr@ietf.org List
> Subject: Re: [Idr] draft-ietf-idr-as0-00 ?
>
>
> I agre with Enke here as well...
>
> -danny
>
>
> On Dec 1, 2011, at 5:18 PM, Enke Chen wrote:
>
>> 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
>>
>>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From bruno.decraene@orange.com  Wed Dec  7 07:38:41 2011
Return-Path: 
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 9922421F8B47 for ; Wed,  7 Dec 2011 07:38:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 nSb9-REinPtn for ; Wed,  7 Dec 2011 07:38:40 -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 8942F21F8B26 for ; Wed,  7 Dec 2011 07:38:40 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F23E1FC4005 for ; Wed,  7 Dec 2011 16:38:37 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id E99DBFC4003 for ; Wed,  7 Dec 2011 16:38:37 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 7 Dec 2011 16:38:37 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 7 Dec 2011 16:38:36 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-idr-custom-decision-00
Thread-Index: Acy09kkjhJxILug2QpCW5Yh41i4R2g==
From: 
To: 
X-OriginalArrivalTime: 07 Dec 2011 15:38:37.0868 (UTC) FILETIME=[49B86EC0:01CCB4F6]
Subject: [Idr] draft-ietf-idr-custom-decision-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 15:38:41 -0000

Alvaro, Russ, all

Draft says:

"  If the non-transitive version of a Cost Community is received across
   an Autonomous System boundary, then the receiver SHOULD strip it off
   the BGP update, and ignore it when running the selection process."

1) IMHO, for consistency, the handling of non-transitive community,
should be defined in a single document (rfc4360) rather than in each
document defining a new extended community.

2) There has been some discussion regarding the handling of non
transitive community over an eBGP session:
http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00
presented in IETF 76. The feeling I got at the time, was that the
intention of RFC 4360 was to prohibit the propagation to an eBGP session
of a non-transitive community being in the loc_RIB. But that it was
possible to set a non-transitive attribute in the outbound policy of an
eBGP session. --> hence the eBGP peer should not remove the received
non-transitive community

(for reference RFC 4360 says "If a route has a non-transitivity extended
community, then before advertising the route across the Autonomous
System boundary the community SHOULD be removed from the route.")


Hence, would you consider removing the above sentence from the draft?

Thanks,
Regards,
Bruno

From robert@raszuk.net  Wed Dec  7 14:12:14 2011
Return-Path: 
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 990B321F8B0E for ; Wed,  7 Dec 2011 14:12:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 S2IoswhRwSZm for ; Wed,  7 Dec 2011 14:12:13 -0800 (PST)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id A68BD21F8B08 for ; Wed,  7 Dec 2011 14:12:13 -0800 (PST)
Received: (qmail 27244 invoked by uid 399); 7 Dec 2011 22:12:12 -0000
Received: from unknown (HELO ?192.168.124.179?) (200.211.176.90) by mail1310.opentransfer.com with ESMTP; 7 Dec 2011 22:12:12 -0000
X-Originating-IP: 200.211.176.90
Message-ID: <4EDFE4BD.6010609@raszuk.net>
Date: Wed, 07 Dec 2011 23:12:13 +0100
From: Robert Raszuk 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: bruno.decraene@orange.com, idr@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Idr] draft-ietf-idr-custom-decision-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 22:12:14 -0000

Hi Bruno,

I think you are bringing a very important topic - however I think I am 
not in line with your suggestion.

As we have discussed in Prague there is general need to handle 
customizations for best path selection. Such customization may be 
required to span domains. So rather then remove anything how the 
non-transitive community should be handled I would rather see proposal 
how to make safely cost community to be transitive across domains.

Once we do that proposals like AIGP would be automatically addressed by 
operator's configuration without any need for new drafts or RFCs.

Best regards,
R.

> Alvaro, Russ, all
>
> Draft says:
>
> "  If the non-transitive version of a Cost Community is received across
>     an Autonomous System boundary, then the receiver SHOULD strip it off
>     the BGP update, and ignore it when running the selection process."
>
> 1) IMHO, for consistency, the handling of non-transitive community,
> should be defined in a single document (rfc4360) rather than in each
> document defining a new extended community.
>
> 2) There has been some discussion regarding the handling of non
> transitive community over an eBGP session:
> http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00
> presented in IETF 76. The feeling I got at the time, was that the
> intention of RFC 4360 was to prohibit the propagation to an eBGP session
> of a non-transitive community being in the loc_RIB. But that it was
> possible to set a non-transitive attribute in the outbound policy of an
> eBGP session. -->  hence the eBGP peer should not remove the received
> non-transitive community
>
> (for reference RFC 4360 says "If a route has a non-transitivity extended
> community, then before advertising the route across the Autonomous
> System boundary the community SHOULD be removed from the route.")
>
>
> Hence, would you consider removing the above sentence from the draft?
>
> Thanks,
> Regards,
> Bruno
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>


From bruno.decraene@orange.com  Thu Dec  8 00:46:53 2011
Return-Path: 
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 82CEA21F8AAA for ; Thu,  8 Dec 2011 00:46:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 c4Nk3m-Lky4V for ; Thu,  8 Dec 2011 00:46:53 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4EA21F8610 for ; Thu,  8 Dec 2011 00:46:52 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 989AC858004; Thu,  8 Dec 2011 09:57:32 +0100 (CET)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 90393858001; Thu,  8 Dec 2011 09:57:32 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 8 Dec 2011 09:46:50 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 8 Dec 2011 09:46:49 +0100
Message-ID: 
In-Reply-To: <4EDFE4BD.6010609@raszuk.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] draft-ietf-idr-custom-decision-00
Thread-Index: Acy1LVnSEhYEN1S1Qo+YxIvUI3bIIwAVDwzQ
References:  <4EDFE4BD.6010609@raszuk.net>
From: 
To: , 
X-OriginalArrivalTime: 08 Dec 2011 08:46:50.0507 (UTC) FILETIME=[ED6615B0:01CCB585]
Subject: Re: [Idr] draft-ietf-idr-custom-decision-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 08:46:53 -0000

Hi Robert, all

>From: Robert Raszuk [mailto:robert@raszuk.net] Sent: Wednesday,
December 07, 2011 11:12 PM
>
>Hi Bruno,
>
>I think you are bringing a very important topic - however I think I am
>not in line with your suggestion.
>
>As we have discussed in Prague there is general need to handle
>customizations for best path selection.

Ok.

> Such customization may be required to span domains.=20

Agreed.

>So rather then remove anything how the
>non-transitive community should be handled I would rather see proposal
>how to make safely cost community to be transitive across domains.

- I'm not proposing to remove anything on how non-transitive communities
are to be handled. I'm proposing the behavior be agreed on and specified
in a single document: RFC 4360(bis)
- Note that idr-customer-decision proposes to reserve 2 opaque extended
community types: one transitive and one non transitive. So the
transitive one is already a way to have the cost community usable across
domains.
- Finally, my proposition goes in the direction you ask (make the cost
community be usable across domain) as it remove a restriction for using
it on eBGP sessions.=20

>Once we do that proposals like AIGP would be automatically addressed by
operator's configuration without any need for new drafts or RFCs.

That's completely orthogonal to my comment.
My point is that extended communities are already specified in RFC 4360.
So either the extended community is the right tool for custom-decision
or it's not. That is up to authors of draft-ietf-idr-custom-decision.
IMHO, what is not is redefining how (non-transitive) extended
communities are to be handled. That is of course a personal opinion
only, it's up to the WG/chairs to decide.

Best regards,
Bruno

>Best regards,
>R.
>
>> Alvaro, Russ, all
>>
>> Draft says:
>>
>> "  If the non-transitive version of a Cost Community is received
across
>>     an Autonomous System boundary, then the receiver SHOULD strip it
off
>>     the BGP update, and ignore it when running the selection
process."
>>
>> 1) IMHO, for consistency, the handling of non-transitive community,
>> should be defined in a single document (rfc4360) rather than in each
>> document defining a new extended community.
>>
>> 2) There has been some discussion regarding the handling of non
>> transitive community over an eBGP session:
>>
http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00
>> presented in IETF 76. The feeling I got at the time, was that the
>> intention of RFC 4360 was to prohibit the propagation to an eBGP
session
>> of a non-transitive community being in the loc_RIB. But that it was
>> possible to set a non-transitive attribute in the outbound policy of
an
>> eBGP session. -->  hence the eBGP peer should not remove the received
>> non-transitive community
>>
>> (for reference RFC 4360 says "If a route has a non-transitivity
extended
>> community, then before advertising the route across the Autonomous
>> System boundary the community SHOULD be removed from the route.")
>>
>>
>> Hence, would you consider removing the above sentence from the draft?
>>
>> Thanks,
>> Regards,
>> Bruno
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>>


From bruno.decraene@orange.com  Thu Dec  8 01:22:04 2011
Return-Path: 
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 B8AF921F888A for ; Thu,  8 Dec 2011 01:22:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 gExZR9LAoOfl for ; Thu,  8 Dec 2011 01:22:04 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2063421F869E for ; Thu,  8 Dec 2011 01:22:04 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 72027858003 for ; Thu,  8 Dec 2011 10:32:45 +0100 (CET)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 63FA1858001 for ; Thu,  8 Dec 2011 10:32:45 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 8 Dec 2011 10:22:03 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 8 Dec 2011 10:22:02 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-idr-custom-decision-00
Thread-Index: Acy1itg5sokm18BwSeGduZeO+Fm3bA==
From: 
To: 
X-OriginalArrivalTime: 08 Dec 2011 09:22:03.0331 (UTC) FILETIME=[D8BD7130:01CCB58A]
Subject: [Idr] draft-ietf-idr-custom-decision-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 09:22:04 -0000

Alvaro, Russ, all

Draft says:

"      The value of the high-order octet of this Opaque Extended
      Community is 0x03 or 0x43.  The value of the low-order octet of
      the extended type field for this community is 0x01."

[...]

"   IANA is asked to assign the type values indicated in Section 3 to
the
   Cost Community in the BGP Opaque Extended Community registry
   [BGP_EXT]."

In order to avoid that different independent draft inadvertently pick
the same value, I would suggest that either the specific value (0x01) be
removed from the draft (replaced by "TBD") or probably preferably, that
you request this value to the IANA (Opaque Extended Community is "First
Come First Serve"). That's a 1 minute request @
http://www.iana.org/cgi-bin/assignments.pl .

Many thanks
Bruno

PS: I agree that the probably of collision is small, but when it
happens, in the end the pain is mostly on the provider side. So if we
could avoid at no cost.


From wwwrun@rfc-editor.org  Thu Dec  8 12:09:31 2011
Return-Path: 
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 1243421F8B3D; Thu,  8 Dec 2011 12:09:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.154
X-Spam-Level: 
X-Spam-Status: No, score=-105.154 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 fTtRgDOtOHIK; Thu,  8 Dec 2011 12:09:29 -0800 (PST)
Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id C53B621F8BEC; Thu,  8 Dec 2011 12:09:27 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id DBF26B1E003; Thu,  8 Dec 2011 12:08:49 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20111208200849.DBF26B1E003@rfc-editor.org>
Date: Thu,  8 Dec 2011 12:08:49 -0800 (PST)
Cc: idr@ietf.org, rfc-editor@rfc-editor.org
Subject: [Idr] BCP 172, RFC 6472 on Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 20:09:31 -0000

A new Request for Comments is now available in online RFC libraries.

        BCP 172        
        RFC 6472

        Title:      Recommendation for Not Using AS_SET 
                    and AS_CONFED_SET in BGP 
        Author:     W. Kumari, K. Sriram
        Status:     Best Current Practice
        Stream:     IETF
        Date:       December 2011
        Mailbox:    warren@kumari.net, 
                    ksriram@nist.gov
        Pages:      5
        Characters: 10673
        See Also:   BCP0172

        I-D Tag:    draft-ietf-idr-deprecate-as-sets-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6472.txt

This document recommends against the use of the AS_SET and
AS_CONFED_SET types of the AS_PATH in BGPv4.  This is done to
simplify the design and implementation of BGP and to make the
semantics of the originator of a route more clear.  This will also
simplify the design, implementation, and deployment of ongoing work
in the Secure Inter-Domain Routing Working Group.  This memo documents
an Internet Best Current Practice.

This document is a product of the Inter-Domain Routing Working Group of the IETF.


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From internet-drafts@ietf.org  Mon Dec 12 08:40:42 2011
Return-Path: 
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 0E16621F8B95; Mon, 12 Dec 2011 08:40:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.58
X-Spam-Level: 
X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 kHTUbkuqL3Nd; Mon, 12 Dec 2011 08:40:41 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891C721F8A96; Mon, 12 Dec 2011 08:40:41 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64
Message-ID: <20111212164041.14667.58878.idtracker@ietfa.amsl.com>
Date: Mon, 12 Dec 2011 08:40:41 -0800
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-aigp-07.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Dec 2011 16:40:42 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Inter-Domain Routing Working Group of=
 the IETF.

	Title           : The Accumulated IGP Metric Attribute for BGP
	Author(s)       : Pradosh Mohapatra
                          Rex Fernando
                          Eric C. Rosen
                          James Uttaro
	Filename        : draft-ietf-idr-aigp-07.txt
	Pages           : 14
	Date            : 2011-12-12

   Routing protocols that have been designed to run within a single
   administrative domain ("IGPs") generally do so by assigning a metric
   to each link, and then choosing as the installed path between two
   nodes the path for which the total distance (sum of the metric of
   each link along the path) is minimized.  BGP, designed to provide
   routing over a large number of independent administrative domains
   ("autonomous systems"), does not make its path selection decisions
   through the use of a metric.  It is generally recognized that any
   attempt to do so would incur significant scalability problems, as
   well as inter-administration coordination problems.  However, there
   are deployments in which a single administration runs several
   contiguous BGP networks.  In such cases, it can be desirable, within
   that single administrative domain, for BGP to select paths based on a
   metric, just as an IGP would do.  The purpose of this document is to
   provide a specification for doing so.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-aigp-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-aigp-07.txt


From internet-drafts@ietf.org  Thu Dec 15 15:38:45 2011
Return-Path: 
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 6E14321F8AFA; Thu, 15 Dec 2011 15:38:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 qoJ6gLnfCp+L; Thu, 15 Dec 2011 15:38:45 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A78B21F8AE9; Thu, 15 Dec 2011 15:38:45 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64p1
Message-ID: <20111215233845.21432.33837.idtracker@ietfa.amsl.com>
Date: Thu, 15 Dec 2011 15:38:45 -0800
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Dec 2011 23:38:45 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Inter-Domain Routing Working Group of=
 the IETF.

	Title           : Revised Error Handling for BGP UPDATE Messages
	Author(s)       : John G. Scudder
                          Enke Chen
                          Pradosh Mohapatra
                          Keyur Patel
	Filename        : draft-ietf-idr-error-handling-01.txt
	Pages           : 10
	Date            : 2011-12-15

   According to the base BGP specification, a BGP speaker that receives
   an UPDATE message containing a malformed attribute is required to
   reset the session over which the offending attribute was received.
   This behavior is undesirable as a session reset would impact not only
   routes with the offending attribute, but also other valid routes
   exchanged over the session.  This document partially revises the
   error handling for UPDATE messages, and provides guidelines for the
   authors of documents defining new attributes.  Finally, it revises
   the error handling procedures for several existing attributes.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-error-handling-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-error-handling-01.txt


From jakob.heitz@ericsson.com  Fri Dec 16 07:50:52 2011
Return-Path: 
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 44EF821F8AAC for ; Fri, 16 Dec 2011 07:50:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 VnGBQMdHdV1i for ; Fri, 16 Dec 2011 07:50:51 -0800 (PST)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 215DA21F8BAD for ; Fri, 16 Dec 2011 07:50:50 -0800 (PST)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pBGFoYrB012517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 16 Dec 2011 09:50:50 -0600
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 16 Dec 2011 10:50:38 -0500
From: Jakob Heitz 
To: "idr@ietf.org" 
Date: Fri, 16 Dec 2011 10:52:17 -0500
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
Thread-Index: Acy8CnR0GYSVnoupTWeVZcaRPUwVOQ==
Message-ID: <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com>
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com>
In-Reply-To: <20111215233845.21432.33837.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 15:50:52 -0000

SSBhZ3JlZSB3aXRoIHRoZSBhZGRlZCBzZW50ZW5jZToNCg0KDQogICBJZiBhbiBhdHRyaWJ1dGUg
YXBwZWFycyBtb3JlIHRoYW4gb25jZSBpbiBhbiBVUERBVEUgbWVzc2FnZSwgdGhlbiBhbGwNCiAg
IHRoZSBvY2N1cnJlbmNlcyBvZiB0aGUgYXR0cmlidXRlIG90aGVyIHRoYW4gdGhlIGZpcnN0IG9u
ZSBTSEFMTCBiZQ0KICAgZGlzY2FyZGVkIGFuZCB0aGUgVVBEQVRFIG1lc3NhZ2UgY29udGludWUg
dG8gYmUgcHJvY2Vzc2VkLg0KDQotLQ0KSmFrb2IgSGVpdHouDQoNCg0KT24gRGVjIDE1LCAyMDEx
LCBhdCAzOjM5IFBNLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1k
cmFmdHNAaWV0Zi5vcmc+IiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5l
dC1kcmFmdHNAaWV0Zi5vcmc+PiB3cm90ZToNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh
dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuIFRo
aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEludGVyLURvbWFpbiBSb3V0aW5nIFdvcmtp
bmcgR3JvdXAgb2YgdGhlIElFVEYuDQoNCiAgIFRpdGxlICAgICAgICAgICA6IFJldmlzZWQgRXJy
b3IgSGFuZGxpbmcgZm9yIEJHUCBVUERBVEUgTWVzc2FnZXMNCiAgIEF1dGhvcihzKSAgICAgICA6
IEpvaG4gRy4gU2N1ZGRlcg0KICAgICAgICAgICAgICAgICAgICAgICAgIEVua2UgQ2hlbg0KICAg
ICAgICAgICAgICAgICAgICAgICAgIFByYWRvc2ggTW9oYXBhdHJhDQogICAgICAgICAgICAgICAg
ICAgICAgICAgS2V5dXIgUGF0ZWwNCiAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtaWRy
LWVycm9yLWhhbmRsaW5nLTAxLnR4dA0KICAgUGFnZXMgICAgICAgICAgIDogMTANCiAgIERhdGUg
ICAgICAgICAgICA6IDIwMTEtMTItMTUNCg0KICBBY2NvcmRpbmcgdG8gdGhlIGJhc2UgQkdQIHNw
ZWNpZmljYXRpb24sIGEgQkdQIHNwZWFrZXIgdGhhdCByZWNlaXZlcw0KICBhbiBVUERBVEUgbWVz
c2FnZSBjb250YWluaW5nIGEgbWFsZm9ybWVkIGF0dHJpYnV0ZSBpcyByZXF1aXJlZCB0bw0KICBy
ZXNldCB0aGUgc2Vzc2lvbiBvdmVyIHdoaWNoIHRoZSBvZmZlbmRpbmcgYXR0cmlidXRlIHdhcyBy
ZWNlaXZlZC4NCiAgVGhpcyBiZWhhdmlvciBpcyB1bmRlc2lyYWJsZSBhcyBhIHNlc3Npb24gcmVz
ZXQgd291bGQgaW1wYWN0IG5vdCBvbmx5DQogIHJvdXRlcyB3aXRoIHRoZSBvZmZlbmRpbmcgYXR0
cmlidXRlLCBidXQgYWxzbyBvdGhlciB2YWxpZCByb3V0ZXMNCiAgZXhjaGFuZ2VkIG92ZXIgdGhl
IHNlc3Npb24uICBUaGlzIGRvY3VtZW50IHBhcnRpYWxseSByZXZpc2VzIHRoZQ0KICBlcnJvciBo
YW5kbGluZyBmb3IgVVBEQVRFIG1lc3NhZ2VzLCBhbmQgcHJvdmlkZXMgZ3VpZGVsaW5lcyBmb3Ig
dGhlDQogIGF1dGhvcnMgb2YgZG9jdW1lbnRzIGRlZmluaW5nIG5ldyBhdHRyaWJ1dGVzLiAgRmlu
YWxseSwgaXQgcmV2aXNlcw0KICB0aGUgZXJyb3IgaGFuZGxpbmcgcHJvY2VkdXJlcyBmb3Igc2V2
ZXJhbCBleGlzdGluZyBhdHRyaWJ1dGVzLg0KDQoNCkEgVVJMIGZvciB0aGlzIEludGVybmV0LURy
YWZ0IGlzOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1p
ZHItZXJyb3ItaGFuZGxpbmctMDEudHh0DQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFp
bGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k
cmFmdHMvDQoNClRoaXMgSW50ZXJuZXQtRHJhZnQgY2FuIGJlIHJldHJpZXZlZCBhdDoNCmZ0cDov
L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1pZHItZXJyb3ItaGFuZGxp
bmctMDEudHh0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5vcmc8bWFpbHRvOklkckBpZXRmLm9yZz4N
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo=

From robert@raszuk.net  Fri Dec 16 08:04:53 2011
Return-Path: 
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 4C3EB21F8A71 for ; Fri, 16 Dec 2011 08:04:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 PZEX+nxlOqdY for ; Fri, 16 Dec 2011 08:04:52 -0800 (PST)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 82C2D21F8A67 for ; Fri, 16 Dec 2011 08:04:52 -0800 (PST)
Received: (qmail 19272 invoked by uid 399); 16 Dec 2011 16:04:51 -0000
Received: from unknown (HELO ?192.168.1.91?) (83.31.233.122) by mail1310.opentransfer.com with ESMTP; 16 Dec 2011 16:04:51 -0000
X-Originating-IP: 83.31.233.122
Message-ID: <4EEB6C23.4080803@raszuk.net>
Date: Fri, 16 Dec 2011 17:04:51 +0100
From: Robert Raszuk 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Jakob Heitz 
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com>
In-Reply-To: <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 16:04:53 -0000

Hi Jakob,

Is this paragraph referring to any attribute ? If so I think more proper 
would be to say:

"If an identical attribute appears more than once .."
        ^^^^^^^^^

Example:

You have received Update message with two MP_UNREACH attributes first 
containing 5 NLRIs and the second 50 I don't think it is safe to drop 
the second MP_UNREACH and continue processing the message as usual.

Thx,
R.


> I agree with the added sentence:
>
>
>     If an attribute appears more than once in an UPDATE message, then all
>     the occurrences of the attribute other than the first one SHALL be
>     discarded and the UPDATE message continue to be processed.
>
> --
> Jakob Heitz.

From bruno.decraene@orange.com  Fri Dec 16 08:11:45 2011
Return-Path: 
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 DFCED21F8BAE for ; Fri, 16 Dec 2011 08:11:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
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 GHkiXMzgVgnq for ; Fri, 16 Dec 2011 08:11:45 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id EDB6C21F8BAA for ; Fri, 16 Dec 2011 08:11:44 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id AA92D22C1E0; Fri, 16 Dec 2011 17:11:43 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8761B35C048; Fri, 16 Dec 2011 17:11:43 +0100 (CET)
Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.01.0323.000; Fri, 16 Dec 2011 17:11:43 +0100
From: 
To: Jakob Heitz , "idr@ietf.org" 
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
Thread-Index: Acy8CnR0GYSVnoupTWeVZcaRPUwVOQAAbUFw
Date: Fri, 16 Dec 2011 16:11:42 +0000
Message-ID: <22846_1324051903_4EEB6DBF_22846_1333_4_53C29892C857584299CBF5D05346208A0103F8@PEXCVZYM11.corporate.adroot.infra.ftgroup>
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com>
In-Reply-To: <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.31.105417
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 16:11:46 -0000

>I agree with the added sentence:
>
>
>   If an attribute appears more than once in an UPDATE message, then all

What does "an attribute" refer to?
a) any attribute?
b) any attribute in error?
c) any attribute in error which does not impact the routing ("attribute dis=
card")?

I understand "c". I'm not sure about the others ("a", "b") (in particular "=
a" would mean to silently discard an AS_PATH, MP_REACH attribute while proc=
essing the NLRI)

>   the occurrences of the attribute other than the first one SHALL be
>   discarded and the UPDATE message continue to be processed.
>--
>Jakob Heitz.
>
>
>On Dec 15, 2011, at 3:39 PM, "internet-drafts@ietf.orgdrafts@ietf.org>" >
>wrote:
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts directo=
ries.
>This draft is a work item of the Inter-Domain Routing Working Group of the
>IETF.
>
>   Title           : Revised Error Handling for BGP UPDATE Messages
>   Author(s)       : John G. Scudder
>                         Enke Chen
>                         Pradosh Mohapatra
>                         Keyur Patel
>   Filename        : draft-ietf-idr-error-handling-01.txt
>   Pages           : 10
>   Date            : 2011-12-15
>
>  According to the base BGP specification, a BGP speaker that receives
>  an UPDATE message containing a malformed attribute is required to
>  reset the session over which the offending attribute was received.
>  This behavior is undesirable as a session reset would impact not only
>  routes with the offending attribute, but also other valid routes
>  exchanged over the session.  This document partially revises the
>  error handling for UPDATE messages, and provides guidelines for the
>  authors of documents defining new attributes.  Finally, it revises
>  the error handling procedures for several existing attributes.
>
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-idr-error-handling-01.txt
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>This Internet-Draft can be retrieved at:
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-error-handling-01.txt
>
>_______________________________________________
>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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if th=
is message was modified, changed or falsified.
Thank you.


From jakob.heitz@ericsson.com  Fri Dec 16 08:23:58 2011
Return-Path: 
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 7B00A21F8B08 for ; Fri, 16 Dec 2011 08:23:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 vtZjO2+ZLiHr for ; Fri, 16 Dec 2011 08:23:57 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8314721F8B03 for ; Fri, 16 Dec 2011 08:23:57 -0800 (PST)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBGGNrBW003437; Fri, 16 Dec 2011 10:23:54 -0600
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 16 Dec 2011 11:23:52 -0500
From: Jakob Heitz 
To: "bruno.decraene@orange.com" 
Date: Fri, 16 Dec 2011 11:25:30 -0500
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
Thread-Index: Acy8DxiMlhmTFG7rQ1iUkzOaOTCvQA==
Message-ID: <2F58DE3B-92E5-42BF-B7A2-FBDD1A1DA230@ericsson.com>
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <22846_1324051903_4EEB6DBF_22846_1333_4_53C29892C857584299CBF5D05346208A0103F8@PEXCVZYM11.corporate.adroot.infra.ftgroup>
In-Reply-To: <22846_1324051903_4EEB6DBF_22846_1333_4_53C29892C857584299CBF5D05346208A0103F8@PEXCVZYM11.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 16:23:58 -0000

An attribute of a specific type. For example if an update message contains =
2 LOCAL_PREF attributes, the second would be discarded. The first one would=
 be processed. If the first was in error, then it would be processed as suc=
h, but the second would be discarded nonetheless.

--
Jakob Heitz.


On Dec 16, 2011, at 8:11 AM, "bruno.decraene@orange.com"  wrote:

>=20
>=20
>> I agree with the added sentence:
>>=20
>>=20
>>  If an attribute appears more than once in an UPDATE message, then all
>=20
> What does "an attribute" refer to?
> a) any attribute?
> b) any attribute in error?
> c) any attribute in error which does not impact the routing ("attribute d=
iscard")?
>=20
> I understand "c". I'm not sure about the others ("a", "b") (in particular=
 "a" would mean to silently discard an AS_PATH, MP_REACH attribute while pr=
ocessing the NLRI)
>=20
>>  the occurrences of the attribute other than the first one SHALL be
>>  discarded and the UPDATE message continue to be processed.
>> --
>> Jakob Heitz.
>>=20
>>=20
>> On Dec 15, 2011, at 3:39 PM, "internet-drafts@ietf.org> drafts@ietf.org>" >
>> wrote:
>>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts direc=
tories.
>> This draft is a work item of the Inter-Domain Routing Working Group of t=
he
>> IETF.
>>=20
>>  Title           : Revised Error Handling for BGP UPDATE Messages
>>  Author(s)       : John G. Scudder
>>                        Enke Chen
>>                        Pradosh Mohapatra
>>                        Keyur Patel
>>  Filename        : draft-ietf-idr-error-handling-01.txt
>>  Pages           : 10
>>  Date            : 2011-12-15
>>=20
>> According to the base BGP specification, a BGP speaker that receives
>> an UPDATE message containing a malformed attribute is required to
>> reset the session over which the offending attribute was received.
>> This behavior is undesirable as a session reset would impact not only
>> routes with the offending attribute, but also other valid routes
>> exchanged over the session.  This document partially revises the
>> error handling for UPDATE messages, and provides guidelines for the
>> authors of documents defining new attributes.  Finally, it revises
>> the error handling procedures for several existing attributes.
>>=20
>>=20
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-idr-error-handling-01.txt
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-error-handling-01.txt
>>=20
>> _______________________________________________
>> 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
>=20
> _________________________________________________________________________=
________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci
>=20
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
> they should not be distributed, used or copied without authorization.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, France Telecom - Orange shall not be liable if =
this message was modified, changed or falsified.
> Thank you.
>=20

From jakob.heitz@ericsson.com  Fri Dec 16 08:32:39 2011
Return-Path: 
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 BA9CC21F8B8A for ; Fri, 16 Dec 2011 08:32:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 0g60zOufkw7L for ; Fri, 16 Dec 2011 08:32:39 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2207421F8B43 for ; Fri, 16 Dec 2011 08:32:39 -0800 (PST)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBGGWQUW005506; Fri, 16 Dec 2011 10:32:38 -0600
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 16 Dec 2011 11:32:33 -0500
From: Jakob Heitz 
To: "robert@raszuk.net" 
Date: Fri, 16 Dec 2011 11:34:12 -0500
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
Thread-Index: Acy8EE8830GG0R23QKCtgxZmHaD7EQ==
Message-ID: 
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>
In-Reply-To: <4EEB6C23.4080803@raszuk.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 16:32:39 -0000

Say I get 2 LOCAL_PREF, one with value 100, the other 99. They are not iden=
tical, but I can clearly choose only one.

Robert, please go through the list of bgp attributes in http://www.iana.org=
/assignments/bgp-parameters/bgp-parameters.xml and enumerate the identical =
ones.

--
Jakob Heitz.


On Dec 16, 2011, at 8:04 AM, "Robert Raszuk"  wrote:

> Hi Jakob,
>=20
> Is this paragraph referring to any attribute ? If so I think more proper=
=20
> would be to say:
>=20
> "If an identical attribute appears more than once .."
>        ^^^^^^^^^
>=20
> Example:
>=20
> You have received Update message with two MP_UNREACH attributes first=20
> containing 5 NLRIs and the second 50 I don't think it is safe to drop=20
> the second MP_UNREACH and continue processing the message as usual.
>=20
> Thx,
> R.
>=20
>=20
>> I agree with the added sentence:
>>=20
>>=20
>>    If an attribute appears more than once in an UPDATE message, then all
>>    the occurrences of the attribute other than the first one SHALL be
>>    discarded and the UPDATE message continue to be processed.
>>=20
>> --
>> Jakob Heitz.

From bruno.decraene@orange.com  Fri Dec 16 08:51:40 2011
Return-Path: 
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 691E021F8B4F for ; Fri, 16 Dec 2011 08:51:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
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 JsQSMbx5NGfp for ; Fri, 16 Dec 2011 08:51:39 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 258B921F8B3E for ; Fri, 16 Dec 2011 08:51:39 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id A2559324A98; Fri, 16 Dec 2011 17:51:37 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8A0E935C045; Fri, 16 Dec 2011 17:51:37 +0100 (CET)
Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.01.0323.000; Fri, 16 Dec 2011 17:51:37 +0100
From: 
To: Jakob Heitz 
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
Thread-Index: Acy8DxiMGYSVnoupTWeVZcaRPUwVOQAAJstg
Date: Fri, 16 Dec 2011 16:51:35 +0000
Message-ID: <9432_1324054297_4EEB7719_9432_12_1_53C29892C857584299CBF5D05346208A01085A@PEXCVZYM11.corporate.adroot.infra.ftgroup>
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <22846_1324051903_4EEB6DBF_22846_1333_4_53C29892C857584299CBF5D05346208A0103F8@PEXCVZYM11.corporate.adroot.infra.ftgroup> <2F58DE3B-92E5-42BF-B7A2-FBDD1A1DA230@ericsson.com>
In-Reply-To: <2F58DE3B-92E5-42BF-B7A2-FBDD1A1DA230@ericsson.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.31.105417
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 16:51:40 -0000

>An attribute of a specific type. For example if an update message contains=
 2
>LOCAL_PREF attributes, the second would be discarded. The first one would =
be
>processed.

That would be my "a" case.
Why would it be valid and safe to discard ("attribute discard") this second=
 LOCAL_PREF and not the first/only one?

> If the first was in error, then it would be processed as such, but
> the second would be discarded nonetheless.

If the first is treated as "treat-as-withdraw" (My case "b"), the second wi=
ll never be processed in the first place. No need to add a sentence.

If the first is treated as "attribute discard" (My case "c"), I'm fine with=
 the proposed new addition but yet why would we want to discard the second =
attribute?

In short, IMHO, the additional sentence is mostly applicable to attribute t=
reated with the approach "attribute discard". I would propose the following=
 formulation:
If an attribute _using the "attribute discard" approach_ appears more than =
once in an UPDATE message, then all the occurrences of the attribute other =
than the first _valid_ one SHALL be discarded and the UPDATE message contin=
ue to be processed.

>
>--
>Jakob Heitz.
>
>
>On Dec 16, 2011, at 8:11 AM, "bruno.decraene@orange.com"
> wrote:
>
>>
>>
>>> I agree with the added sentence:
>>>
>>>
>>>  If an attribute appears more than once in an UPDATE message, then all
>>
>> What does "an attribute" refer to?
>> a) any attribute?
>> b) any attribute in error?
>> c) any attribute in error which does not impact the routing ("attribute
>discard")?
>>
>> I understand "c". I'm not sure about the others ("a", "b") (in particula=
r "a"
>would mean to silently discard an AS_PATH, MP_REACH attribute while proces=
sing
>the NLRI)
>>
>>>  the occurrences of the attribute other than the first one SHALL be
>>>  discarded and the UPDATE message continue to be processed.
>>> --
>>> Jakob Heitz.
>>>
>>>
>>> On Dec 15, 2011, at 3:39 PM, "internet-drafts@ietf.org>> drafts@ietf.org>" drafts@ietf.org>>
>>> wrote:
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>>> This draft is a work item of the Inter-Domain Routing Working Group of =
the
>>> IETF.
>>>
>>>  Title           : Revised Error Handling for BGP UPDATE Messages
>>>  Author(s)       : John G. Scudder
>>>                        Enke Chen
>>>                        Pradosh Mohapatra
>>>                        Keyur Patel
>>>  Filename        : draft-ietf-idr-error-handling-01.txt
>>>  Pages           : 10
>>>  Date            : 2011-12-15
>>>
>>> According to the base BGP specification, a BGP speaker that receives
>>> an UPDATE message containing a malformed attribute is required to
>>> reset the session over which the offending attribute was received.
>>> This behavior is undesirable as a session reset would impact not only
>>> routes with the offending attribute, but also other valid routes
>>> exchanged over the session.  This document partially revises the
>>> error handling for UPDATE messages, and provides guidelines for the
>>> authors of documents defining new attributes.  Finally, it revises
>>> the error handling procedures for several existing attributes.
>>>
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-idr-error-handling-01.txt
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> This Internet-Draft can be retrieved at:
>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-error-handling-01.txt
>>>
>>> _______________________________________________
>>> 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
>>
>>
>__________________________________________________________________________=
_____
>__________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r=
ecu
>ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>> France Telecom - Orange decline toute responsabilite si ce message a ete
>altere, deforme ou falsifie. Merci
>>
>> This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>> they should not be distributed, used or copied without authorization.
>> If you have received this email in error, please notify the sender and d=
elete
>this message and its attachments.
>> As emails may be altered, France Telecom - Orange shall not be liable if=
 this
>message was modified, changed or falsified.
>> Thank you.
>>

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if th=
is message was modified, changed or falsified.
Thank you.


From robert@raszuk.net  Fri Dec 16 08:59:18 2011
Return-Path: 
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 71E9521F8B73 for ; Fri, 16 Dec 2011 08:59:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 RuShkWjiz9Wl for ; Fri, 16 Dec 2011 08:59:17 -0800 (PST)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 9117B21F8B3B for ; Fri, 16 Dec 2011 08:59:17 -0800 (PST)
Received: (qmail 9285 invoked by uid 399); 16 Dec 2011 16:59:17 -0000
Received: from unknown (HELO ?192.168.1.91?) (83.31.233.122) by mail1310.opentransfer.com with ESMTP; 16 Dec 2011 16:59:17 -0000
X-Originating-IP: 83.31.233.122
Message-ID: <4EEB78E5.6070809@raszuk.net>
Date: Fri, 16 Dec 2011 17:59:17 +0100
From: Robert Raszuk 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Jakob Heitz 
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 16:59:18 -0000

Jakob,

> Say I get 2 LOCAL_PREF, one with value 100, the other 99. They are
> not identical, but I can clearly choose only one.

If you want to know my preference .. I would prefer to drop the session 
rather then to deal with peer which can not even build the BGP Update 
message properly.

> Robert, please go through the list of bgp attributes in
> http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xml and
> enumerate the identical ones.

Entirely irrelevant comment.

Thx,
R.



> On Dec 16, 2011, at 8:04 AM, "Robert Raszuk"
> wrote:
>
>> Hi Jakob,
>>
>> Is this paragraph referring to any attribute ? If so I think more
>> proper would be to say:
>>
>> "If an identical attribute appears more than once .." ^^^^^^^^^
>>
>> Example:
>>
>> You have received Update message with two MP_UNREACH attributes
>> first containing 5 NLRIs and the second 50 I don't think it is safe
>> to drop the second MP_UNREACH and continue processing the message
>> as usual.
>>
>> Thx, R.
>>
>>
>>> I agree with the added sentence:
>>>
>>>
>>> If an attribute appears more than once in an UPDATE message, then
>>> all the occurrences of the attribute other than the first one
>>> SHALL be discarded and the UPDATE message continue to be
>>> processed.
>>>
>>> -- Jakob Heitz.
>
>


From internet-drafts@ietf.org  Fri Dec 16 10:23:24 2011
Return-Path: 
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 6BB1221F84FC; Fri, 16 Dec 2011 10:23:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level: 
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 AyVTBaNiBs-n; Fri, 16 Dec 2011 10:23:24 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D0621F848A; Fri, 16 Dec 2011 10:23:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64p1
Message-ID: <20111216182324.17528.28150.idtracker@ietfa.amsl.com>
Date: Fri, 16 Dec 2011 10:23:24 -0800
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-as0-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 18:23:24 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Inter-Domain Routing Working Group of=
 the IETF.

	Title           : Codification of AS 0 processing.
	Author(s)       : Warren Kumari
                          Randy Bush
                          Heather Schiller
	Filename        : draft-ietf-idr-as0-01.txt
	Pages           : 6
	Date            : 2011-12-16

   This document proscribes the use of AS 0 in BGP OPEN and AS_PATH /
   AS4_PATH BGP attribute.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-as0-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-as0-01.txt


From warren@kumari.net  Fri Dec 16 10:39:33 2011
Return-Path: 
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 0C2DE21F8A71; Fri, 16 Dec 2011 10:39:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 u+HAG73gajXT; Fri, 16 Dec 2011 10:39:32 -0800 (PST)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1EF21F8A62; Fri, 16 Dec 2011 10:39:32 -0800 (PST)
Received: from [192.168.0.105] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 984AC1B401ED; Fri, 16 Dec 2011 13:39:31 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari 
In-Reply-To: <20111216182324.17528.28150.idtracker@ietfa.amsl.com>
Date: Fri, 16 Dec 2011 13:39:30 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net>
References: <20111216182324.17528.28150.idtracker@ietfa.amsl.com>
To: internet-drafts@ietf.org
X-Mailer: Apple Mail (2.1084)
Cc: idr@ietf.org, i-d-announce@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 18:39:33 -0000

As requested, this version separates the error definition and error =
handling by pointing to the draft-ietf-idr-error-handling document...


Thanks to everyone who provided feedback on -00.
W


On Dec 16, 2011, at 1:23 PM, internet-drafts@ietf.org wrote:

>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories. This draft is a work item of the Inter-Domain Routing =
Working Group of the IETF.
>=20
> 	Title           : Codification of AS 0 processing.
> 	Author(s)       : Warren Kumari
>                          Randy Bush
>                          Heather Schiller
> 	Filename        : draft-ietf-idr-as0-01.txt
> 	Pages           : 6
> 	Date            : 2011-12-16
>=20
>   This document proscribes the use of AS 0 in BGP OPEN and AS_PATH /
>   AS4_PATH BGP attribute.
>=20
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-idr-as0-01.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-as0-01.txt
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>=20


From jakob.heitz@ericsson.com  Fri Dec 16 10:59:30 2011
Return-Path: 
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 C426721F8B0D; Fri, 16 Dec 2011 10:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, 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 qGGhOZcUltRW; Fri, 16 Dec 2011 10:59:30 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4444F21F8B0A; Fri, 16 Dec 2011 10:59:30 -0800 (PST)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBGIx9KL007958; Fri, 16 Dec 2011 12:59:26 -0600
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 16 Dec 2011 13:59:24 -0500
From: Jakob Heitz 
To: Warren Kumari , "internet-drafts@ietf.org" 
Date: Fri, 16 Dec 2011 13:59:23 -0500
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-as0-01.txt
Thread-Index: Acy8IiCa0TVVQn3TQ/2M+k8GDAg6nQAAqq6w
Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A4770AF37@EUSAACMS0701.eamcs.ericsson.se>
References: <20111216182324.17528.28150.idtracker@ietfa.amsl.com> <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net>
In-Reply-To: <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org" , "i-d-announce@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 18:59:30 -0000

Looks good to me.

--
Jakob Heitz.

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Warre=
n Kumari
Sent: Friday, December 16, 2011 10:40 AM
To: internet-drafts@ietf.org
Cc: idr@ietf.org; i-d-announce@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt

As requested, this version separates the error definition and error handlin=
g by pointing to the draft-ietf-idr-error-handling document...


Thanks to everyone who provided feedback on -00.
W


On Dec 16, 2011, at 1:23 PM, internet-drafts@ietf.org wrote:

>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories. This draft is a work item of the Inter-Domain Routing Working Group =
of the IETF.
>=20
> 	Title           : Codification of AS 0 processing.
> 	Author(s)       : Warren Kumari
>                          Randy Bush
>                          Heather Schiller
> 	Filename        : draft-ietf-idr-as0-01.txt
> 	Pages           : 6
> 	Date            : 2011-12-16
>=20
>   This document proscribes the use of AS 0 in BGP OPEN and AS_PATH /
>   AS4_PATH BGP attribute.
>=20
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-idr-as0-01.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-as0-01.txt
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>=20

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

From enkechen@cisco.com  Fri Dec 16 11:01:36 2011
Return-Path: 
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 D41BE21F8B37 for ; Fri, 16 Dec 2011 11:01:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 TG+RvAQnc88K for ; Fri, 16 Dec 2011 11:01:36 -0800 (PST)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0B11A21F8B2E for ; Fri, 16 Dec 2011 11:01:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=7289; q=dns/txt; s=iport; t=1324062096; x=1325271696; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=OfS1hK8RWU+OpHOzeXGU50VfqXeExhLR4CUCAlU6RAU=; b=S2hnEsI4rZx9KCZsW7YAR1qBjR517jHVV/IE42hYb9JL0CuwVhFkbcdS i2L4isRRvhGNqbVyb1dazLNI+1NFyG1EGFOK1qb3OgX+Cq4Rhhv7tsPJo XBABqB3JrUy6k278kF+LBznicCEFpnQH7qkO5wPGsZL5gbXc9EyLQU8AM g=;
X-IronPort-AV: E=Sophos;i="4.71,364,1320624000"; d="scan'208,217";a="21164573"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 16 Dec 2011 19:01:35 +0000
Received: from dhcp-171-71-139-230.cisco.com (dhcp-171-71-139-230.cisco.com [171.71.139.230]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pBGJ1ZsD001479; Fri, 16 Dec 2011 19:01:35 GMT
Message-ID: <4EEB962C.1030908@cisco.com>
Date: Fri, 16 Dec 2011 11:04:12 -0800
From: Enke Chen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: idr@ietf.org
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com>
In-Reply-To: <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com>
Content-Type: multipart/alternative; boundary="------------060408080700080401090701"
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 19:01:36 -0000

This is a multi-part message in MIME format.
--------------060408080700080401090701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

It is to address the following case specified in Sect. 6.3, RFC 4271:

    If any attribute appears more than once in the UPDATE message, then
    the Error Subcode MUST be set to Malformed Attribute List.

We missed the case in the earlier version, although we said:

    The error handling of all other cases described in Section 6.3 of
    [RFC4271] that specify a session reset is revised as follows.
    ...

-- Enke


On 12/16/11 7:52 AM, Jakob Heitz wrote:
> I agree with the added sentence:
>
>
>     If an attribute appears more than once in an UPDATE message, then all
>     the occurrences of the attribute other than the first one SHALL be
>     discarded and the UPDATE message continue to be processed.
>
> --
> Jakob Heitz.
>
>
> On Dec 15, 2011, at 3:39 PM, "internet-drafts@ietf.org">  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF.
>
>     Title           : Revised Error Handling for BGP UPDATE Messages
>     Author(s)       : John G. Scudder
>                           Enke Chen
>                           Pradosh Mohapatra
>                           Keyur Patel
>     Filename        : draft-ietf-idr-error-handling-01.txt
>     Pages           : 10
>     Date            : 2011-12-15
>
>    According to the base BGP specification, a BGP speaker that receives
>    an UPDATE message containing a malformed attribute is required to
>    reset the session over which the offending attribute was received.
>    This behavior is undesirable as a session reset would impact not only
>    routes with the offending attribute, but also other valid routes
>    exchanged over the session.  This document partially revises the
>    error handling for UPDATE messages, and provides guidelines for the
>    authors of documents defining new attributes.  Finally, it revises
>    the error handling procedures for several existing attributes.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-idr-error-handling-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-error-handling-01.txt
>
> _______________________________________________
> 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


--------------060408080700080401090701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
    
It is to address the following case specified in Sect. 6.3, RFC 4271:

   If any attribute appears more than once in the UPDATE message, then
   the Error Subcode MUST be set to Malformed Attribute List.

We missed the case in the earlier version, although we said:

   The error handling of all other cases described in Section 6.3 of
   [RFC4271] that specify a session reset is revised as follows.
   ...

-- Enke


    

    On 12/16/11 7:52 AM, Jakob Heitz wrote:
    

      
I agree with the added sentence:


   If an attribute appears more than once in an UPDATE message, then all
   the occurrences of the attribute other than the first one SHALL be
   discarded and the UPDATE message continue to be processed.

--
Jakob Heitz.


On Dec 15, 2011, at 3:39 PM, "internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>" <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

   Title           : Revised Error Handling for BGP UPDATE Messages
   Author(s)       : John G. Scudder
                         Enke Chen
                         Pradosh Mohapatra
                         Keyur Patel
   Filename        : draft-ietf-idr-error-handling-01.txt
   Pages           : 10
   Date            : 2011-12-15

  According to the base BGP specification, a BGP speaker that receives
  an UPDATE message containing a malformed attribute is required to
  reset the session over which the offending attribute was received.
  This behavior is undesirable as a session reset would impact not only
  routes with the offending attribute, but also other valid routes
  exchanged over the session.  This document partially revises the
  error handling for UPDATE messages, and provides guidelines for the
  authors of documents defining new attributes.  Finally, it revises
  the error handling procedures for several existing attributes.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-error-handling-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-error-handling-01.txt

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


    

    

  


--------------060408080700080401090701--

From warren@kumari.net  Fri Dec 16 11:16:50 2011
Return-Path: 
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 42BB221F84FD for ; Fri, 16 Dec 2011 11:16:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level: 
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 gW-dmD7sQX3p for ; Fri, 16 Dec 2011 11:16:49 -0800 (PST)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id B522121F84F5 for ; Fri, 16 Dec 2011 11:16:49 -0800 (PST)
Received: from [192.168.0.105] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id D7A4A1B401A9; Fri, 16 Dec 2011 14:16:48 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari 
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A4770AF37@EUSAACMS0701.eamcs.ericsson.se>
Date: Fri, 16 Dec 2011 14:16:46 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <8748342E-0458-409A-94DF-FCE62F39C49A@kumari.net>
References: <20111216182324.17528.28150.idtracker@ietfa.amsl.com> <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net> <7309FCBCAE981B43ABBE69B31C8D21391A4770AF37@EUSAACMS0701.eamcs.ericsson.se>
To: Jakob Heitz 
X-Mailer: Apple Mail (2.1084)
Cc: "idr@ietf.org List" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 19:16:50 -0000

[ Trimming that announce-list and id lists, which I forgot to do in the =
initial mail ]  ]=20
On Dec 16, 2011, at 1:59 PM, Jakob Heitz wrote:

> Looks good to me.
>=20

Thank you sir.

Folk often forget how important explicit LGTMs like this are on a =
document.
It's always more fun / interesting to respond with concerns/ issues, but =
explicitly ACK'ing helps the authors know that they are doing what is =
asked of them. Without this it is hard for the authors to know if the =
lack of responses is because folk approve and haven't said so or just =
haven't yet had a chance to read the document...

W

> --
> Jakob Heitz.
>=20
> -----Original Message-----
> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of =
Warren Kumari
> Sent: Friday, December 16, 2011 10:40 AM
> To: internet-drafts@ietf.org
> Cc: idr@ietf.org; i-d-announce@ietf.org
> Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt
>=20
> As requested, this version separates the error definition and error =
handling by pointing to the draft-ietf-idr-error-handling document...
>=20
>=20
> Thanks to everyone who provided feedback on -00.
> W
>=20
>=20
> On Dec 16, 2011, at 1:23 PM, internet-drafts@ietf.org wrote:
>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories. This draft is a work item of the Inter-Domain Routing =
Working Group of the IETF.
>>=20
>> 	Title           : Codification of AS 0 processing.
>> 	Author(s)       : Warren Kumari
>>                         Randy Bush
>>                         Heather Schiller
>> 	Filename        : draft-ietf-idr-as0-01.txt
>> 	Pages           : 6
>> 	Date            : 2011-12-16
>>=20
>>  This document proscribes the use of AS 0 in BGP OPEN and AS_PATH /
>>  AS4_PATH BGP attribute.
>>=20
>>=20
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-idr-as0-01.txt
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-as0-01.txt
>>=20
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>=20
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>=20


From cjeker@diehard.n-r-g.com  Fri Dec 16 14:07:41 2011
Return-Path: 
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 764D01F0C53 for ; Fri, 16 Dec 2011 14:07:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 9LoX7peXLte0 for ; Fri, 16 Dec 2011 14:07:41 -0800 (PST)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by ietfa.amsl.com (Postfix) with ESMTP id C6EA61F0C3F for ; Fri, 16 Dec 2011 14:07:40 -0800 (PST)
Received: (qmail 12305 invoked by uid 1001); 16 Dec 2011 22:07:20 -0000
Date: Fri, 16 Dec 2011 23:07:20 +0100
From: Claudio Jeker 
To: idr@ietf.org
Message-ID: <20111216220720.GB10812@diehard.n-r-g.com>
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>  <4EEB78E5.6070809@raszuk.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4EEB78E5.6070809@raszuk.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 22:07:41 -0000

On Fri, Dec 16, 2011 at 05:59:17PM +0100, Robert Raszuk wrote:
> Jakob,
> 
> >Say I get 2 LOCAL_PREF, one with value 100, the other 99. They are
> >not identical, but I can clearly choose only one.
> 
> If you want to know my preference .. I would prefer to drop the
> session rather then to deal with peer which can not even build the
> BGP Update message properly.
> 

Me too. If a peer is unable to build a valid basic BGP packet it may do
even worse things. The session is not trustworthy and it must be the
direct neighbor at fault, so throwing a NOTIFICATION is the right way to
handle this.

Sometimes it is ok to error out instead of building insane fail saves
(which make the system less stable and can backfire later on).
-- 
:wq Claudio

From jakob.heitz@ericsson.com  Fri Dec 16 14:36:57 2011
Return-Path: 
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 8FC5921F863E for ; Fri, 16 Dec 2011 14:36:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 zgrSxBJCjd5b for ; Fri, 16 Dec 2011 14:36:57 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id EC69D21F8591 for ; Fri, 16 Dec 2011 14:36:56 -0800 (PST)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBGMaqTt017895 for ; Fri, 16 Dec 2011 16:36:56 -0600
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 16 Dec 2011 17:36:51 -0500
From: Jakob Heitz 
To: "idr@ietf.org" 
Date: Fri, 16 Dec 2011 17:36:50 -0500
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
Thread-Index: Acy8Pye0FpqOwoz0RHSKuR4zIng8OwAAjcCQ
Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A4770B078@EUSAACMS0701.eamcs.ericsson.se>
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>  <4EEB78E5.6070809@raszuk.net> <20111216220720.GB10812@diehard.n-r-g.com>
In-Reply-To: <20111216220720.GB10812@diehard.n-r-g.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 22:36:57 -0000

Points made at the Taipei meeting:

Old thinking: No service is better than unreliable service.
New thinking: Partial service is better than no service.

All errors will be logged for debugging and manual verification
of the routing state.

Experience has shown that using a session reset causes severe disruption
to routing, making it an inappropriate way to call attention
to a protocol error. Such errors can be handled in a much
less disruptive manner.

Another point made:

Error handling must be as simple as possible (and no simpler),
lest bugs in the error handling make the medicine worse than the disease.

I think the error handling draft as it stands now lays out
a well balanced solution to meet these criteria.

--
Jakob Heitz.

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Claud=
io Jeker
Sent: Friday, December 16, 2011 2:07 PM
To: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt

On Fri, Dec 16, 2011 at 05:59:17PM +0100, Robert Raszuk wrote:
> Jakob,
>=20
> >Say I get 2 LOCAL_PREF, one with value 100, the other 99. They are
> >not identical, but I can clearly choose only one.
>=20
> If you want to know my preference .. I would prefer to drop the
> session rather then to deal with peer which can not even build the
> BGP Update message properly.
>=20

Me too. If a peer is unable to build a valid basic BGP packet it may do
even worse things. The session is not trustworthy and it must be the
direct neighbor at fault, so throwing a NOTIFICATION is the right way to
handle this.

Sometimes it is ok to error out instead of building insane fail saves
(which make the system less stable and can backfire later on).
--=20
:wq Claudio
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

From robert@raszuk.net  Fri Dec 16 14:50:35 2011
Return-Path: 
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 F2A3021F8AF0 for ; Fri, 16 Dec 2011 14:50:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 U8mNb28OrZZn for ; Fri, 16 Dec 2011 14:50:34 -0800 (PST)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 287A621F8AD9 for ; Fri, 16 Dec 2011 14:50:34 -0800 (PST)
Received: (qmail 23816 invoked by uid 399); 16 Dec 2011 22:50:31 -0000
Received: from unknown (HELO ?192.168.1.57?) (83.9.126.71) by mail1310.opentransfer.com with ESMTP; 16 Dec 2011 22:50:31 -0000
X-Originating-IP: 83.9.126.71
Message-ID: <4EEBCB39.5060702@raszuk.net>
Date: Fri, 16 Dec 2011 23:50:33 +0100
From: Robert Raszuk 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Jakob Heitz 
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>  <4EEB78E5.6070809@raszuk.net> <20111216220720.GB10812@diehard.n-r-g.com> <7309FCBCAE981B43ABBE69B31C8D21391A4770B078@EUSAACMS0701.eamcs.ericsson.se>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A4770B078@EUSAACMS0701.eamcs.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 22:50:35 -0000

Hello Jakob,

> Points made at the Taipei meeting:
>
> Old thinking: No service is better than unreliable service.
> New thinking: Partial service is better than no service.

I could agree with the above realizing the spectrum of applications we 
use BGP as database distributors today. But pls see below ...

> All errors will be logged for debugging and manual verification
> of the routing state.

Sorry but this is not sufficient. We have had number of discussions in 
the past both on the list and during the meetings which agreed to send 
to the peer details of the errors encountered. BGP Operational message 
proposal I have co-authored with Dave and Rob does just that. Somehow we 
are not seeing much progress there in the WG.

> Experience has shown that using a session reset causes severe disruption
> to routing, making it an inappropriate way to call attention
> to a protocol error. Such errors can be handled in a much
> less disruptive manner.

True. But for some strange reason no one recognized that we don't need 
to jump from one extreme to the other extreme.

Simple solution allowing for per BGP message ack would be sufficient to 
address most of the current BGP errors without impacting the critical 
mass of applications traversing over the same BGP session.

Literally I would see keeping the TCP session up (at least till someone 
smart will propose real short lived BGP database like updates), but 
having a way to rejecting the BGP message as opposed to playing colorful 
games how to cover it with various blankets to pretend nothing happened.

> Another point made:
>
> Error handling must be as simple as possible (and no simpler),
> lest bugs in the error handling make the medicine worse than the disease.

Somehow I don't think what we are observing here follows that point.

>  I think the error handling draft as it stands now lays out
> a well balanced solution to meet these criteria.

I would disagree. I would call well balanced a solution which would 
allow to accept or reject granularity of BGP Messages rather then 
tampering with them. And making error-handling on a per BGP Message 
boundaries seems to me like a very simple proposal.

Best regards,
R.

From ilya@nobulus.com  Fri Dec 16 15:41:26 2011
Return-Path: 
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 E69B721F85DB for ; Fri, 16 Dec 2011 15:41:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.651,  BAYES_00=-2.599]
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 H+vtuhxC8+TR for ; Fri, 16 Dec 2011 15:41:26 -0800 (PST)
Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 3402321F85BB for ; Fri, 16 Dec 2011 15:41:25 -0800 (PST)
Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 39F12172C1; Sat, 17 Dec 2011 00:41:23 +0100 (CET)
X-Virus-Scanned: amavisd-new at nobulus.com
Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YJ5lRyCdTOts; Sat, 17 Dec 2011 00:41:21 +0100 (CET)
Received: from [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684] (unknown [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id C438517128; Sat, 17 Dec 2011 00:41:20 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ilya Varlashkin 
In-Reply-To: <20111216220720.GB10812@diehard.n-r-g.com>
Date: Sat, 17 Dec 2011 00:41:17 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>  <4EEB78E5.6070809@raszuk.net> <20111216220720.GB10812@diehard.n-r-g.com>
To: Claudio Jeker 
X-Mailer: Apple Mail (2.1084)
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 23:41:27 -0000

On Dec 16, 2011, at 23:07 , Claudio Jeker wrote:
> On Fri, Dec 16, 2011 at 05:59:17PM +0100, Robert Raszuk wrote:
>> Jakob,
>>=20
>>> Say I get 2 LOCAL_PREF, one with value 100, the other 99. They are
>>> not identical, but I can clearly choose only one.
>>=20
>> If you want to know my preference .. I would prefer to drop the
>> session rather then to deal with peer which can not even build the
>> BGP Update message properly.
>>=20
>=20
> Me too. If a peer is unable to build a valid basic BGP packet it may =
do
> even worse things. The session is not trustworthy and it must be the
> direct neighbor at fault, so throwing a NOTIFICATION is the right way =
to
> handle this.
>=20
> Sometimes it is ok to error out instead of building insane fail saves
> (which make the system less stable and can backfire later on).

An alternative between these black and white behaviours could be to =
throw away whole update but inform the neighbour that it has send =
nonsense, same time applying some penalty points. If neighbour had =
once-in-life-time mistake it can resend proper update, everybody will be =
happy. If on the other hand neighbour persists sending rubbish, it will =
get more penalty points and eventually session can be supressed/dropped, =
possible also (automatically) putting neighbour into a quarantine group =
which will prevent this session from coming up again any time soon.

Having had recent experience with malformed attributes and "offending" =
sessions coming up over and over again just to disappear few moments =
later, I just don't see any help (in this particular context) from =
either dropping offending duplicate attributes or sending NOTIFICATION =
and dropping the session.

/iLya


From robert@raszuk.net  Fri Dec 16 15:58:49 2011
Return-Path: 
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 4D2B811E80A2 for ; Fri, 16 Dec 2011 15:58:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 jIqz4U382hpD for ; Fri, 16 Dec 2011 15:58:48 -0800 (PST)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 98A3311E8099 for ; Fri, 16 Dec 2011 15:58:48 -0800 (PST)
Received: (qmail 19023 invoked by uid 399); 16 Dec 2011 23:58:48 -0000
Received: from unknown (HELO ?192.168.1.57?) (83.9.126.71) by mail1310.opentransfer.com with ESMTP; 16 Dec 2011 23:58:48 -0000
X-Originating-IP: 83.9.126.71
Message-ID: <4EEBDB39.5080108@raszuk.net>
Date: Sat, 17 Dec 2011 00:58:49 +0100
From: Robert Raszuk 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Ilya Varlashkin 
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>  <4EEB78E5.6070809@raszuk.net> <20111216220720.GB10812@diehard.n-r-g.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 23:58:49 -0000

Hi Ilya,

> An alternative between these black and white behaviours could be to
> throw away whole update but inform the neighbour that it has send
> nonsense, same time applying some penalty points.

Glad you have said so. This would be per BGP message action + as you 
suggest signalling to a peer as well as accumulating the penalty. I 
think this would be good error handling tactics.

> If neighbour had once-in-life-time mistake

I think I am a bit stuck and just do not understand the genesis of those 
"once-in-life-time mistakes". Routers are not humans who make mistakes 
.. routers are just programs which usually give the same output if the 
input is still the same.

> If on the other hand neighbour persists sending rubbish, it
> will get more penalty points and eventually session can be
> supressed/dropped, possible also (automatically) putting neighbour
> into a quarantine group which will prevent this session from coming
> up again any time soon.

This will be really good IMHO.

Rather then only seeing tier 1s and 2s and optimizing for their view of 
BGP to try to cure infection in flight without crashing the entire plane 
what you are proposing would actually help to eliminate and stop the 
issue at it's source .. before it takes off again.

Best,
R.


From enkechen@cisco.com  Fri Dec 16 16:34:23 2011
Return-Path: 
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 9C38D1F0C3B for ; Fri, 16 Dec 2011 16:34:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, 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 mBxlZp2jI2Yb for ; Fri, 16 Dec 2011 16:34:23 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 18B9721F888A for ; Fri, 16 Dec 2011 16:34:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=964; q=dns/txt; s=iport; t=1324082063; x=1325291663; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=nNxaVkLRrR9IGFslkRBE2hgtAY4Cl5onKMal4PAycps=; b=gUpYWHXHuwzE3v/EtSCcTsjwk8GFdzc7OzihamuAoK5yh1X8WBVA5F+N hd/c0p+nswlP7l6O7fgxtCHL9GK9FiQvdY63VeWwk5EUTsVJWHCPq8Db9 DBeyFm18Ilg0nqc7Kw668uChCfWfq5k9zt2RcVynXZEW5KgUy0RPQb3Go Y=;
X-IronPort-AV: E=Sophos;i="4.71,366,1320624000"; d="scan'208";a="21190636"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 17 Dec 2011 00:34:23 +0000
Received: from dhcp-171-71-139-230.cisco.com (dhcp-171-71-139-230.cisco.com [171.71.139.230]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pBH0YMgu025141; Sat, 17 Dec 2011 00:34:22 GMT
Message-ID: <4EEBE42B.2020700@cisco.com>
Date: Fri, 16 Dec 2011 16:36:59 -0800
From: Enke Chen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: idr@ietf.org
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>  <4EEB78E5.6070809@raszuk.net> <20111216220720.GB10812@diehard.n-r-g.com>
In-Reply-To: <20111216220720.GB10812@diehard.n-r-g.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Dec 2011 00:34:23 -0000

Robert and Claudio,

Resetting the session is undesirable as we can not recover from the 
situation without a new version of the software.

-- Enke

On 12/16/11 2:07 PM, Claudio Jeker wrote:
> On Fri, Dec 16, 2011 at 05:59:17PM +0100, Robert Raszuk wrote:
>> Jakob,
>>
>>> Say I get 2 LOCAL_PREF, one with value 100, the other 99. They are
>>> not identical, but I can clearly choose only one.
>> If you want to know my preference .. I would prefer to drop the
>> session rather then to deal with peer which can not even build the
>> BGP Update message properly.
>>
> Me too. If a peer is unable to build a valid basic BGP packet it may do
> even worse things. The session is not trustworthy and it must be the
> direct neighbor at fault, so throwing a NOTIFICATION is the right way to
> handle this.
>
> Sometimes it is ok to error out instead of building insane fail saves
> (which make the system less stable and can backfire later on).


From enkechen@cisco.com  Fri Dec 16 17:03:11 2011
Return-Path: 
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 4D60821F8A66 for ; Fri, 16 Dec 2011 17:03:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, 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 ftGo1x7rVv46 for ; Fri, 16 Dec 2011 17:03:10 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id AEB7821F8A35 for ; Fri, 16 Dec 2011 17:03:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=1927; q=dns/txt; s=iport; t=1324083790; x=1325293390; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=RN8JKjdxdHMZiZasn/XUimYVNqMfKs4vgHuudBWRq+0=; b=Yl3DksjcPIT/6zHMMoWi1gIioS+hGgIbQ0at4Ch1aqQAE111gRzspSN7 7K5/xK2RkURRxGepszsnI61J/6gk9iH6t8KtY0YNtSkfX28dPExxEY90I S7WckITrz9rsFl0wjMbCXHd4xCbSbBGnrJ2fWN4s+wf8TT1nuIxjQTn3R E=;
X-IronPort-AV: E=Sophos;i="4.71,366,1320624000"; d="scan'208";a="21194925"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 17 Dec 2011 01:03:10 +0000
Received: from dhcp-171-71-139-230.cisco.com (dhcp-171-71-139-230.cisco.com [171.71.139.230]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBH13Ax5012383; Sat, 17 Dec 2011 01:03:10 GMT
Message-ID: <4EEBEAEB.8070304@cisco.com>
Date: Fri, 16 Dec 2011 17:05:47 -0800
From: Enke Chen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: idr@ietf.org
References: <20111216182324.17528.28150.idtracker@ietfa.amsl.com> <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net>
In-Reply-To: <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Dec 2011 01:03:11 -0000

Warren:

A couple comments:

   1) Is it really necessary to make AS 0 an error in the AGGREGATOR and 
AS4_AGGREGATOR attributes?  What is the gain?

   2) The error handling for AS4_PATH / AS4_AGGREGATOR is specified in 
rfc4893bis (draft-ietf-idr-rfc4893bis-04.txt). Thus it should be 
referenced if you specify AS 0 as an error for the AS4_PATH / 
AS4_AGGREGATOR.

Thanks.  -- Enke

do not have much impact.  Why

On 12/16/11 10:39 AM, Warren Kumari wrote:
> As requested, this version separates the error definition and error handling by pointing to the draft-ietf-idr-error-handling document...
>
>
> Thanks to everyone who provided feedback on -00.
> W
>
>
> On Dec 16, 2011, at 1:23 PM, internet-drafts@ietf.org wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF.
>>
>> 	Title           : Codification of AS 0 processing.
>> 	Author(s)       : Warren Kumari
>>                           Randy Bush
>>                           Heather Schiller
>> 	Filename        : draft-ietf-idr-as0-01.txt
>> 	Pages           : 6
>> 	Date            : 2011-12-16
>>
>>    This document proscribes the use of AS 0 in BGP OPEN and AS_PATH /
>>    AS4_PATH BGP attribute.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-idr-as0-01.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-as0-01.txt
>>
>> _______________________________________________
>> 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


From internet-drafts@ietf.org  Fri Dec 16 17:38:18 2011
Return-Path: 
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 367A621F84D4; Fri, 16 Dec 2011 17:38:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.555
X-Spam-Level: 
X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 ephurcLpF+za; Fri, 16 Dec 2011 17:38:17 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2D721F84B7; Fri, 16 Dec 2011 17:38:17 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64p1
Message-ID: <20111217013817.7903.27609.idtracker@ietfa.amsl.com>
Date: Fri, 16 Dec 2011 17:38:17 -0800
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-enhanced-route-refresh-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Dec 2011 01:38:18 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Inter-Domain Routing Working Group of=
 the IETF.

	Title           : Enhanced Route Refresh Capability for BGP-4
	Author(s)       : Keyur Patel
                          Enke Chen
                          Balaji Venkatachalapathy
	Filename        : draft-ietf-idr-bgp-enhanced-route-refresh-01.txt
	Pages           : 6
	Date            : 2011-12-16

   In this document we enhance the existing BGP route refresh mechanisms
   to provide for the demarcation of the beginning and the ending of a
   route refresh.  The enhancement can be used to facilitate on-line,
   non-disruptive consistency validations of BGP routing updates.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-enhanced-route-refre=
sh-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp-enhanced-route-refres=
h-01.txt


From jakob.heitz@ericsson.com  Fri Dec 16 19:16:21 2011
Return-Path: 
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 784C61F0C4E for ; Fri, 16 Dec 2011 19:16:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, 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 e8joWpqMRpoG for ; Fri, 16 Dec 2011 19:16:21 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id F29091F0C3B for ; Fri, 16 Dec 2011 19:16:20 -0800 (PST)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBH3GJtT003265; Fri, 16 Dec 2011 21:16:20 -0600
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 16 Dec 2011 22:16:13 -0500
From: Jakob Heitz 
To: "robert@raszuk.net" 
Date: Fri, 16 Dec 2011 22:16:12 -0500
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
Thread-Index: Acy8RSdJWcL35qzZQy2a/mtKcOekPAAJFQQg
Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A4770B0F5@EUSAACMS0701.eamcs.ericsson.se>
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>  <4EEB78E5.6070809@raszuk.net> <20111216220720.GB10812@diehard.n-r-g.com> <7309FCBCAE981B43ABBE69B31C8D21391A4770B078@EUSAACMS0701.eamcs.ericsson.se> <4EEBCB39.5060702@raszuk.net>
In-Reply-To: <4EEBCB39.5060702@raszuk.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Dec 2011 03:16:21 -0000

Either draft does not preclude the other.

--
Jakob Heitz. x25475. 510-566-2901

-----Original Message-----
From: Robert Raszuk [mailto:robert@raszuk.net]=20
Sent: Friday, December 16, 2011 2:51 PM
To: Jakob Heitz
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt

BGP Operational message=20
proposal I have co-authored with Dave and Rob does just that. Somehow we=20
are not seeing much progress there in the WG.=

From cjeker@diehard.n-r-g.com  Sat Dec 17 02:39:55 2011
Return-Path: 
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 C8C6021F8C04 for ; Sat, 17 Dec 2011 02:39:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 qsr+llMOPjby for ; Sat, 17 Dec 2011 02:39:55 -0800 (PST)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by ietfa.amsl.com (Postfix) with ESMTP id B5C4D21F8BFE for ; Sat, 17 Dec 2011 02:39:54 -0800 (PST)
Received: (qmail 31617 invoked by uid 1001); 17 Dec 2011 10:39:52 -0000
Date: Sat, 17 Dec 2011 11:39:52 +0100
From: Claudio Jeker 
To: idr@ietf.org
Message-ID: <20111217103952.GA7158@diehard.n-r-g.com>
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>  <4EEB78E5.6070809@raszuk.net> <20111216220720.GB10812@diehard.n-r-g.com> <4EEBE42B.2020700@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4EEBE42B.2020700@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Dec 2011 10:39:55 -0000

On Fri, Dec 16, 2011 at 04:36:59PM -0800, Enke Chen wrote:
> Robert and Claudio,
> 
> Resetting the session is undesirable as we can not recover from the
> situation without a new version of the software.
> 

I hope that the people writing that software are well aware of this and
that they fix the problem before it actually goes out into the wild.
Do you trust the software that is unable to follow the very basic rules of
the RFC of not duplicating an attribute to be bug free in other regards?
You think it will not mangle the ASPATH in ways that will suddenly direct
all your traffic to that router where it is dropped or looped back to you?

I understand that the error handling with optional transitive attributes
needs to be very careful and should not result in NOTIFICATIONS and
session drops. I do not understand that we try to keep direct neighbor
routers that act flaky (either because of dying HW or bad SW) up until the
situation is so bad that it may result in a much bigger issue.

Yes, the connection between the two neighbors in question will be down,
there will be no traffic exchanged over it (but we have a dynamic routing
protocol here and maybe it is able to find an alternate route to that site
that is not disrupted). Plus the rest of the network is not influenced by
this incident (because a good design would add enough redundancy into it).
On the other hand if bad routing information is spread through the network
it can cause a massive blackout (and this is what you actually try to
avoid in the first place).


Btw. I think the draft needs further explanation for the following cases:
- missing well-known attribute
   I guess this should be a treat-as-withdraw (but it is not said so)
- unrecognized well-known attribute
   Are all unknown attributes automatically optional?
   In other words is this draft killing the option of having new
   well-known attributes?
   Also what is the correct value of a unknown attribute?
- leftmost AS check in ASPATH (enforce neighbor-as)
   Shouldn't we allow the "enforce neighbor-as" to send a NOTIFICATION as
   it is doing so now? Because else we can remove that from the RFC and
   tell people to filter on the leftmost AS (has the same effect).

-- 
:wq Claudio

> -- Enke
> 
> On 12/16/11 2:07 PM, Claudio Jeker wrote:
> >On Fri, Dec 16, 2011 at 05:59:17PM +0100, Robert Raszuk wrote:
> >>Jakob,
> >>
> >>>Say I get 2 LOCAL_PREF, one with value 100, the other 99. They are
> >>>not identical, but I can clearly choose only one.
> >>If you want to know my preference .. I would prefer to drop the
> >>session rather then to deal with peer which can not even build the
> >>BGP Update message properly.
> >>
> >Me too. If a peer is unable to build a valid basic BGP packet it may do
> >even worse things. The session is not trustworthy and it must be the
> >direct neighbor at fault, so throwing a NOTIFICATION is the right way to
> >handle this.
> >
> >Sometimes it is ok to error out instead of building insane fail saves
> >(which make the system less stable and can backfire later on).
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

From ilya@nobulus.com  Sat Dec 17 07:34:33 2011
Return-Path: 
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 E9BFA21F87D9 for ; Sat, 17 Dec 2011 07:34:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.467
X-Spam-Level: 
X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 W0KsLaA0v7P9 for ; Sat, 17 Dec 2011 07:34:31 -0800 (PST)
Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id BEEFD21F87C5 for ; Sat, 17 Dec 2011 07:34:30 -0800 (PST)
Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 790EB172C1; Sat, 17 Dec 2011 16:34:29 +0100 (CET)
X-Virus-Scanned: amavisd-new at nobulus.com
Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vgxgkGNRBccF; Sat, 17 Dec 2011 16:34:26 +0100 (CET)
Received: from [10.174.88.90] (tmo-103-90.customers.d1-online.com [80.187.103.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 7A22017141; Sat, 17 Dec 2011 16:34:26 +0100 (CET)
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>  <4EEB78E5.6070809@raszuk.net> <20111216220720.GB10812@diehard.n-r-g.com> <4EEBE42B.2020700@cisco.com> <20111217103952.GA7158@diehard.n-r-g.com>
In-Reply-To: <20111217103952.GA7158@diehard.n-r-g.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <44D2DDE4-E482-4B5C-8A3B-3DE11C8FB864@nobulus.com>
X-Mailer: iPhone Mail (9A405)
From: Ilya Varlashkin 
Date: Sat, 17 Dec 2011 16:35:36 +0100
To: Claudio Jeker 
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Dec 2011 15:34:34 -0000

NOTIFICATION as it is now won't prevent broken neighbour from coming up agai=
n. Session going down or up can rise CPU utilisation (=3D=3Daffect control p=
lane) for several minutes. And not only on the router that shuts broken sess=
ion but potentially on many other due to constant flapping of the routes.

Bottom line: simple resetting session with broken neighbour is not a solutio=
n.

/iLya


On 17 Dec 2011, at 11:39, Claudio Jeker  wrote:

> On Fri, Dec 16, 2011 at 04:36:59PM -0800, Enke Chen wrote:
>> Robert and Claudio,
>>=20
>> Resetting the session is undesirable as we can not recover from the
>> situation without a new version of the software.
>>=20
>=20
> I hope that the people writing that software are well aware of this and
> that they fix the problem before it actually goes out into the wild.
> Do you trust the software that is unable to follow the very basic rules of=

> the RFC of not duplicating an attribute to be bug free in other regards?
> You think it will not mangle the ASPATH in ways that will suddenly direct
> all your traffic to that router where it is dropped or looped back to you?=

>=20
> I understand that the error handling with optional transitive attributes
> needs to be very careful and should not result in NOTIFICATIONS and
> session drops. I do not understand that we try to keep direct neighbor
> routers that act flaky (either because of dying HW or bad SW) up until the=

> situation is so bad that it may result in a much bigger issue.
>=20
> Yes, the connection between the two neighbors in question will be down,
> there will be no traffic exchanged over it (but we have a dynamic routing
> protocol here and maybe it is able to find an alternate route to that site=

> that is not disrupted). Plus the rest of the network is not influenced by
> this incident (because a good design would add enough redundancy into it).=

> On the other hand if bad routing information is spread through the network=

> it can cause a massive blackout (and this is what you actually try to
> avoid in the first place).
>=20
>=20
> Btw. I think the draft needs further explanation for the following cases:
> - missing well-known attribute
>   I guess this should be a treat-as-withdraw (but it is not said so)
> - unrecognized well-known attribute
>   Are all unknown attributes automatically optional?
>   In other words is this draft killing the option of having new
>   well-known attributes?
>   Also what is the correct value of a unknown attribute?
> - leftmost AS check in ASPATH (enforce neighbor-as)
>   Shouldn't we allow the "enforce neighbor-as" to send a NOTIFICATION as
>   it is doing so now? Because else we can remove that from the RFC and
>   tell people to filter on the leftmost AS (has the same effect).
>=20
> --=20
> :wq Claudio
>=20
>> -- Enke
>>=20
>> On 12/16/11 2:07 PM, Claudio Jeker wrote:
>>> On Fri, Dec 16, 2011 at 05:59:17PM +0100, Robert Raszuk wrote:
>>>> Jakob,
>>>>=20
>>>>> Say I get 2 LOCAL_PREF, one with value 100, the other 99. They are
>>>>> not identical, but I can clearly choose only one.
>>>> If you want to know my preference .. I would prefer to drop the
>>>> session rather then to deal with peer which can not even build the
>>>> BGP Update message properly.
>>>>=20
>>> Me too. If a peer is unable to build a valid basic BGP packet it may do
>>> even worse things. The session is not trustworthy and it must be the
>>> direct neighbor at fault, so throwing a NOTIFICATION is the right way to=

>>> handle this.
>>>=20
>>> Sometimes it is ok to error out instead of building insane fail saves
>>> (which make the system less stable and can backfire later on).
>>=20
>> _______________________________________________
>> 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
>=20

From warren@kumari.net  Sat Dec 17 09:26:14 2011
Return-Path: 
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 3278421F8AA9 for ; Sat, 17 Dec 2011 09:26:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.276
X-Spam-Level: 
X-Spam-Status: No, score=-106.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 eUyolnT5EXuP for ; Sat, 17 Dec 2011 09:26:13 -0800 (PST)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id A3F1E21F8AA8 for ; Sat, 17 Dec 2011 09:26:13 -0800 (PST)
Received: from [192.168.0.105] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 40E401B401ED; Sat, 17 Dec 2011 12:26:12 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari 
In-Reply-To: <4EEBEAEB.8070304@cisco.com>
Date: Sat, 17 Dec 2011 12:26:10 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <0156DFD0-B706-42B0-93AB-89C9E6E252FD@kumari.net>
References: <20111216182324.17528.28150.idtracker@ietfa.amsl.com> <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net> <4EEBEAEB.8070304@cisco.com>
To: Enke Chen 
X-Mailer: Apple Mail (2.1084)
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Dec 2011 17:26:14 -0000

On Dec 16, 2011, at 8:05 PM, Enke Chen wrote:

> Warren:
>=20
> A couple comments:
>=20
>  1) Is it really necessary to make AS 0 an error in the AGGREGATOR and =
AS4_AGGREGATOR attributes?  What is the gain?

I'll double check with co-authors on Monday -- I don't think it is =
strictly necessary to prevent attack, rather it seemed more elegant to =
check AS 0 where ever it occurs.

It was brought up on the NANOG list that some vendors support zero'ing =
out the AGGREGATOR (see Junipers "no-aggregator-id" as an example -- =
this appears to only zero out the router ID, but I haven't checked all =
implementations), so checking for AS 0 in the .*AGGREGATOR may be a bad =
idea, so at the moment I'm leaning towards removing it (obviously, this =
being a WG doc, with the WG's approval)

>=20
>  2) The error handling for AS4_PATH / AS4_AGGREGATOR is specified in =
rfc4893bis (draft-ietf-idr-rfc4893bis-04.txt). Thus it should be =
referenced if you specify AS 0 as an error for the AS4_PATH / =
AS4_AGGREGATOR.
>=20

Doh! This was mentioned a few times and I intended to do so, but it =
completely slipped my mind when typing... Thanks for reminding me....

W


> Thanks.  -- Enke
>=20
> do not have much impact.  Why
>=20
> On 12/16/11 10:39 AM, Warren Kumari wrote:
>> As requested, this version separates the error definition and error =
handling by pointing to the draft-ietf-idr-error-handling document...
>>=20
>>=20
>> Thanks to everyone who provided feedback on -00.
>> W
>>=20
>>=20
>> On Dec 16, 2011, at 1:23 PM, internet-drafts@ietf.org wrote:
>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories. This draft is a work item of the Inter-Domain Routing =
Working Group of the IETF.
>>>=20
>>> 	Title           : Codification of AS 0 processing.
>>> 	Author(s)       : Warren Kumari
>>>                          Randy Bush
>>>                          Heather Schiller
>>> 	Filename        : draft-ietf-idr-as0-01.txt
>>> 	Pages           : 6
>>> 	Date            : 2011-12-16
>>>=20
>>>   This document proscribes the use of AS 0 in BGP OPEN and AS_PATH /
>>>   AS4_PATH BGP attribute.
>>>=20
>>>=20
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-idr-as0-01.txt
>>>=20
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>> This Internet-Draft can be retrieved at:
>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-as0-01.txt
>>>=20
>>> _______________________________________________
>>> Idr mailing list
>>> Idr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/idr
>>>=20
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>=20


From bruno.decraene@orange.com  Mon Dec 19 03:37:33 2011
Return-Path: 
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 BA5AB21F853E for ; Mon, 19 Dec 2011 03:37:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, UNPARSEABLE_RELAY=0.001]
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 h6GcN8h1VwMO for ; Mon, 19 Dec 2011 03:37:32 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 73D6921F852E for ; Mon, 19 Dec 2011 03:37:32 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 1E43A22C5A7; Mon, 19 Dec 2011 12:37:29 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id F28A3238067; Mon, 19 Dec 2011 12:37:28 +0100 (CET)
Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.01.0323.000; Mon, 19 Dec 2011 12:37:28 +0100
From: 
To: Claudio Jeker , "idr@ietf.org" 
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
Thread-Index: AQHMvD8UGYSVnoupTWeVZcaRPUwVOZXfHreAgACocQCAAzNUkA==
Date: Mon, 19 Dec 2011 11:37:27 +0000
Message-ID: <26782_1324294649_4EEF21F9_26782_3157_1_53C29892C857584299CBF5D05346208A010D51@PEXCVZYM11.corporate.adroot.infra.ftgroup>
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>  <4EEB78E5.6070809@raszuk.net>	<20111216220720.GB10812@diehard.n-r-g.com> <4EEBE42B.2020700@cisco.com> <20111217103952.GA7158@diehard.n-r-g.com>
In-Reply-To: <20111217103952.GA7158@diehard.n-r-g.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.19.104814
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 11:37:33 -0000

As some of the recent comments are more on the requirement side, it may be =
useful to remind that there is a requirement draft on BGP error handling in=
 the GROW WG: draft-ietf-grow-ops-reqs-for-bgp-error-handling-02 Might want=
 to read and comment.

More inline (a bit long)

>From: Claudio Jeker Sent: Saturday, December 17, 2011 11:40 AM
>> Robert and Claudio,
>>
>> Resetting the session is undesirable as we can not recover from the
>> situation without a new version of the software.
>>
>
>I hope that the people writing that software are well aware of this and
>that they fix the problem before it actually goes out into the wild.

I don't believe tests will ever be able to detect all bugs. So we need to b=
e prepare to handle them.

>Do you trust the software that is unable to follow the very basic rules of
>the RFC of not duplicating an attribute to be bug free in other regards?
>You think it will not mangle the ASPATH in ways that will suddenly direct
>all your traffic to that router where it is dropped or looped back to you?
>
>I understand that the error handling with optional transitive attributes
>needs to be very careful and should not result in NOTIFICATIONS and
>session drops. I do not understand that we try to keep direct neighbor
>routers that act flaky (either because of dying HW or bad SW) up until the
>situation is so bad that it may result in a much bigger issue.

I don't believe in the "so bad SW" argument:
- Yes, something is bad, there is no way to figure it out in live, it would=
 be safer to shut to not trust this router anymore and shut the BGP session=
. But to keep it safe, going that way, we should shut the BGP session forev=
er, shut the IGP adjacencies if any (it's so bad I can't trust it/it's FIB =
any more), flood -at least in the AS- the OS version to warn all routers th=
at that OS (HW) should not be trusted and that all routers should shut thei=
r BGP sessions with this bad SW... It may locally be seem as "safer", but t=
his has consequences in term of network availability. Another valid path, t=
he "cautious path" is to try to limit the consequences of the error (as def=
ined in draft-ietf-idr-error-handling). Frankly, between the "safe path" an=
d the "cautious path" the latter also seems a very reasonable option (and d=
efinitely the safer in term of security / DOS consideration). Yes, sometime=
s it will result in a bad decision with a bad neighbor still being used. Bu=
t let's try this new path because we have tried the first one and we don't =
like it.
- we should also remember that we are mostly talking about events on router=
s from majors companies doing significant effort to carefully implement and=
 test it, with SP doing furthers tests and then OS/routers running for mont=
hs without any issue. Seems strange to suddenly assume they are bad and sho=
uld not been talked to anymore.

I agree that optional transitive attributes are the most most likely to cau=
se issues. However I would prefer that no single BGP update cause the BGP s=
ession to be shut down. Including well known mandatory attributes.=20
e.g. let's take the AS_PATH, probably the most well known mandatory one. If=
 I were the first AS to deploy draft-ietf-idr-as0, if one remote AS adverti=
se an update with AS 0 in the AS_PATH, If I don't treat that error as withd=
raw (but as notification) I would end up tearing down all my BGP sessions (=
nominal, and _all_ backup ones) toward that NRLI and all the NLRI advertise=
d over those sessions. That could be lots of NLRI (>50%), with no backup pa=
th, and forever until someone find the issue and the solution.

>Yes, the connection between the two neighbors in question will be down,
>there will be no traffic exchanged over it (but we have a dynamic routing
>protocol here and maybe it is able to find an alternate route to that site
>that is not disrupted).=20

You are assuming a local error with your neighbor. Chances are that errors =
have been trigger by a specific state and that all backup paths also got th=
at state. Hence you can't assume that there would be a backup path if you c=
hoose to shut down the session.


However, to better take your valid case (a single bad neighbor) into accoun=
t one could:
- keep the BGP session up (as per draft-ietf-idr-error-handling-01)
- in addition, flag all routes received (and not treated as withdraw) over =
that session with an IANA community. Then SP would be free to lower the LOC=
AL_PREF (or cost community) of those routes so that others routers in the A=
S would prefer another path if another good path were available.

That would probably better cover both cases (single bad neighbor, global is=
sue with all BGP session affected), at the cost of creating BGP churn at pr=
obably a bad moment (but just like the existing RFC 4271 does).

Bruno

>Plus the rest of the network is not influenced by
>this incident (because a good design would add enough redundancy into it).
>On the other hand if bad routing information is spread through the network
>it can cause a massive blackout (and this is what you actually try to
>avoid in the first place).
>
>
>Btw. I think the draft needs further explanation for the following cases:
>- missing well-known attribute
>   I guess this should be a treat-as-withdraw (but it is not said so)
>- unrecognized well-known attribute
>   Are all unknown attributes automatically optional?
>   In other words is this draft killing the option of having new
>   well-known attributes?
>   Also what is the correct value of a unknown attribute?
>- leftmost AS check in ASPATH (enforce neighbor-as)
>   Shouldn't we allow the "enforce neighbor-as" to send a NOTIFICATION as
>   it is doing so now? Because else we can remove that from the RFC and
>   tell people to filter on the leftmost AS (has the same effect).
>
>--
>:wq Claudio
>
>> -- Enke
>>
>> On 12/16/11 2:07 PM, Claudio Jeker wrote:
>> >On Fri, Dec 16, 2011 at 05:59:17PM +0100, Robert Raszuk wrote:
>> >>Jakob,
>> >>
>> >>>Say I get 2 LOCAL_PREF, one with value 100, the other 99. They are
>> >>>not identical, but I can clearly choose only one.
>> >>If you want to know my preference .. I would prefer to drop the
>> >>session rather then to deal with peer which can not even build the
>> >>BGP Update message properly.
>> >>
>> >Me too. If a peer is unable to build a valid basic BGP packet it may do
>> >even worse things. The session is not trustworthy and it must be the
>> >direct neighbor at fault, so throwing a NOTIFICATION is the right way to
>> >handle this.
>> >
>> >Sometimes it is ok to error out instead of building insane fail saves
>> >(which make the system less stable and can backfire later on).
>>
>> _______________________________________________
>> 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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if th=
is message was modified, changed or falsified.
Thank you.


From robert@raszuk.net  Mon Dec 19 06:25:07 2011
Return-Path: 
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 AEBA521F8B7D for ; Mon, 19 Dec 2011 06:25:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 zWpZRbkkmIg0 for ; Mon, 19 Dec 2011 06:25:07 -0800 (PST)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 066E021F8B38 for ; Mon, 19 Dec 2011 06:25:07 -0800 (PST)
Received: (qmail 19524 invoked by uid 399); 19 Dec 2011 14:25:06 -0000
Received: from unknown (HELO ?192.168.1.91?) (83.31.234.225) by mail1310.opentransfer.com with ESMTP; 19 Dec 2011 14:25:06 -0000
X-Originating-IP: 83.31.234.225
Message-ID: <4EEF4942.6050105@raszuk.net>
Date: Mon, 19 Dec 2011 15:25:06 +0100
From: Robert Raszuk 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: bruno.decraene@orange.com
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>  <4EEB78E5.6070809@raszuk.net>	<20111216220720.GB10812@diehard.n-r-g.com> <4EEBE42B.2020700@cisco.com> <20111217103952.GA7158@diehard.n-r-g.com> <26782_1324294649_4EEF21F9_26782_3157_1_53C29892C857584299CBF5D05346208A010D51@PEXCVZYM11.corporate.adroot.infra.ftgroup>
In-Reply-To: <26782_1324294649_4EEF21F9_26782_3157_1_53C29892C857584299CBF5D05346208A010D51@PEXCVZYM11.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 14:25:07 -0000

Hi Bruno,

> You are assuming a local error with your neighbor. Chances are that
> errors have been trigger by a specific state and that all backup
> paths also got that state. Hence you can't assume that there would be
> a backup path if you choose to shut down the session.

Reasonable networks have many neighbors. The like hood that due to 
mandatory BGP attribute error we will experience an outage from all 
neighbors is rather quite unlikely IMHO.

However I am not opposing recommendations of 
draft-ietf-idr-error-handling. What I am not quite comfortable with is 
to assume that this should be the new default behaviour.

You say that "we don't like it" what is happening today. One may argue 
that "some do not like it some do". Those who do not like it do they 
really use already available tools like multisession deployed in 
production to limit one SAFI impacting other SAFIs ? Could they just not 
use validating layer before the BGP update hits RP ?

The fact that draft-ietf-idr-error-handling seems to be targetting to 
update 4271 means that when I boot router with new software the 
behaviour will change and now all of the operations teams worldwide need 
to develop new syslog parsing scripts to catch the new error categories. 
Today they see it easily as session is going down.

--

Also note that if this is hacker on the CE trying to mess with his EBGP 
session towards PE to perhaps destroy other VPNs on such PE keeping the 
session up is only helping him to better attack the PE. Is this the 
aspect of "improvement" you have all considered ?

--

Last is I think the point that Ilya brought. While we are at the topic 
let's address the flapping session problem (assume that non of 
conditions in the new draft apply) and that session is getting resetted. 
It seems valid to me to accumulate penalty on such consecutive resets 
and keep the session shut when such penalty reaches some value. While 
some may say that this is implementation thing some may also see 
reasonable to define what the behaviour should be.

Best regards,
R.

From bruno.decraene@orange.com  Mon Dec 19 07:43:19 2011
Return-Path: 
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 3704021F8B82 for ; Mon, 19 Dec 2011 07:43:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.298
X-Spam-Level: 
X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
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 Cbf0Tc8itHeR for ; Mon, 19 Dec 2011 07:43:18 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id EB95021F8801 for ; Mon, 19 Dec 2011 07:43:17 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 06C192DC988; Mon, 19 Dec 2011 16:43:17 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id DAB094C066; Mon, 19 Dec 2011 16:43:16 +0100 (CET)
Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.01.0323.000; Mon, 19 Dec 2011 16:43:16 +0100
From: 
To: "robert@raszuk.net" 
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
Thread-Index: AQHMvloAGYSVnoupTWeVZcaRPUwVOZXjOikQ
Date: Mon, 19 Dec 2011 15:43:15 +0000
Message-ID: <22583_1324309396_4EEF5B94_22583_6701_1_53C29892C857584299CBF5D05346208A010EC8@PEXCVZYM11.corporate.adroot.infra.ftgroup>
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>  <4EEB78E5.6070809@raszuk.net>	<20111216220720.GB10812@diehard.n-r-g.com> <4EEBE42B.2020700@cisco.com> <20111217103952.GA7158@diehard.n-r-g.com> <26782_1324294649_4EEF21F9_26782_3157_1_53C29892C857584299CBF5D05346208A010D51@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4EEF4942.6050105@raszuk.net>
In-Reply-To: <4EEF4942.6050105@raszuk.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.3]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.19.141514
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 15:43:19 -0000

Hi Robert,

>From: Robert Raszuk [mailto:robert@raszuk.net]>Sent: Monday, December 19, =
2011 3:25 PM
>
>Hi Bruno,
>
>> You are assuming a local error with your neighbor. Chances are that
>> errors have been trigger by a specific state and that all backup
>> paths also got that state. Hence you can't assume that there would be
>> a backup path if you choose to shut down the session.
>
>Reasonable networks have many neighbors. The like hood that due to
>mandatory BGP attribute error we will experience an outage from all
>neighbors is rather quite unlikely IMHO.

Please refer to my previous example: I'm the first AS (on the path) to impl=
ement draft-ietf-idr-as0. AS_X originates route Z/z with an AS 0 in the AS_=
PATH.
The number of neighbors is of little relevance as from all neighbors advert=
ising Z/z, I will receive an invalid AS_PATH.
For a tier-1 like AS, the more neighbor ASes advertising a path to Z/z, the=
 more sessions will go done.
For a lower tier AS, typically less BGP session will go done but each sessi=
on would carry more NLRI (e.g. the whole Internet as advertised by its upst=
ream transit).

And that's a single example. I'm sure reality will be much more creative.

BTW, I agree with you that this is quite unlikely. However when this happen=
, how do we want to react?

>
>However I am not opposing recommendations of
>draft-ietf-idr-error-handling. What I am not quite comfortable with is
>to assume that this should be the new default behaviour.
>
>You say that "we don't like it" what is happening today. One may argue
>that "some do not like it some do".=20

Sure. But again, that's a discussion for draft-ietf-grow-ops-reqs-for-bgp-e=
rror-handling-02

>Those who do not like it do they
>really use already available tools like multisession deployed in
>production to limit one SAFI impacting other SAFIs ?=20

Bringing down a whole AFI/SAFI is already too much. E.g. 1/1 (Internet) or =
128/1 (L3 VPN) especially on an iBGP session with your BGP Route Reflector.

>Could they just not
>use validating layer before the BGP update hits RP ?

Sorry, I don't see what you are refering to.

>The fact that draft-ietf-idr-error-handling seems to be targetting to
>update 4271 means that when I boot router with new software the
>behaviour will change and now all of the operations teams worldwide need
>to develop new syslog parsing scripts to catch the new error categories.
>Today they see it easily as session is going down.

I agree. I already brought that point both during the meeting and on the ma=
iling list: http://www.ietf.org/mail-archive/web/idr/current/msg04710.html

Ideally _current_ operations teams/tools should have a chance to learn abou=
t the issue (degraded behavior) even if they have not been "upgraded". Some=
thing using the same news channel that when BGP sessions are reported down.=
 (e.g. a new "bgp4V2PeerState" value "established-UPDATES in error (7)" whi=
ch would probably also trigger "bgp4V2BackwardTransitionNotification NOTIFI=
CATION-TYPE", but I'm not really into the MIB stuff so I would prefer that =
some else do the job).

Could authors of draft-ietf-idr-error-handling consider addressing the abov=
e point? Many thanks.


>--
>
>Also note that if this is hacker on the CE trying to mess with his EBGP
>session towards PE to perhaps destroy other VPNs on such PE keeping the
>session up is only helping him to better attack the PE. Is this the
>aspect of "improvement" you have all considered ?

IMHO, having the ability to trigger a BGP session down further in the netwo=
rk is a bigger attack vector.

>--
>
>Last is I think the point that Ilya brought. While we are at the topic
>let's address the flapping session problem (assume that non of
>conditions in the new draft apply) and that session is getting resetted.
>It seems valid to me to accumulate penalty on such consecutive resets
>and keep the session shut when such penalty reaches some value. While
>some may say that this is implementation thing some may also see
>reasonable to define what the behaviour should be.

Would DampPeerOscillations (=A78.1.1. of RFC 4271) do the job or are you th=
inking about something else?

Best regards,
Bruno
>Best regards,
>R.

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if th=
is message was modified, changed or falsified.
Thank you.


From robert@raszuk.net  Mon Dec 19 08:08:52 2011
Return-Path: 
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 09A431F0C4B for ; Mon, 19 Dec 2011 08:08:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 7kHmZ+E1kyDr for ; Mon, 19 Dec 2011 08:08:51 -0800 (PST)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id D2B301F0C3B for ; Mon, 19 Dec 2011 08:08:50 -0800 (PST)
Received: (qmail 29873 invoked by uid 399); 19 Dec 2011 16:08:50 -0000
Received: from unknown (HELO ?192.168.1.91?) (83.31.234.225) by mail1310.opentransfer.com with ESMTP; 19 Dec 2011 16:08:50 -0000
X-Originating-IP: 83.31.234.225
Message-ID: <4EEF6192.1090901@raszuk.net>
Date: Mon, 19 Dec 2011 17:08:50 +0100
From: Robert Raszuk 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: bruno.decraene@orange.com
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>  <4EEB78E5.6070809@raszuk.net>	<20111216220720.GB10812@diehard.n-r-g.com> <4EEBE42B.2020700@cisco.com> <20111217103952.GA7158@diehard.n-r-g.com> <26782_1324294649_4EEF21F9_26782_3157_1_53C29892C857584299CBF5D05346208A010D51@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4EEF4942.6050105@raszuk.net> <22583_1324309396_4EEF5B94_22583_6701_1_53C29892C857584299CBF5D05346208A010EC8@PEXCVZYM11.corporate.adroot.infra.ftgroup>
In-Reply-To: <22583_1324309396_4EEF5B94_22583_6701_1_53C29892C857584299CBF5D05346208A010EC8@PEXCVZYM11.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 16:08:52 -0000

Hi Bruno,

> Please refer to my previous example: I'm the first AS (on the path)
> to implement draft-ietf-idr-as0. AS_X originates route Z/z with an AS
> 0 in the AS_PATH. The number of neighbors is of little relevance as
> from all neighbors advertising Z/z, I will receive an invalid
> AS_PATH. For a tier-1 like AS, the more neighbor ASes advertising a
> path to Z/z, the more sessions will go done. For a lower tier AS,
> typically less BGP session will go done but each session would carry
> more NLRI (e.g. the whole Internet as advertised by its upstream
> transit).
>
> And that's a single example. I'm sure reality will be much more
> creative.
>
> BTW, I agree with you that this is quite unlikely. However when this
> happen, how do we want to react?

draft-ietf-idr-as0 implementation should generate "warning-only" in the 
syslog rather then attempting to reset the session. Then your NOC can 
deal with it.

It is pretty bad to upgrade the router with new image supporting 
draft-ietf-idr-as0 and suddenly see session resets or treat-as-withdraws 
going on left and right.

Then you could use "replace-as knob" which is available in most of the 
BGP implementations and replace AS 0 with your AS in the AS_PATH in 
ingress. Warning will disappear from syslog giving you enough time to 
talk to those who inject it and perhaps letting them know that IDR came 
with new draft/rfc ;)

>> You say that "we don't like it" what is happening today. One may
>> argue that "some do not like it some do".
>
> Sure. But again, that's a discussion for
> draft-ietf-grow-ops-reqs-for-bgp-error-handling-02

Well there are many ways to meet requirements. One way as I suggested 
was to treat errors on a per Update message not per attributes. Add 
sequence numbers to Update Messages and notify peers that some of those 
have contained the errors. Note that due to BGP nature treat-as-withdraw 
may still be applicable.

> Bringing down a whole AFI/SAFI is already too much. E.g. 1/1
> (Internet) or 128/1 (L3 VPN) especially on an iBGP session with your
> BGP Route Reflector.

See above.


>> The fact that draft-ietf-idr-error-handling seems to be targetting
>> to update 4271 means that when I boot router with new software the
>> behaviour will change and now all of the operations teams worldwide
>> need to develop new syslog parsing scripts to catch the new error
>> categories. Today they see it easily as session is going down.
>
> I agree. I already brought that point both during the meeting and on
> the mailing list:
> http://www.ietf.org/mail-archive/web/idr/current/msg04710.html
>
> Ideally _current_ operations teams/tools should have a chance to
> learn about the issue (degraded behavior) even if they have not been
> "upgraded". Something using the same news channel that when BGP
> sessions are reported down. (e.g. a new "bgp4V2PeerState" value
> "established-UPDATES in error (7)" which would probably also trigger
> "bgp4V2BackwardTransitionNotification NOTIFICATION-TYPE", but I'm not
> really into the MIB stuff so I would prefer that some else do the
> job).
>
> Could authors of draft-ietf-idr-error-handling consider addressing
> the above point? Many thanks.

Glad we agree here !

>> Also note that if this is hacker on the CE trying to mess with his
>> EBGP session towards PE to perhaps destroy other VPNs on such PE
>> keeping the session up is only helping him to better attack the PE.
>> Is this the aspect of "improvement" you have all considered ?
>
> IMHO, having the ability to trigger a BGP session down further in the
> network is a bigger attack vector.

True - but former is a targeted one the latter seems like a random one. 
I think we should try to avoid both.


>> Last is I think the point that Ilya brought. While we are at the
>> topic let's address the flapping session problem (assume that non
>> of conditions in the new draft apply) and that session is getting
>> resetted. It seems valid to me to accumulate penalty on such
>> consecutive resets and keep the session shut when such penalty
>> reaches some value. While some may say that this is implementation
>> thing some may also see reasonable to define what the behaviour
>> should be.
>
> Would DampPeerOscillations (§8.1.1. of RFC 4271) do the job or are
> you thinking about something else?

I am not sure if DampPeerOscillations kicks in due to error triggered 
sessions resets. It seems reading 4271 it is to catch session 
connect/session disconnect case. I think Ilya observed recently that it 
does not. But it is better that he comments here.

Best,
R.

From ilya@nobulus.com  Mon Dec 19 11:29:36 2011
Return-Path: 
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 5276011E80B3 for ; Mon, 19 Dec 2011 11:29:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 D9uFSUnStc9Y for ; Mon, 19 Dec 2011 11:29:35 -0800 (PST)
Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id C2EA511E80A0 for ; Mon, 19 Dec 2011 11:29:35 -0800 (PST)
Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 76020172D4; Mon, 19 Dec 2011 20:29:33 +0100 (CET)
X-Virus-Scanned: amavisd-new at nobulus.com
Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id deMnzkSXXT5n; Mon, 19 Dec 2011 20:29:30 +0100 (CET)
Received: from [192.168.2.111] (dslb-088-064-250-069.pools.arcor-ip.net [88.64.250.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 2DB5F172C1; Mon, 19 Dec 2011 20:29:27 +0100 (CET)
Message-Id: 
From: Ilya Varlashkin 
To: robert@raszuk.net
In-Reply-To: <4EEF6192.1090901@raszuk.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 19 Dec 2011 20:29:18 +0100
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>  <4EEB78E5.6070809@raszuk.net>	<20111216220720.GB10812@diehard.n-r-g.com> <4EEBE42B.2020700@cisco.com> <20111217103952.GA7158@diehard.n-r-g.com> <26782_1324294649_4EEF21F9_26782_3157_1_53C29892C857584299CBF5D05346208A010D51@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4EEF4942.6050105@raszuk.net> <22583_1324309396_4EEF5B94_22583_6701_1_53C29892C857584299CBF5D05346208A010EC8@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4EEF6192.1090901@raszuk.net>
X-Mailer: Apple Mail (2.936)
Cc: bruno.decraene@orange.com, "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 19:29:36 -0000

On 19Dec 2011, at 17:08, Robert Raszuk wrote:

>> Would DampPeerOscillations (=A78.1.1. of RFC 4271) do the job or are
>> you thinking about something else?
>
> I am not sure if DampPeerOscillations kicks in due to error =20
> triggered sessions resets. It seems reading 4271 it is to catch =20
> session connect/session disconnect case. I think Ilya observed =20
> recently that it does not. But it is better that he comments here.
>

My experience was with an implementation sending malformed NLRI. As =20
expected, this was causing session reset, flushing all the good routes =20=

as well, then coming up and "marry go 'round". Although logic =20
described for DampPeerOscillations is similar to what could have =20
remedied such behaviour, the actual values specified in rfc4271 won't =20=

catch the exact problem that I've encountered. 4271 specifies 10 times =20=

within 5 minutes and max IdleHoldTime of only 2 minutes, whereas in my =20=

case getting getting all routes was taking 5-20 minutes.

The behaviour I've observed isn't unique to my network and not even to =20=

single vendor. Few months ago one could observe constant session flaps =20=

in many networks due to malformed attribute, then coming up again and =20=

on and on, and DampPeerOscillations provided no significant protection.

Kind regards,
iLya


From stephane.litkowski@orange.com  Tue Dec 27 02:34:20 2011
Return-Path: 
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 612D321F8586 for ; Tue, 27 Dec 2011 02:34:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.952
X-Spam-Level: 
X-Spam-Status: No, score=0.952 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_82=0.6, UNPARSEABLE_RELAY=0.001]
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 T5sdRtWEEuAs for ; Tue, 27 Dec 2011 02:34:19 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBEC21F8564 for ; Tue, 27 Dec 2011 02:34:18 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 4F6A318C380; Tue, 27 Dec 2011 11:34:15 +0100 (CET)
Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 333594C06B; Tue, 27 Dec 2011 11:34:15 +0100 (CET)
Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.46]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Dec 2011 11:34:14 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 27 Dec 2011 11:33:55 +0100
Message-ID: <1701_1324982055_4EF99F27_1701_27016_1_4FC3556A36EE3646A09DAA60429F533507861570@PUEXCBL0.nanterre.francetelecom.fr>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
Thread-Index: Acy8TD23qW+N7m1wQU6TMdcmHllaZgIMlPDg
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com><37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com><4EEB6C23.4080803@raszuk.net><4EEB78E5.6070809@raszuk.net><20111216220720.GB10812@diehard.n-r-g.com> 
From: 
To: "Ilya Varlashkin" 
X-OriginalArrivalTime: 27 Dec 2011 10:34:14.0177 (UTC) FILETIME=[13F95910:01CCC483]
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.27.61516
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Dec 2011 10:34:20 -0000

=20
[Robert]
>If you want to know my preference .. I would prefer to drop the session
rather then to deal with peer which can not even >build the BGP Update
message properly.

Dropping session is bad and is really impacting the service, if we can
deal errors more smoothly it would be better ...


[Jakob & Bruno]
 >If an attribute appears more than once in an UPDATE message, then all
  > the occurrences of the attribute other than the first one SHALL be
   >discarded and the UPDATE message continue to be processed.

IMHO, as you mentioned Bruno, the behavior must be in relation with the
behavior when the attribute is bad.
We consider here that both attributes are valid (not malformed), so the
"treat-as-withdraw"/"attribute-discard" doesn't apply, the only applying
thing currently is the "Malformed attribute List" notification.

I see this as follows : if the duplicate (but valid) attribute is a
"treat-as-withdraw" attribute, the NLRIs must be withdrawn (otherwise
this could cause routing issues).  if the duplicate (but valid)
attribute is a "attribute-discard" attribute , I would agree on keeping
only one (first or last, it doesn't really matter as we are not able to
choose !), the important thing is then to inform the peer and operator
of what we done (see next lines ...).=20


[iLya]=20
>An alternative between these black and white behaviours could be to
throw away whole update but inform the neighbour=20
>that it has send nonsense, same time applying some penalty points.=20

I agree with the point to not go to a total opposite direction.
Moreover,it's not the case in the draft, as all attributes that are
impacting the routing must use "treat-as-withdraw" behavior.
About the way to inform neighbor about a potential bad update (because
some attributes are stripped), maybe we can use some mechanism like
"STALE" community proposed in BGP persistence draft to inform peer that
this path is maybe bad, so prefer another path if there s some other
available (it should be a policy based decision by the SP). And if there
is no path, this "STALE" path could be used.
Globally this marking approach could be used each time we are discarding
an attribute (duplicate case, or bad attribute with "attribute-discard"
behavior).


[Robert]
>You have received Update message with two MP_UNREACH attributes first
containing 5 NLRIs and the second 50 I don't think >it is safe to drop
the second MP_UNREACH and continue processing the message as usual.

A total out of scope suggestion/discussion, why  are we not able to put
multiple MP_UNREACH/MP_REACH_NLRI in a BGP message ? Today it's not
permitted by the BGP RFC, as these are BGP  attributes (easier to
implement than recoding a BGP per AFI/SAFI), so same behavior for all
attributes (one per type per update) but globally we are transporting
prefixes (and NH) only in these "attributes". So being able to transport
multiple occurence of MP_UNR/MP_R (one per AFI/SAFI), would permit a
better packing of BGP updates when for example a VRF with common
policies is using IPv4,IPv6,mVPN , multiple prefixes could be packed
with same attribute sequence. Easy to say, but maybe hard to implement.
There's topics about AFI/SAFI separations/fault isolation, and this
would go in an opposite direction ...

I just wanted to have some opinions on that (I was too young when BGP MP
extensions were defined :) ).





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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if th=
is message was modified, changed or falsified.
Thank you.


From jakob.heitz@ericsson.com  Tue Dec 27 03:01:10 2011
Return-Path: 
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 EC3C321F8442 for ; Tue, 27 Dec 2011 03:01:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_82=0.6, 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 dC2L2t0EIguK for ; Tue, 27 Dec 2011 03:01:10 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 33F1921F843E for ; Tue, 27 Dec 2011 03:01:10 -0800 (PST)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBRB17TR032033; Tue, 27 Dec 2011 05:01:08 -0600
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 27 Dec 2011 06:01:04 -0500
From: Jakob Heitz 
To: "stephane.litkowski@orange.com" , Ilya Varlashkin 
Date: Tue, 27 Dec 2011 06:01:00 -0500
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
Thread-Index: Acy8TD23qW+N7m1wQU6TMdcmHllaZgIMlPDgAAGYGPA=
Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A4781C1C7@EUSAACMS0701.eamcs.ericsson.se>
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com><37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com><4EEB6C23.4080803@raszuk.net><4EEB78E5.6070809@raszuk.net><20111216220720.GB10812@diehard.n-r-g.com>  <1701_1324982055_4EF99F27_1701_27016_1_4FC3556A36EE3646A09DAA60429F533507861570@PUEXCBL0.nanterre.francetelecom.fr>
In-Reply-To: <1701_1324982055_4EF99F27_1701_27016_1_4FC3556A36EE3646A09DAA60429F533507861570@PUEXCBL0.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Dec 2011 11:01:11 -0000

When a speaker sends a malformed attribute and the receiver
has to guess at the intention, SOMETHING WENT WRONG and
MUST BE FIXED.

We are here just trying to define how to limp along
instead of needlessly spreading damage.

It doesn't matter much whether we keep one or the other
or neither or withdraw.

Personally, I would treat a repeated attribute as a
malformation of that attribute: the receiver can only
guess at the intent and the problem needs to be fixed.
However, I'm agreeable to the current draft wording too.

--
Jakob Heitz.

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of steph=
ane.litkowski@orange.com
Sent: Tuesday, December 27, 2011 2:34 AM
To: Ilya Varlashkin
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt

=20
[Robert]
>If you want to know my preference .. I would prefer to drop the session
rather then to deal with peer which can not even >build the BGP Update
message properly.

Dropping session is bad and is really impacting the service, if we can
deal errors more smoothly it would be better ...


[Jakob & Bruno]
 >If an attribute appears more than once in an UPDATE message, then all
  > the occurrences of the attribute other than the first one SHALL be
   >discarded and the UPDATE message continue to be processed.

IMHO, as you mentioned Bruno, the behavior must be in relation with the
behavior when the attribute is bad.
We consider here that both attributes are valid (not malformed), so the
"treat-as-withdraw"/"attribute-discard" doesn't apply, the only applying
thing currently is the "Malformed attribute List" notification.

I see this as follows : if the duplicate (but valid) attribute is a
"treat-as-withdraw" attribute, the NLRIs must be withdrawn (otherwise
this could cause routing issues).  if the duplicate (but valid)
attribute is a "attribute-discard" attribute , I would agree on keeping
only one (first or last, it doesn't really matter as we are not able to
choose !), the important thing is then to inform the peer and operator
of what we done (see next lines ...).=20


[iLya]=20
>An alternative between these black and white behaviours could be to
throw away whole update but inform the neighbour=20
>that it has send nonsense, same time applying some penalty points.=20

I agree with the point to not go to a total opposite direction.
Moreover,it's not the case in the draft, as all attributes that are
impacting the routing must use "treat-as-withdraw" behavior.
About the way to inform neighbor about a potential bad update (because
some attributes are stripped), maybe we can use some mechanism like
"STALE" community proposed in BGP persistence draft to inform peer that
this path is maybe bad, so prefer another path if there s some other
available (it should be a policy based decision by the SP). And if there
is no path, this "STALE" path could be used.
Globally this marking approach could be used each time we are discarding
an attribute (duplicate case, or bad attribute with "attribute-discard"
behavior).


[Robert]
>You have received Update message with two MP_UNREACH attributes first
containing 5 NLRIs and the second 50 I don't think >it is safe to drop
the second MP_UNREACH and continue processing the message as usual.

A total out of scope suggestion/discussion, why  are we not able to put
multiple MP_UNREACH/MP_REACH_NLRI in a BGP message ? Today it's not
permitted by the BGP RFC, as these are BGP  attributes (easier to
implement than recoding a BGP per AFI/SAFI), so same behavior for all
attributes (one per type per update) but globally we are transporting
prefixes (and NH) only in these "attributes". So being able to transport
multiple occurence of MP_UNR/MP_R (one per AFI/SAFI), would permit a
better packing of BGP updates when for example a VRF with common
policies is using IPv4,IPv6,mVPN , multiple prefixes could be packed
with same attribute sequence. Easy to say, but maybe hard to implement.
There's topics about AFI/SAFI separations/fault isolation, and this
would go in an opposite direction ...

I just wanted to have some opinions on that (I was too young when BGP MP
extensions were defined :) ).





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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if th=
is message was modified, changed or falsified.
Thank you.

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

From stephane.litkowski@orange.com  Tue Dec 27 06:39:06 2011
Return-Path: 
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 5448B21F84FA for ; Tue, 27 Dec 2011 06:39:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.648
X-Spam-Level: 
X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=1.600,  BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
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 wKTb8GH5P+HD for ; Tue, 27 Dec 2011 06:39:05 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8346021F84F9 for ; Tue, 27 Dec 2011 06:39:05 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 26CC43B44FE; Tue, 27 Dec 2011 15:39:02 +0100 (CET)
Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 06BA54C017; Tue, 27 Dec 2011 15:39:02 +0100 (CET)
Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.46]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Dec 2011 15:39:00 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 27 Dec 2011 15:38:59 +0100
Message-ID: <30062_1324996742_4EF9D886_30062_31905_1_4FC3556A36EE3646A09DAA60429F53350786165C@PUEXCBL0.nanterre.francetelecom.fr>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
Thread-Index: Acy+hJIKYhhGe/dKTCiOWzuagA4rbAGH8Fpg
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com><37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com><4EEB6C23.4080803@raszuk.net><4EEB78E5.6070809@raszuk.net>	<20111216220720.GB10812@diehard.n-r-g.com><4EEBE42B.2020700@cisco.com><20111217103952.GA7158@diehard.n-r-g.com><26782_1324294649_4EEF21F9_26782_3157_1_53C29892C857584299CBF5D05346208A010D51@PEXCVZYM11.corporate.adroot.infra.ftgroup><4EEF4942.6050105@raszuk.net><22583_1324309396_4EEF5B94_22583_6701_1_53C29892C857584299CBF5D05346208A010EC8@PEXCVZYM11.corporate.adroot.infra.ftgroup><4EEF6192.1090901@raszuk.net> 
From: 
To: "Ilya Varlashkin" , 
X-OriginalArrivalTime: 27 Dec 2011 14:39:00.0115 (UTC) FILETIME=[4579A630:01CCC4A5]
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.27.134515
Cc: DECRAENE Bruno RD-CORE , idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Dec 2011 14:39:06 -0000

Hi,

Are we sure that DampPeerOscillations has been implemented in vendors code ?
We globally have many session flap , especially PE-CE (sometimes PE-RR), wi=
th high flapping rate leading to high CPU on nodes, and we were wondering i=
f the functionnality was implemented or not ...
Maybe vendors can answer ...
The values given in RFC 4271 seems to be only examples, if there is impleme=
ntation of DampPeerOscillations, the values may differs.

Thanks,

Stephane

-----Message d'origine-----
De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la part de Ilya =
Varlashkin
Envoy=E9 : lundi 19 d=E9cembre 2011 20:29
=C0 : robert@raszuk.net
Cc : DECRAENE Bruno RD-CORE; idr@ietf.org
Objet : Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt


On 19Dec 2011, at 17:08, Robert Raszuk wrote:

>> Would DampPeerOscillations (=A78.1.1. of RFC 4271) do the job or are=20
>> you thinking about something else?
>
> I am not sure if DampPeerOscillations kicks in due to error triggered=20
> sessions resets. It seems reading 4271 it is to catch session=20
> connect/session disconnect case. I think Ilya observed recently that=20
> it does not. But it is better that he comments here.
>

My experience was with an implementation sending malformed NLRI. As expecte=
d, this was causing session reset, flushing all the good routes as well, th=
en coming up and "marry go 'round". Although logic described for DampPeerOs=
cillations is similar to what could have remedied such behaviour, the actua=
l values specified in rfc4271 won't catch the exact problem that I've encou=
ntered. 4271 specifies 10 times within 5 minutes and max IdleHoldTime of on=
ly 2 minutes, whereas in my case getting getting all routes was taking 5-20=
 minutes.

The behaviour I've observed isn't unique to my network and not even to sing=
le vendor. Few months ago one could observe constant session flaps in many =
networks due to malformed attribute, then coming up again and on and on, an=
d DampPeerOscillations provided no significant protection.

Kind regards,
iLya

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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if th=
is message was modified, changed or falsified.
Thank you.


From cjeker@diehard.n-r-g.com  Tue Dec 27 06:41:24 2011
Return-Path: 
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 6591321F8510 for ; Tue, 27 Dec 2011 06:41:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Level: 
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
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 p4DFsoqj0oNB for ; Tue, 27 Dec 2011 06:41:23 -0800 (PST)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by ietfa.amsl.com (Postfix) with ESMTP id D521821F84FA for ; Tue, 27 Dec 2011 06:41:22 -0800 (PST)
Received: (qmail 3953 invoked by uid 1001); 27 Dec 2011 14:41:20 -0000
Date: Tue, 27 Dec 2011 15:41:20 +0100
From: Claudio Jeker 
To: bruno.decraene@orange.com
Message-ID: <20111227144120.GB5504@diehard.n-r-g.com>
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>  <4EEB78E5.6070809@raszuk.net> <20111216220720.GB10812@diehard.n-r-g.com> <4EEBE42B.2020700@cisco.com> <20111217103952.GA7158@diehard.n-r-g.com> <26782_1324294649_4EEF21F9_26782_3157_1_53C29892C857584299CBF5D05346208A010D51@PEXCVZYM11.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <26782_1324294649_4EEF21F9_26782_3157_1_53C29892C857584299CBF5D05346208A010D51@PEXCVZYM11.corporate.adroot.infra.ftgroup>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Dec 2011 14:41:24 -0000

On Mon, Dec 19, 2011 at 11:37:27AM +0000, bruno.decraene@orange.com wrote:
> As some of the recent comments are more on the requirement side, it may
> be useful to remind that there is a requirement draft on BGP error
> handling in the GROW WG:
> draft-ietf-grow-ops-reqs-for-bgp-error-handling-02 Might want to read
> and comment.
> More inline (a bit long)

Me too.
 
> >From: Claudio Jeker Sent: Saturday, December 17, 2011 11:40 AM
> >> Robert and Claudio,
> >>
> >> Resetting the session is undesirable as we can not recover from the
> >> situation without a new version of the software.
> >>
> >
> >I hope that the people writing that software are well aware of this and
> >that they fix the problem before it actually goes out into the wild.
> 
> I don't believe tests will ever be able to detect all bugs. So we need
> to be prepare to handle them.

No, they will not find all bugs but some of the obvious ones that
everybody suffered from. Maybe I'm to naive...

> >Do you trust the software that is unable to follow the very basic rules of
> >the RFC of not duplicating an attribute to be bug free in other regards?
> >You think it will not mangle the ASPATH in ways that will suddenly direct
> >all your traffic to that router where it is dropped or looped back to you?
> >
> >I understand that the error handling with optional transitive attributes
> >needs to be very careful and should not result in NOTIFICATIONS and
> >session drops. I do not understand that we try to keep direct neighbor
> >routers that act flaky (either because of dying HW or bad SW) up until the
> >situation is so bad that it may result in a much bigger issue.
> 
> I don't believe in the "so bad SW" argument:
> - Yes, something is bad, there is no way to figure it out in live, it
> would be safer to shut to not trust this router anymore and shut the BGP
> session. But to keep it safe, going that way, we should shut the BGP
> session forever, shut the IGP adjacencies if any (it's so bad I can't
> trust it/it's FIB any more), flood -at least in the AS- the OS version
> to warn all routers that that OS (HW) should not be trusted and that all
> routers should shut their BGP sessions with this bad SW... It may
> locally be seem as "safer", but this has consequences in term of network
> availability. Another valid path, the "cautious path" is to try to limit
> the consequences of the error (as defined in
> draft-ietf-idr-error-handling). Frankly, between the "safe path" and the
> "cautious path" the latter also seems a very reasonable option (and
> definitely the safer in term of security / DOS consideration). Yes,
> sometimes it will result in a bad decision with a bad neighbor still
> being used. But let's try this new path because we have tried the first
> one and we don't like it.

Actually that was tried already long time ago and resulted in nice
meltdowns. Yes, throwing a NOTIFICATION and closing the session is often
too extrem but it is not OK to ever accept and maybe propagate a possible
faulty attribute. Which is exactly the case when a router sends an
attribute twice.

> - we should also remember that we are mostly talking about events on
> routers from majors companies doing significant effort to carefully
> implement and test it, with SP doing furthers tests and then OS/routers
> running for months without any issue. Seems strange to suddenly assume
> they are bad and should not been talked to anymore.

So if they are tested so carefully why has the problem not been found
already?
Since the problem was not found until now how can you assume that because
the system was fine for a few month it will still be fine? You don't know
the cause of the problem, it may be harmless or it may be something that
will take the network down.
 
> I agree that optional transitive attributes are the most most likely to
> cause issues. However I would prefer that no single BGP update cause the
> BGP session to be shut down. Including well known mandatory attributes. 
> e.g. let's take the AS_PATH, probably the most well known mandatory one.
> If I were the first AS to deploy draft-ietf-idr-as0, if one remote AS
> advertise an update with AS 0 in the AS_PATH, If I don't treat that
> error as withdraw (but as notification) I would end up tearing down all
> my BGP sessions (nominal, and _all_ backup ones) toward that NRLI and
> all the NLRI advertised over those sessions. That could be lots of NLRI
> (>50%), with no backup path, and forever until someone find the issue
> and the solution.
>

This is a bad example. You deploy something that extends the error
handling and makes the interpretation of messages more strict. Sure you
may end up in that situation, it was your decision to deploy it.
I guess a more valid point would be the handling of more then 255 elements
in an AS PATH (which caused some issues some time ago). In in that case
treating that UPDATE as a withdraw is probably the better option than
shutting down the session.
 
> >Yes, the connection between the two neighbors in question will be down,
> >there will be no traffic exchanged over it (but we have a dynamic routing
> >protocol here and maybe it is able to find an alternate route to that site
> >that is not disrupted). 
> 
> You are assuming a local error with your neighbor. Chances are that
> errors have been trigger by a specific state and that all backup paths
> also got that state. Hence you can't assume that there would be a backup
> path if you choose to shut down the session.

I was talking about duplicate attributes in an UPDATE message. I wonder
how that can propagate beyond the two systems. I guess we need to assume
that an external event caused this bug and yes it could affact other
systems to. But why does the system that found the error propagate a
possible faulty attribute? What assumtion tells us that the first
attribute was the correct one? Why not the last? We're guessing here and
that is bad for an error-handling RFC. IMO the correct behaviour would be
"attribute discard" or "treat-as-withdraw" depending on the attribute.

 
> However, to better take your valid case (a single bad neighbor) into
> account one could:
> - keep the BGP session up (as per draft-ietf-idr-error-handling-01)
> - in addition, flag all routes received (and not treated as withdraw)
> over that session with an IANA community. Then SP would be free to lower
> the LOCAL_PREF (or cost community) of those routes so that others
> routers in the AS would prefer another path if another good path were
> available.

Nice idea.

> 
> That would probably better cover both cases (single bad neighbor, global
> issue with all BGP session affected), at the cost of creating BGP churn
> at probably a bad moment (but just like the existing RFC 4271 does).


-- 
:wq Claudio

From cjeker@diehard.n-r-g.com  Tue Dec 27 06:49:14 2011
Return-Path: 
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 83A3521F84DF for ; Tue, 27 Dec 2011 06:49:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.67
X-Spam-Level: 
X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930,  BAYES_00=-2.599]
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 Txns9s6TsO3S for ; Tue, 27 Dec 2011 06:49:14 -0800 (PST)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by ietfa.amsl.com (Postfix) with ESMTP id AB23B21F84DD for ; Tue, 27 Dec 2011 06:49:13 -0800 (PST)
Received: (qmail 7905 invoked by uid 1001); 27 Dec 2011 14:49:12 -0000
Date: Tue, 27 Dec 2011 15:49:12 +0100
From: Claudio Jeker 
To: Jakob Heitz 
Message-ID: <20111227144912.GC5504@diehard.n-r-g.com>
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net>  <4EEB78E5.6070809@raszuk.net> <20111216220720.GB10812@diehard.n-r-g.com>  <1701_1324982055_4EF99F27_1701_27016_1_4FC3556A36EE3646A09DAA60429F533507861570@PUEXCBL0.nanterre.francetelecom.fr> <7309FCBCAE981B43ABBE69B31C8D21391A4781C1C7@EUSAACMS0701.eamcs.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A4781C1C7@EUSAACMS0701.eamcs.ericsson.se>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "idr@ietf.org" 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Dec 2011 14:49:14 -0000

On Tue, Dec 27, 2011 at 06:01:00AM -0500, Jakob Heitz wrote:
> When a speaker sends a malformed attribute and the receiver
> has to guess at the intention, SOMETHING WENT WRONG and
> MUST BE FIXED.
> 
> We are here just trying to define how to limp along
> instead of needlessly spreading damage.
> 
> It doesn't matter much whether we keep one or the other
> or neither or withdraw.
> 
> Personally, I would treat a repeated attribute as a
> malformation of that attribute: the receiver can only
> guess at the intent and the problem needs to be fixed.
> However, I'm agreeable to the current draft wording too.
> 

I can agree with most of draft-ietf-idr-error-handling-01
but this is one point I can't agree. I'm more on your line here. Repeated
attributes are a malformation and the receiver should never guess about
the intent esp. when handling errors. If in doubt ignore all instead of
possibly distributing the wrong attribute.

-- 
:wq Claudio

From stephane.litkowski@orange.com  Tue Dec 27 06:52:31 2011
Return-Path: 
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 0E26221F849C for ; Tue, 27 Dec 2011 06:52:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.448
X-Spam-Level: 
X-Spam-Status: No, score=-1.448 tagged_above=-999 required=5 tests=[AWL=0.800,  BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
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 obZzWMQb3vwa for ; Tue, 27 Dec 2011 06:52:30 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3770021F8495 for ; Tue, 27 Dec 2011 06:52:30 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 7E9EE264182; Tue, 27 Dec 2011 15:52:29 +0100 (CET)
Received: from puexcc41.nanterre.francetelecom.fr (unknown [10.168.74.60]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 5DD6B27C037; Tue, 27 Dec 2011 15:52:29 +0100 (CET)
Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.46]) by puexcc41.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Dec 2011 15:52:29 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 27 Dec 2011 15:52:27 +0100
Message-ID: <29770_1324997549_4EF9DBAD_29770_218328_1_4FC3556A36EE3646A09DAA60429F533507861664@PUEXCBL0.nanterre.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
Thread-Index: Acy+hJIKYhhGe/dKTCiOWzuagA4rbAGH8FpgAACWr8A=
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com><37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com><4EEB6C23.4080803@raszuk.net><4EEB78E5.6070809@raszuk.net>	<20111216220720.GB10812@diehard.n-r-g.com><4EEBE42B.2020700@cisco.com><20111217103952.GA7158@diehard.n-r-g.com><26782_1324294649_4EEF21F9_26782_3157_1_53C29892C857584299CBF5D05346208A010D51@PEXCVZYM11.corporate.adroot.infra.ftgroup><4EEF4942.6050105@raszuk.net><22583_1324309396_4EEF5B94_22583_6701_1_53C29892C857584299CBF5D05346208A010EC8@PEXCVZYM11.corporate.adroot.infra.ftgroup><4EEF6192.1090901@raszuk.net>  
From: 
To: "LITKOWSKI Stephane DTF/DERX" , "Ilya Varlashkin" , 
X-OriginalArrivalTime: 27 Dec 2011 14:52:29.0308 (UTC) FILETIME=[27CAB3C0:01CCC4A7]
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.27.142415
Cc: DECRAENE Bruno RD-CORE , idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Dec 2011 14:52:31 -0000

Hmmm ... Here are some findings from RFC 4276 :

3.28.156.  Event6: AutomaticStart_with_DampPeerOscillations

       Functionality/Description: The AllowAutomaticStart attribute
       SHOULD be set to TRUE

       RFC2119: SHOULD

       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: O    Don't support DampPeerOscillations
                                    attribute.
       Laurel  Y/N/O/Comments: Y

       NextHop Y/N/O/Comments: Y



Alcatel/Cisco were not supporting DampPeerOscillations when the survey was =
done. Maybe it changed, maybe not (RFC is old ...).
No feedback about Juniper.
=20

-----Message d'origine-----
De : LITKOWSKI Stephane DTF/DERX=20
Envoy=E9 : mardi 27 d=E9cembre 2011 15:39
=C0 : 'Ilya Varlashkin'; robert@raszuk.net
Cc : DECRAENE Bruno RD-CORE; idr@ietf.org
Objet : RE: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt

Hi,

Are we sure that DampPeerOscillations has been implemented in vendors code ?
We globally have many session flap , especially PE-CE (sometimes PE-RR), wi=
th high flapping rate leading to high CPU on nodes, and we were wondering i=
f the functionnality was implemented or not ...
Maybe vendors can answer ...
The values given in RFC 4271 seems to be only examples, if there is impleme=
ntation of DampPeerOscillations, the values may differs.

Thanks,

Stephane

-----Message d'origine-----
De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la part de Ilya =
Varlashkin Envoy=E9 : lundi 19 d=E9cembre 2011 20:29 =C0 : robert@raszuk.ne=
t Cc : DECRAENE Bruno RD-CORE; idr@ietf.org Objet : Re: [Idr] I-D Action: d=
raft-ietf-idr-error-handling-01.txt


On 19Dec 2011, at 17:08, Robert Raszuk wrote:

>> Would DampPeerOscillations (=A78.1.1. of RFC 4271) do the job or are=20
>> you thinking about something else?
>
> I am not sure if DampPeerOscillations kicks in due to error triggered=20
> sessions resets. It seems reading 4271 it is to catch session=20
> connect/session disconnect case. I think Ilya observed recently that=20
> it does not. But it is better that he comments here.
>

My experience was with an implementation sending malformed NLRI. As expecte=
d, this was causing session reset, flushing all the good routes as well, th=
en coming up and "marry go 'round". Although logic described for DampPeerOs=
cillations is similar to what could have remedied such behaviour, the actua=
l values specified in rfc4271 won't catch the exact problem that I've encou=
ntered. 4271 specifies 10 times within 5 minutes and max IdleHoldTime of on=
ly 2 minutes, whereas in my case getting getting all routes was taking 5-20=
 minutes.

The behaviour I've observed isn't unique to my network and not even to sing=
le vendor. Few months ago one could observe constant session flaps in many =
networks due to malformed attribute, then coming up again and on and on, an=
d DampPeerOscillations provided no significant protection.

Kind regards,
iLya

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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if th=
is message was modified, changed or falsified.
Thank you.


From stephane.litkowski@orange.com  Thu Dec 29 00:12:57 2011
Return-Path: 
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 8650D11E808C for ; Thu, 29 Dec 2011 00:12:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.415
X-Spam-Level: 
X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[AWL=0.233,  BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_82=0.6, UNPARSEABLE_RELAY=0.001]
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 C5OrIgyyUAFA for ; Thu, 29 Dec 2011 00:12:56 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCA021F844A for ; Thu, 29 Dec 2011 00:12:53 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 478AA2DC497; Thu, 29 Dec 2011 09:12:50 +0100 (CET)
Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 2BB23238059; Thu, 29 Dec 2011 09:12:50 +0100 (CET)
Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.46]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Dec 2011 09:12:50 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 29 Dec 2011 09:12:49 +0100
Message-ID: <30916_1325146370_4EFC2102_30916_56577_1_4FC3556A36EE3646A09DAA60429F5335078619C8@PUEXCBL0.nanterre.francetelecom.fr>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A4781C1C7@EUSAACMS0701.eamcs.ericsson.se>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
Thread-Index: Acy8TD23qW+N7m1wQU6TMdcmHllaZgIMlPDgAAGYGPAAXsMUIA==
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com><37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com><4EEB6C23.4080803@raszuk.net><4EEB78E5.6070809@raszuk.net><20111216220720.GB10812@diehard.n-r-g.com> <1701_1324982055_4EF99F27_1701_27016_1_4FC3556A36EE3646A09DAA60429F533507861570@PUEXCBL0.nanterre.francetelecom.fr> <7309FCBCAE981B43ABBE69B31C8D21391A4781C1C7@EUSAACMS0701.eamcs.ericsson.se>
From: 
To: "Jakob Heitz" , "Ilya Varlashkin" 
X-OriginalArrivalTime: 29 Dec 2011 08:12:50.0252 (UTC) FILETIME=[A7FCA0C0:01CCC601]
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.29.73315
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Dec 2011 08:12:57 -0000

Hi Jakob,


>When a speaker sends a malformed attribute and the receiver has to guess a=
t the intention, SOMETHING WENT WRONG and MUST BE FIXED.
>We are here just trying to define how to limp along instead of needlessly =
spreading damage.

Totally agree !

But ot sure to understand your meaning, when you said :

"I would treat a repeated attribute as a malformation of that attribute"
So basically, with the current proposed behavior in the draft, it means tha=
t the NLRIs are withdraw if attribute is "treat-as-withdraw", or attributes=
 (all occurences) are discarded if attribute is "attribute-discard" type.=
=20


But you say that you agree with the current wording which say that we keep/=
process the first occurrence of the attribute. So there is a contradiction =
here, maybe I misunderstood something ... Please clarify.

I totally agree on "the receiver can only guess at the intent and the probl=
em needs to be fixed.", so if we decide to keep one attribute in some cases=
, the receiver must be informed that there s something wrong with the path =
(the way to inform need to be defined -> see my proposal to reuse STALE com=
munity).

Regards

Stephane


-----Message d'origine-----
De : Jakob Heitz [mailto:jakob.heitz@ericsson.com]=20
Envoy=E9 : mardi 27 d=E9cembre 2011 12:01
=C0 : LITKOWSKI Stephane DTF/DERX; Ilya Varlashkin
Cc : idr@ietf.org
Objet : RE: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt

When a speaker sends a malformed attribute and the receiver has to guess at=
 the intention, SOMETHING WENT WRONG and MUST BE FIXED.

We are here just trying to define how to limp along instead of needlessly s=
preading damage.

It doesn't matter much whether we keep one or the other or neither or withd=
raw.

Personally, I would treat a repeated attribute as a malformation of that at=
tribute: the receiver can only guess at the intent and the problem needs to=
 be fixed.
However, I'm agreeable to the current draft wording too.

--
Jakob Heitz.

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of steph=
ane.litkowski@orange.com
Sent: Tuesday, December 27, 2011 2:34 AM
To: Ilya Varlashkin
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt

=20
[Robert]
>If you want to know my preference .. I would prefer to drop the session
rather then to deal with peer which can not even >build the BGP Update mess=
age properly.

Dropping session is bad and is really impacting the service, if we can deal=
 errors more smoothly it would be better ...


[Jakob & Bruno]
 >If an attribute appears more than once in an UPDATE message, then all
  > the occurrences of the attribute other than the first one SHALL be
   >discarded and the UPDATE message continue to be processed.

IMHO, as you mentioned Bruno, the behavior must be in relation with the beh=
avior when the attribute is bad.
We consider here that both attributes are valid (not malformed), so the "tr=
eat-as-withdraw"/"attribute-discard" doesn't apply, the only applying thing=
 currently is the "Malformed attribute List" notification.

I see this as follows : if the duplicate (but valid) attribute is a "treat-=
as-withdraw" attribute, the NLRIs must be withdrawn (otherwise this could c=
ause routing issues).  if the duplicate (but valid) attribute is a "attribu=
te-discard" attribute , I would agree on keeping only one (first or last, i=
t doesn't really matter as we are not able to choose !), the important thin=
g is then to inform the peer and operator of what we done (see next lines .=
..).=20


[iLya]=20
>An alternative between these black and white behaviours could be to
throw away whole update but inform the neighbour=20
>that it has send nonsense, same time applying some penalty points.=20

I agree with the point to not go to a total opposite direction.
Moreover,it's not the case in the draft, as all attributes that are impacti=
ng the routing must use "treat-as-withdraw" behavior.
About the way to inform neighbor about a potential bad update (because some=
 attributes are stripped), maybe we can use some mechanism like "STALE" com=
munity proposed in BGP persistence draft to inform peer that this path is m=
aybe bad, so prefer another path if there s some other available (it should=
 be a policy based decision by the SP). And if there is no path, this "STAL=
E" path could be used.
Globally this marking approach could be used each time we are discarding an=
 attribute (duplicate case, or bad attribute with "attribute-discard"
behavior).


[Robert]
>You have received Update message with two MP_UNREACH attributes first
containing 5 NLRIs and the second 50 I don't think >it is safe to drop the =
second MP_UNREACH and continue processing the message as usual.

A total out of scope suggestion/discussion, why  are we not able to put mul=
tiple MP_UNREACH/MP_REACH_NLRI in a BGP message ? Today it's not permitted =
by the BGP RFC, as these are BGP  attributes (easier to implement than reco=
ding a BGP per AFI/SAFI), so same behavior for all attributes (one per type=
 per update) but globally we are transporting prefixes (and NH) only in the=
se "attributes". So being able to transport multiple occurence of MP_UNR/MP=
_R (one per AFI/SAFI), would permit a better packing of BGP updates when fo=
r example a VRF with common policies is using IPv4,IPv6,mVPN , multiple pre=
fixes could be packed with same attribute sequence. Easy to say, but maybe =
hard to implement.
There's topics about AFI/SAFI separations/fault isolation, and this would g=
o in an opposite direction ...

I just wanted to have some opinions on that (I was too young when BGP MP ex=
tensions were defined :) ).





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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou =
copies sans autorisation. Si vous avez recu ce message par erreur, veuillez=
 le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le=
s messages electroniques etant susceptibles d'alteration, France Telecom - =
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law; they should not be distributed, used=
 or copied without authorization.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if th=
is message was modified, changed or falsified.
Thank you.

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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if th=
is message was modified, changed or falsified.
Thank you.


From stephane.litkowski@orange.com  Thu Dec 29 00:41:53 2011
Return-Path: 
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 6177421F8513 for ; Thu, 29 Dec 2011 00:41:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.773
X-Spam-Level: 
X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=0.475,  BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
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 df5qT0H-0z0k for ; Thu, 29 Dec 2011 00:41:52 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD4721F8509 for ; Thu, 29 Dec 2011 00:41:52 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 0BA7918C705 for ; Thu, 29 Dec 2011 09:41:50 +0100 (CET)
Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id DB66D27C037 for ; Thu, 29 Dec 2011 09:41:49 +0100 (CET)
Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.46]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Dec 2011 09:41:50 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 29 Dec 2011 09:41:48 +0100
Message-ID: <1262_1325148109_4EFC27CD_1262_46384_3_4FC3556A36EE3646A09DAA60429F5335078619F2@PUEXCBL0.nanterre.francetelecom.fr>
In-Reply-To: <30916_1325146370_4EFC2102_30916_56577_1_4FC3556A36EE3646A09DAA60429F5335078619C8@PUEXCBL0.nanterre.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
Thread-Index: Acy8TD23qW+N7m1wQU6TMdcmHllaZgIMlPDgAAGYGPAAXsMUIAAA0RSA
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com><37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com><4EEB6C23.4080803@raszuk.net><4EEB78E5.6070809@raszuk.net><20111216220720.GB10812@diehard.n-r-g.com><1701_1324982055_4EF99F27_1701_27016_1_4FC3556A36EE3646A09DAA60429F533507861570@PUEXCBL0.nanterre.francetelecom.fr><7309FCBCAE981B43ABBE69B31C8D21391A4781C1C7@EUSAACMS0701.eamcs.ericsson.se> <30916_1325146370_4EFC2102_30916_56577_1_4FC3556A36EE3646A09DAA60429F5335078619C8@PUEXCBL0.nanterre.francetelecom.fr>
From: 
To: 
X-OriginalArrivalTime: 29 Dec 2011 08:41:50.0019 (UTC) FILETIME=[B4F80130:01CCC605]
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.29.73315
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Dec 2011 08:41:53 -0000

=20
Hi Authors,


In the draft, there is a work started about describing expected behavior
for some attribute : Aggregator, Community, Extcommunity.

How to you want to proceed for all other existing attributes ? And for
futures (the draft has a precision for futures) ?=20
Potential solutions :
- make this document as a reference for all attributes (so document is
appended each time a new attribute is defined -> it's not what has been
agreed today)
- make this document as a reference for all already existing attributes
and for futures, the behavior will be described in the associated
draft/RFC
- update all existing draft/RFCs with attribute definition to reflect
the behavior (treat-as-withdraw or attribute-discard).

Currently the document says : "A document which specifies a new
attribute MUST provide specifics
   regarding what constitutes an error for that attribute and how that
   error is to be handled."

So we must deal with all old ones...

IMHO, we should not leave any ambiguity on per attribute behavior. If
only a generic rule is defined as it's done in the draft, vendors may
have a different view about Routing impact of attributes and we will be
exposed to different behavior per vendor and so potential routing issues
...

Current generic rule :"  When a path attribute in an UPDATE message is
determined to be
   malformed, the UPDATE message containing that attribute MUST be
   treated as though all contained routes had been withdrawn just as if
   they had been listed in the WITHDRAWN ROUTES field (or in the
   MP_UNREACH_NLRI attribute [RFC4760bis] if appropriate) of the UPDATE
   message, thus causing them to be removed from the Adj-RIB-In
   according to the procedures of [RFC4271].  In the case of an
   attribute which has no effect on route selection or installation, the
   malformed attribute MAY instead be discarded and the UPDATE message
   continue to be processed.  For the sake of brevity, the former
   approach is termed "treat-as-withdraw", and the latter as "attribute
   discard"."


I would prefer to describe behavior for all existing attributes to
suppress any ambiguity, especially for attributes like Cluster List,
Originator ID ... (I hope a treat as withdraw behavior to prevent
routing loops). Then all others : ATTR_SET, PMSI Tunnel, IPv6 EXT CT ...
The job is not huge, attribute list is not too long.


Thanks to clarify,


Stephane


___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if th=
is message was modified, changed or falsified.
Thank you.