From adam.simpson@alcatel-lucent.com Thu Mar 1 12:55:27 2012 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 047DB21E8085 for ; Thu, 1 Mar 2012 12:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 HERPsRNBhjNY for ; Thu, 1 Mar 2012 12:55:25 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A00D121E8021 for ; Thu, 1 Mar 2012 12:55:21 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q21KtK2j019112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 1 Mar 2012 14:55:21 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q21KtK4N001360 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 1 Mar 2012 14:55:20 -0600 Received: from USNAVSXCHMBSC1.ndc.alcatel-lucent.com ([135.3.39.146]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 1 Mar 2012 14:55:20 -0600 From: "Simpson, Adam (Adam)" To: "idr@ietf.org" Date: Thu, 1 Mar 2012 14:55:19 -0600 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt Thread-Index: Acy7grKLhpwJfMWdRZWQG1puvl4pqQ8ZvkRQ Message-ID: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 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, 01 Mar 2012 20:55:27 -0000 Authors, Thank you for your work on this. One topic that I would like see discussed more thoroughly in a next version= of the draft is how attribute-length errors should be handled and whether = it's even appropriate for these types of errors to fall under the scope of = the treat-as-withdrawn or attribute-discard approaches. In section 5 of the current draft you give examples of a malformed communit= y attribute as one with a length that is not a multiple of 4 bytes and a ma= lformed aggregator attribute as one with a length that is not 6 or 8 bytes.= The trouble I have with treating these types of errors using treat-as-with= drawn or attribute-discard is that you are forcing the receiver of a malfor= med Update message to guess what the sender actually encoded. If an aggrega= tor attribute with a reported length of 7 bytes is received did the sender = encode 6 bytes and incorrectly put 7 in the length field or did they put an= extra byte of garbage in the attribute? Fundamentally, I think it would be better to restrict treat-as-withdraw and= attribute-discard to cases where the length of an attribute is not in ques= tion. If you disagree then I think you must add text to the draft that desc= ribes what an implementation should assume when it sees a length error such= as the example discussed above - e.g. should it assume the "closest" valid= value? There is probably a small chance of making a wrong "guess" that act= ually results in successful parsing of the message but if that chance is at= all greater than 0 it seems we are taking treat-as-wthdrawn a step too far= . Adam > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Thursday, December 15, 2011 6:39 PM > To: i-d-announce@ietf.org > Cc: idr@ietf.org > Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt >=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 : 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 From enkechen@cisco.com Thu Mar 1 13:51:07 2012 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 8FEB421E81B4 for ; Thu, 1 Mar 2012 13:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 GC86F3QZdJXi for ; Thu, 1 Mar 2012 13:51:06 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4DB21E819C for ; Thu, 1 Mar 2012 13:51:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=3972; q=dns/txt; s=iport; t=1330638666; x=1331848266; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Rm+tmjRDN0xvK3XxGZ8tAbDMsPUp5GuOZYmIraStRyQ=; b=hfhU2o8zdvjyt7ddR2m3jVvAC+H7QXRW/PtKLc5Sx8r519W4d0EBD8T/ FsDH+ObWG/F/q8hec/bIEpABBF8559BCLNkfikyyNsk7CLUE27ZMPh5g3 XjmJocqtkliXneK2DKcHfIWjBTPpt7/QY7GlzOIgKxT24U66sTRvBQRSz 0=; X-IronPort-AV: E=Sophos;i="4.73,513,1325462400"; d="scan'208";a="31429570" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 01 Mar 2012 21:51:05 +0000 Received: from dhcp-171-71-139-175.cisco.com (dhcp-171-71-139-175.cisco.com [171.71.139.175]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q21Lp5gf013695; Thu, 1 Mar 2012 21:51:05 GMT Message-ID: <4F4FF078.8050106@cisco.com> Date: Thu, 01 Mar 2012 13:56:08 -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> In-Reply-To: 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: Thu, 01 Mar 2012 21:51:07 -0000 Hi, Adam: Not sure if we need extra text. The receiver must use the attribute length encoded in the message to continue parsing the message. -- Enke On 3/1/12 12:55 PM, Simpson, Adam (Adam) wrote: > Authors, > > Thank you for your work on this. > > One topic that I would like see discussed more thoroughly in a next version of the draft is how attribute-length errors should be handled and whether it's even appropriate for these types of errors to fall under the scope of the treat-as-withdrawn or attribute-discard approaches. > > In section 5 of the current draft you give examples of a malformed community attribute as one with a length that is not a multiple of 4 bytes and a malformed aggregator attribute as one with a length that is not 6 or 8 bytes. The trouble I have with treating these types of errors using treat-as-withdrawn or attribute-discard is that you are forcing the receiver of a malformed Update message to guess what the sender actually encoded. If an aggregator attribute with a reported length of 7 bytes is received did the sender encode 6 bytes and incorrectly put 7 in the length field or did they put an extra byte of garbage in the attribute? > > Fundamentally, I think it would be better to restrict treat-as-withdraw and attribute-discard to cases where the length of an attribute is not in question. If you disagree then I think you must add text to the draft that describes what an implementation should assume when it sees a length error such as the example discussed above - e.g. should it assume the "closest" valid value? There is probably a small chance of making a wrong "guess" that actually results in successful parsing of the message but if that chance is at all greater than 0 it seems we are taking treat-as-wthdrawn a step too far. > > Adam > >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Thursday, December 15, 2011 6:39 PM >> To: i-d-announce@ietf.org >> Cc: idr@ietf.org >> Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-01.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 : 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 From robert@raszuk.net Thu Mar 1 21:33:27 2012 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 E2D8D21F89B9 for ; Thu, 1 Mar 2012 21:33:26 -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 KmfklepJb6h2 for ; Thu, 1 Mar 2012 21:33:26 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 17B9D21F89BF for ; Thu, 1 Mar 2012 21:33:25 -0800 (PST) Received: (qmail 4858 invoked by uid 399); 2 Mar 2012 05:33:23 -0000 Received: from unknown (HELO ?184.48.56.228?) (pbs:robert@raszuk.net@12.217.162.34) by mail1310.opentransfer.com with ESMTPM; 2 Mar 2012 05:33:23 -0000 X-Originating-IP: 12.217.162.34 Message-ID: <4F505BA5.5070707@raszuk.net> Date: Fri, 02 Mar 2012 06:33:25 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Simpson, Adam (Adam)" References: <20111215233845.21432.33837.idtracker@ietfa.amsl.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, 02 Mar 2012 05:33:27 -0000 Hi Adam, > The trouble I have with treating these types of errors using > treat-as-withdrawn or attribute-discard is that you are forcing the > receiver of a malformed Update message to guess what the sender > actually encoded Invalid length of the attribute is a fatal error as Enke said you just can't parse the message further and you either treat-as-withdraw (if MP_(UN)REACH_NLRI attributes were at the beginning) and you know what prefixes were sent/withdrawn in this update message or you drop the session. That's pretty much two alternatives you have. Can you explain where any "guessing" would be taking place ? Thx, R. > Authors, > > Thank you for your work on this. > > One topic that I would like see discussed more thoroughly in a next > version of the draft is how attribute-length errors should be > handled and whether it's even appropriate for these types of errors > to fall under the scope of the treat-as-withdrawn or > attribute-discard approaches. > > In section 5 of the current draft you give examples of a malformed > community attribute as one with a length that is not a multiple of 4 > bytes and a malformed aggregator attribute as one with a length that > is not 6 or 8 bytes. The trouble I have with treating these types of > errors using treat-as-withdrawn or attribute-discard is that you are > forcing the receiver of a malformed Update message to guess what the > sender actually encoded. If an aggregator attribute with a reported > length of 7 bytes is received did the sender encode 6 bytes and > incorrectly put 7 in the length field or did they put an extra byte > of garbage in the attribute? > > Fundamentally, I think it would be better to restrict > treat-as-withdraw and attribute-discard to cases where the length of > an attribute is not in question. If you disagree then I think you > must add text to the draft that describes what an implementation > should assume when it sees a length error such as the example > discussed above - e.g. should it assume the "closest" valid value? > There is probably a small chance of making a wrong "guess" that > actually results in successful parsing of the message but if that > chance is at all greater than 0 it seems we are taking > treat-as-wthdrawn a step too far. > > Adam > >> -----Original Message----- From: idr-bounces@ietf.org >> [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >> Sent: Thursday, December 15, 2011 6:39 PM To: i-d-announce@ietf.org >> Cc: idr@ietf.org Subject: [Idr] I-D Action: >> draft-ietf-idr-error-handling-01.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 : 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 > > From adam.simpson@alcatel-lucent.com Fri Mar 2 07:06:37 2012 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 B25B921F8657 for ; Fri, 2 Mar 2012 07:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.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 C4bwiI7PQCqy for ; Fri, 2 Mar 2012 07:06:37 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id DACC821F864A for ; Fri, 2 Mar 2012 07:06:36 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q22F6ZNT014539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Mar 2012 09:06:35 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q22F6Y55032262 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 09:06:35 -0600 Received: from USNAVSXCHMBSC1.ndc.alcatel-lucent.com ([135.3.39.146]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 2 Mar 2012 09:06:34 -0600 From: "Simpson, Adam (Adam)" To: "robert@raszuk.net" Date: Fri, 2 Mar 2012 09:06:31 -0600 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt Thread-Index: Acz4hg7NeFMq9ZGLS9OkeX4AjaLicQ== Message-ID: In-Reply-To: <4F505BA5.5070707@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 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, 02 Mar 2012 15:06:37 -0000 Thanks for your reply Robert. See inline. On 12-03-02 12:33 AM, "Robert Raszuk" wrote: >Hi Adam, > >> The trouble I have with treating these types of errors using >> treat-as-withdrawn or attribute-discard is that you are forcing the >> receiver of a malformed Update message to guess what the sender >> actually encoded > >Invalid length of the attribute is a fatal error as Enke said you just >can't parse the message further and you either treat-as-withdraw (if >MP_(UN)REACH_NLRI attributes were at the beginning) and you know what >prefixes were sent/withdrawn in this update message or you drop the >session. That's pretty much two alternatives you have. I agree these are the two options. Based on the current text in the draft you might also be led to believe that attribute discard is another option -- if the attribute with the length error does not influence path selection -- but that's clearly invalid in this type of error case. I am OK with treat-as-withdraw as an option but I think the processing rules need to be spelled out clearly - for example: 1. Apply treat as withdraw if the first attribute in the message is MP_REACH_NLRI and the message length, withdrawn routes length and total path attributes length indicate that there are no non-multiprotocol IPv4 NLRI at the end of the message. 2. Trust that the message length and total path attributes length were correct in order to skip to the end of the Update message. > >Can you explain where any "guessing" would be taking place ? If you look at the above rules both are based on the assumption that the overall message length and total path attributes length were correct even though one (or more) of the individual attribute lengths were "incorrect". I think in practice this will rarely pan out and the session will be dropped anyway. > >Thx, >R. > > >> Authors, >> >> Thank you for your work on this. >> >> One topic that I would like see discussed more thoroughly in a next >> version of the draft is how attribute-length errors should be >> handled and whether it's even appropriate for these types of errors >> to fall under the scope of the treat-as-withdrawn or >> attribute-discard approaches. >> >> In section 5 of the current draft you give examples of a malformed >> community attribute as one with a length that is not a multiple of 4 >> bytes and a malformed aggregator attribute as one with a length that >> is not 6 or 8 bytes. The trouble I have with treating these types of >> errors using treat-as-withdrawn or attribute-discard is that you are >> forcing the receiver of a malformed Update message to guess what the >> sender actually encoded. If an aggregator attribute with a reported >> length of 7 bytes is received did the sender encode 6 bytes and >> incorrectly put 7 in the length field or did they put an extra byte >> of garbage in the attribute? >> >> Fundamentally, I think it would be better to restrict >> treat-as-withdraw and attribute-discard to cases where the length of >> an attribute is not in question. If you disagree then I think you >> must add text to the draft that describes what an implementation >> should assume when it sees a length error such as the example >> discussed above - e.g. should it assume the "closest" valid value? >> There is probably a small chance of making a wrong "guess" that >> actually results in successful parsing of the message but if that >> chance is at all greater than 0 it seems we are taking >> treat-as-wthdrawn a step too far. >> >> Adam >> >>> -----Original Message----- From: idr-bounces@ietf.org >>> [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >>> Sent: Thursday, December 15, 2011 6:39 PM To: i-d-announce@ietf.org >>> Cc: idr@ietf.org Subject: [Idr] I-D Action: >>> draft-ietf-idr-error-handling-01.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 : 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 >> >> From Donald.Smith@CenturyLink.com Fri Mar 2 07:43:01 2012 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 CB6F621F863D for ; Fri, 2 Mar 2012 07:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=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 zSDbJGMHotJ2 for ; Fri, 2 Mar 2012 07:43:00 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6E321F8637 for ; Fri, 2 Mar 2012 07:42:59 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id q22FgqAR001447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Mar 2012 09:42:53 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id AEAD51E004D; Fri, 2 Mar 2012 08:42:47 -0700 (MST) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 940501E0035; Fri, 2 Mar 2012 08:42:47 -0700 (MST) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q22FglSk009765; Fri, 2 Mar 2012 08:42:47 -0700 (MST) Received: from qtdenexhtm20.AD.QINTRA.COM (qtdenexhtm20.ad.qintra.com [151.119.91.229]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q22Fgkle009761 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 2 Mar 2012 08:42:47 -0700 (MST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Fri, 2 Mar 2012 08:42:46 -0700 From: "Smith, Donald" To: "robert@raszuk.net" , "Simpson, Adam (Adam)" Content-Class: urn:content-classes:message Date: Fri, 2 Mar 2012 08:42:59 -0700 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt Thread-Index: Acz4NgNvtF4psnMQQJuBWgZNRhbZIwAVM+3QAAAUbPo= Message-ID: References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> , <4F505BA5.5070707@raszuk.net> In-Reply-To: <4F505BA5.5070707@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.3.105.0 Content-Type: multipart/alternative; boundary="_000_CF28F4930CB541B38614EC0069CCD926mimectl_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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, 02 Mar 2012 15:43:02 -0000 --_000_CF28F4930CB541B38614EC0069CCD926mimectl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable But if the length is invalid the packet is somehow malformed. How can you t= ake any action on a malformed packet or trust any of the data in said packe= t? I would vote for discard not dropping the session or taking any action on a= malformed packet. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: idr-bounces@ietf.org [idr-bounces@ietf.org] On Behalf Of Robert Raszu= k [robert@raszuk.net] Sent: Thursday, March 01, 2012 10:33 PM To: Simpson, Adam (Adam) Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt Hi Adam, > The trouble I have with treating these types of errors using > treat-as-withdrawn or attribute-discard is that you are forcing the > receiver of a malformed Update message to guess what the sender > actually encoded Invalid length of the attribute is a fatal error as Enke said you just can't parse the message further and you either treat-as-withdraw (if MP_(UN)REACH_NLRI attributes were at the beginning) and you know what prefixes were sent/withdrawn in this update message or you drop the session. That's pretty much two alternatives you have. Can you explain where any "guessing" would be taking place ? Thx, R. > Authors, > > Thank you for your work on this. > > One topic that I would like see discussed more thoroughly in a next > version of the draft is how attribute-length errors should be > handled and whether it's even appropriate for these types of errors > to fall under the scope of the treat-as-withdrawn or > attribute-discard approaches. > > In section 5 of the current draft you give examples of a malformed > community attribute as one with a length that is not a multiple of 4 > bytes and a malformed aggregator attribute as one with a length that > is not 6 or 8 bytes. The trouble I have with treating these types of > errors using treat-as-withdrawn or attribute-discard is that you are > forcing the receiver of a malformed Update message to guess what the > sender actually encoded. If an aggregator attribute with a reported > length of 7 bytes is received did the sender encode 6 bytes and > incorrectly put 7 in the length field or did they put an extra byte > of garbage in the attribute? > > Fundamentally, I think it would be better to restrict > treat-as-withdraw and attribute-discard to cases where the length of > an attribute is not in question. If you disagree then I think you > must add text to the draft that describes what an implementation > should assume when it sees a length error such as the example > discussed above - e.g. should it assume the "closest" valid value? > There is probably a small chance of making a wrong "guess" that > actually results in successful parsing of the message but if that > chance is at all greater than 0 it seems we are taking > treat-as-wthdrawn a step too far. > > Adam > >> -----Original Message----- From: idr-bounces@ietf.org >> [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >> Sent: Thursday, December 15, 2011 6:39 PM To: i-d-announce@ietf.org >> Cc: idr@ietf.org Subject: [Idr] I-D Action: >> draft-ietf-idr-error-handling-01.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 : 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 > > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ________________________________ This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. --_000_CF28F4930CB541B38614EC0069CCD926mimectl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
But if = the length is invalid the packet is somehow malformed. How can you take any= action on a malformed packet or trust any of the data in said packet?
 
I would vote for discard = not dropping the session or taking any action on a malformed packet.=
 
(coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Sm= ith@qwest.com
From: idr-bounces= @ietf.org [idr-bounces@ietf.org] On Behalf Of Robert Raszuk [robert@raszuk.= net]
Sent: Thursday, March 01, 2012 10:33 PM
To: Simpson, Adam (Adam)
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt<= br>
Hi Adam,

> The trouble I have with treating these types of errors using
> treat-as-withdrawn or attribute-discard is that you are forcing the > receiver of a malformed Update message to guess what the sender
> actually encoded

Invalid length of the attribute is a fatal error as Enke said you just
can't parse the message further and you either treat-as-withdraw (if
MP_(UN)REACH_NLRI attributes were at the beginning) and you know what
prefixes were sent/withdrawn in this update message or you drop the
session. That's pretty much two alternatives you have.

Can you explain where any "guessing" would be taking place ?

Thx,
R.


> Authors,
>
> Thank you for your work on this.
>
> One topic that I would like see discussed more thoroughly in a next > version of the draft is how attribute-length errors should be
> handled and whether it's even appropriate for these types of errors > to fall under the scope of the treat-as-withdrawn or
> attribute-discard approaches.
>
> In section 5 of the current draft you give examples of a malformed
> community attribute as one with a length that is not a multiple of 4 > bytes and a malformed aggregator attribute as one with a length that > is not 6 or 8 bytes. The trouble I have with treating these types of > errors using treat-as-withdrawn or attribute-discard is that you are > forcing the receiver of a malformed Update message to guess what the > sender actually encoded. If an aggregator attribute with a reported > length of 7 bytes is received did the sender encode 6 bytes and
> incorrectly put 7 in the length field or did they put an extra byte > of garbage in the attribute?
>
> Fundamentally, I think it would be better to restrict
> treat-as-withdraw and attribute-discard to cases where the length of > an attribute is not in question. If you disagree then I think you
> must add text to the draft that describes what an implementation
> should assume when it sees a length error such as the example
> discussed above - e.g. should it assume the "closest" valid = value?
> There is probably a small chance of making a wrong "guess" t= hat
> actually results in successful parsing of the message but if that
> chance is at all greater than 0 it seems we are taking
> treat-as-wthdrawn a step too far.
>
> Adam
>
>> -----Original Message----- From: idr-bounces@ietf.org
>> [mailto:= idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
>> Sent: Thursday, December 15, 2011 6:39 PM To: i-d-announce@ietf.or= g
>> Cc: idr@ietf.org Subject: [Idr] I-D Action:
>> draft-ietf-idr-error-handling-01.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts=
>>  directories. This draft is a work item of the Inter-Domain R= outing
>>  Working Group of the IETF.
>>
>> Title           = : Revised Error Handling for BGP UPDATE Messages
>> Author(s)       : John G. Scudder En= ke Chen Pradosh Mohapatra
>> Keyur Patel Filename        : d= raft-ietf-idr-error-handling-01.txt
>> Pages : 10 Date        &nb= sp;   : 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 als= o
>> 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<= br> >> 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
>
>

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

This communication is the pr= operty of CenturyLink and may contain confidential or privileged informatio= n. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy<= br> all copies of the communication and any attachments.
 --_000_CF28F4930CB541B38614EC0069CCD926mimectl_-- From tony.li@tony.li Fri Mar 2 08:05:51 2012 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 12BC221F8510 for ; Fri, 2 Mar 2012 08:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.333 X-Spam-Level: X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=0.266, 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 I6EV4aMJZe4A for ; Fri, 2 Mar 2012 08:05:49 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2F66C21F854E for ; Fri, 2 Mar 2012 08:05:47 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id geGs1i0031wpRvQ5Dg5npj; Fri, 02 Mar 2012 16:05:47 +0000 Received: from sjc-vpn5-492.cisco.com ([128.107.239.233]) by omta18.westchester.pa.mail.comcast.net with comcast id gg5X1i00w52qHCY3eg5aoF; Fri, 02 Mar 2012 16:05:45 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Tony Li In-Reply-To: Date: Fri, 2 Mar 2012 08:05:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1B586D1B-9A8F-41F0-A00D-E08EC4318398@tony.li> References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> , <4F505BA5.5070707@raszuk.net> To: "Smith, Donald" X-Mailer: Apple Mail (2.1257) Cc: "idr@ietf.org" , "robert@raszuk.net" 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, 02 Mar 2012 16:05:51 -0000 On Mar 2, 2012, at 7:42 AM, Smith, Donald wrote: > But if the length is invalid the packet is somehow malformed. How can = you take any action on a malformed packet or trust any of the data in = said packet? > =20 > I would vote for discard not dropping the session or taking any action = on a malformed packet. It's a message in a byte stream. If you no longer trust where the = message ended, where is the start of the next message? Tony From robert@raszuk.net Fri Mar 2 08:53:57 2012 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 BE70D21F8683 for ; Fri, 2 Mar 2012 08:53:57 -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 so56KLsDqq99 for ; Fri, 2 Mar 2012 08:53:57 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id E1BFD21F86C9 for ; Fri, 2 Mar 2012 08:53:56 -0800 (PST) Received: (qmail 31583 invoked by uid 399); 2 Mar 2012 16:53:55 -0000 Received: from unknown (HELO ?184.48.56.228?) (pbs:m42@mojaklasa.info@12.217.162.34) by mail1310.opentransfer.com with ESMTPM; 2 Mar 2012 16:53:55 -0000 X-Originating-IP: 12.217.162.34 Message-ID: <4F50FB26.6090602@raszuk.net> Date: Fri, 02 Mar 2012 17:53:58 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Smith, Donald" References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> , <4F505BA5.5070707@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, 02 Mar 2012 16:53:57 -0000 Hi Donald, > But if the length is invalid the packet is somehow malformed. How can > you take any action on a malformed packet or trust any of the data in > said packet? Just to clarify I am assuming UPDATE message length is ok, but some attribute(s) length within given message is bad. > I would vote for discard not dropping the session or taking any action > on a malformed packet. If UPDATE message length itself is wrong you drop session. How and what would you discard ? Thx, R. From Donald.Smith@CenturyLink.com Fri Mar 2 09:43:54 2012 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 8FBB921E803C for ; Fri, 2 Mar 2012 09:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HTML_MESSAGE=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 47Nzx9mDSFqg for ; Fri, 2 Mar 2012 09:43:53 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 2164F21E802D for ; Fri, 2 Mar 2012 09:43:53 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id q22HhoN3024388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Mar 2012 10:43:51 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 7D9EA1E004F; Fri, 2 Mar 2012 11:43:40 -0600 (CST) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 603D41E005B; Fri, 2 Mar 2012 11:43:40 -0600 (CST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id q22Hhdwb022513; Fri, 2 Mar 2012 11:43:40 -0600 (CST) Received: from qtdenexhtm22.AD.QINTRA.COM (qtdenexhtm22.ad.qintra.com [151.119.91.231]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id q22HhdQm022501 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 2 Mar 2012 11:43:39 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Fri, 2 Mar 2012 10:43:39 -0700 From: "Smith, Donald" To: "robert@raszuk.net" Content-Class: urn:content-classes:message Date: Fri, 2 Mar 2012 10:43:51 -0700 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt Thread-Index: Acz4lRSbWDI/3svxQ6iz12e4s+++zwABmwx8AAAhiEA= Message-ID: References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> , <4F505BA5.5070707@raszuk.net> , <4F50FB26.6090602@raszuk.net> In-Reply-To: <4F50FB26.6090602@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.3.105.0 Content-Type: multipart/alternative; boundary="_000_A83E2FE967C44E03B7DFB1BDA9F0BC36mimectl_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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, 02 Mar 2012 17:43:54 -0000 --_000_A83E2FE967C44E03B7DFB1BDA9F0BC36mimectl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That was my assumption too (packet length is correct but some attribute len= gth is incorrect). I would drop the packet but not the session assuming something along the wa= y mundged the packet somewhat. Now what could you do if ALL bgp update pack= ets from a peer were malformed? At some point you would have to treat it as= a bad peer and drop the session or something right? (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: Robert Raszuk [robert@raszuk.net] Sent: Friday, March 02, 2012 9:53 AM To: Smith, Donald Cc: Simpson, Adam (Adam); idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt Hi Donald, > But if the length is invalid the packet is somehow malformed. How can > you take any action on a malformed packet or trust any of the data in > said packet? Just to clarify I am assuming UPDATE message length is ok, but some attribute(s) length within given message is bad. > I would vote for discard not dropping the session or taking any action > on a malformed packet. If UPDATE message length itself is wrong you drop session. How and what would you discard ? Thx, R. ________________________________ This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. --_000_A83E2FE967C44E03B7DFB1BDA9F0BC36mimectl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
That wa= s my assumption too (packet length is correct but some attribute length is = incorrect).
I would drop the packet b= ut not the session assuming something along the way mundged the packet somewhat. Now what could you do if ALL bgp= update packets from a peer were malformed? At some point you would have to treat it as a bad peer and drop= the session or something right?
 
(coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Sm= ith@qwest.com
From: Robert Rasz= uk [robert@raszuk.net]
Sent: Friday, March 02, 2012 9:53 AM
To: Smith, Donald
Cc: Simpson, Adam (Adam); idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt<= br>
Hi Donald,

> But if the length is invalid the packet is somehow malformed. How can<= br> > you take any action on a malformed packet or trust any of the data in<= br> > said packet?

Just to clarify I am assuming UPDATE message length is ok, but some
attribute(s) length within given message is bad.

> I would vote for discard not dropping the session or taking any action=
> on a malformed packet.

If UPDATE message length itself is wrong you drop session. How and what would you discard ?

Thx,
R.

This communication is the pr= operty of CenturyLink and may contain confidential or privileged informatio= n. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy<= br> all copies of the communication and any attachments.
 --_000_A83E2FE967C44E03B7DFB1BDA9F0BC36mimectl_-- From Donald.Smith@CenturyLink.com Fri Mar 2 09:49:08 2012 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 86B2321F8648 for ; Fri, 2 Mar 2012 09:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HTML_MESSAGE=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 od1HsKpaB-z8 for ; Fri, 2 Mar 2012 09:49:07 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8232521F8613 for ; Fri, 2 Mar 2012 09:49:07 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id q22Hn5G1011253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Mar 2012 11:49:05 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 53ECE1E005D; Fri, 2 Mar 2012 11:49:00 -0600 (CST) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 37DD51E004F; Fri, 2 Mar 2012 11:49:00 -0600 (CST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id q22HmxWm000686; Fri, 2 Mar 2012 11:48:59 -0600 (CST) Received: from qtdenexhtm21.AD.QINTRA.COM (qtdenexhtm21.ad.qintra.com [151.119.91.230]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id q22Hmxwi000683 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 2 Mar 2012 11:48:59 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Fri, 2 Mar 2012 10:48:58 -0700 From: "Smith, Donald" To: Tony Li Content-Class: urn:content-classes:message Date: Fri, 2 Mar 2012 10:49:12 -0700 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt Thread-Index: Acz4jlXGZT2QgWZZTUm5mGQ2kyIYswADi/NYAAAQWK0= Message-ID: <2E52B916-689E-4BEC-B07A-5A8D4DFC9A3C@mimectl> References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> , <4F505BA5.5070707@raszuk.net> , <1B586D1B-9A8F-41F0-A00D-E08EC4318398@tony.li> In-Reply-To: <1B586D1B-9A8F-41F0-A00D-E08EC4318398@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.3.105.0 Content-Type: multipart/alternative; boundary="_000_2E52B916689E4BECB07A5A8D4DFC9A3Cmimectl_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "idr@ietf.org" , "robert@raszuk.net" 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, 02 Mar 2012 17:49:08 -0000 --_000_2E52B916689E4BECB07A5A8D4DFC9A3Cmimectl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I wasn't thinking about the packet length its self. In that case there is a= decent chance the os stack, a middle box or something is going to drop it = anyways as malformed. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: Tony Li [tony.li@tony.li] Sent: Friday, March 02, 2012 9:05 AM To: Smith, Donald Cc: robert@raszuk.net; Simpson, Adam (Adam); idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt On Mar 2, 2012, at 7:42 AM, Smith, Donald wrote: > But if the length is invalid the packet is somehow malformed. How can you= take any action on a malformed packet or trust any of the data in said pac= ket? > > I would vote for discard not dropping the session or taking any action on= a malformed packet. It's a message in a byte stream. If you no longer trust where the message = ended, where is the start of the next message? Tony ________________________________ This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. --_000_2E52B916689E4BECB07A5A8D4DFC9A3Cmimectl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I wasn'= t thinking about the packet length its self. In that case there is a decent= chance the os stack, a middle box or somethi= ng is going to drop it anyways as malformed.
 
(coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Sm= ith@qwest.com
From: Tony Li [to= ny.li@tony.li]
Sent: Friday, March 02, 2012 9:05 AM
To: Smith, Donald
Cc: robert@raszuk.net; Simpson, Adam (Adam); idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt<= br>

On Mar 2, 2012, at 7:42 AM, Smith, Donald wrote:

> But if the length is invalid the packet is somehow malformed. How can = you take any action on a malformed packet or trust any of the data in said = packet?
> 
> I would vote for discard not dropping the session or taking any action= on a malformed packet.


It's a message in a byte stream.  If you no longer trust where the mes= sage ended, where is the start of the next message?

Tony



This communication is the pr= operty of CenturyLink and may contain confidential or privileged informatio= n. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy<= br> all copies of the communication and any attachments.
 --_000_2E52B916689E4BECB07A5A8D4DFC9A3Cmimectl_-- From tony.li@tony.li Fri Mar 2 09:49:28 2012 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 82CFF21F8545 for ; Fri, 2 Mar 2012 09:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.371 X-Spam-Level: X-Spam-Status: No, score=-102.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 ug7+ABDl0RMs for ; Fri, 2 Mar 2012 09:49:27 -0800 (PST) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by ietfa.amsl.com (Postfix) with ESMTP id BDB5B21F84C3 for ; Fri, 2 Mar 2012 09:49:27 -0800 (PST) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta11.emeryville.ca.mail.comcast.net with comcast id ghpE1i0010lTkoCABhpTc1; Fri, 02 Mar 2012 17:49:27 +0000 Received: from [10.155.34.217] ([128.107.239.233]) by omta04.emeryville.ca.mail.comcast.net with comcast id ghpE1i00q52qHCY8QhpHqn; Fri, 02 Mar 2012 17:49:25 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Tony Li In-Reply-To: Date: Fri, 2 Mar 2012 09:49:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <32F442E8-8592-421F-919C-0C56D973D72B@tony.li> References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> , <4F505BA5.5070707@raszuk.net> , <4F50FB26.6090602@raszuk.net> To: "Smith, Donald" X-Mailer: Apple Mail (2.1257) Cc: "idr@ietf.org" , "robert@raszuk.net" 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, 02 Mar 2012 17:49:28 -0000 On Mar 2, 2012, at 9:43 AM, Smith, Donald wrote: > That was my assumption too (packet length is correct but some = attribute length is incorrect). How do you know that it was the attribute length and not the message = length? In reality, all you can tell is that they are inconsistent. Tony From robert@raszuk.net Fri Mar 2 09:56:20 2012 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 5F31821E8032 for ; Fri, 2 Mar 2012 09:56:20 -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 eYj+GHqbUuua for ; Fri, 2 Mar 2012 09:56:19 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id A36E521E8027 for ; Fri, 2 Mar 2012 09:56:19 -0800 (PST) Received: (qmail 26431 invoked by uid 399); 2 Mar 2012 17:56:19 -0000 Received: from unknown (HELO ?184.48.56.228?) (pbs:robert@raszuk.net@12.217.162.34) by mail1310.opentransfer.com with ESMTPM; 2 Mar 2012 17:56:19 -0000 X-Originating-IP: 12.217.162.34 Message-ID: <4F5109C6.2040507@raszuk.net> Date: Fri, 02 Mar 2012 18:56:22 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Smith, Donald" References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> , <4F505BA5.5070707@raszuk.net> , <4F50FB26.6090602@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, 02 Mar 2012 17:56:20 -0000 Hi Donald, > Now what could you do if ALL bgpupdate packets from a peer were > malformed? At some point you would have to treat it as a bad peer and > drop the session or something right? Actually the way specs and implementations are/will be there is no notion of "at some point". The implicit assumption is that error happens sporadically .. and here I must say that I am not convinced this is the right assumption. Another point is that this is to become a default when you upgrade the router. So we all need to carefully study release notes and as soon as possible after upgrade configure the knob not to follow this spec till our NOC scripts are able to catch those events from the syslog and generate alarms. Session will stay unless one of the fatal errors happen (invalid BGP message length itself is one of them). Cheers, R. From Donald.Smith@CenturyLink.com Fri Mar 2 10:09:42 2012 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 4B4B921F8494 for ; Fri, 2 Mar 2012 10:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=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 v42FKcBWM5k9 for ; Fri, 2 Mar 2012 10:09:41 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 853B821F8491 for ; Fri, 2 Mar 2012 10:09:41 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id q22I9eQi027436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Mar 2012 12:09:41 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id A2A2E1E0067; Fri, 2 Mar 2012 11:09:35 -0700 (MST) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 7E9611E0062; Fri, 2 Mar 2012 11:09:35 -0700 (MST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id q22I9ZcN015423; Fri, 2 Mar 2012 12:09:35 -0600 (CST) Received: from qtdenexhtm22.AD.QINTRA.COM (qtdenexhtm22.ad.qintra.com [151.119.91.231]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id q22I9YAt015393 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 2 Mar 2012 12:09:34 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Fri, 2 Mar 2012 11:09:33 -0700 From: "Smith, Donald" To: Tony Li Content-Class: urn:content-classes:message Date: Fri, 2 Mar 2012 11:09:45 -0700 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt Thread-Index: Acz4nNGFIVdNct/qSY2Y7/2+7wvXEwAAoxd4AAASEyg= Message-ID: <88898E4B-EB46-491B-9F64-748E22785010@mimectl> References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> , <4F505BA5.5070707@raszuk.net> , <4F50FB26.6090602@raszuk.net> , <32F442E8-8592-421F-919C-0C56D973D72B@tony.li> In-Reply-To: <32F442E8-8592-421F-919C-0C56D973D72B@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.3.105.0 Content-Type: multipart/alternative; boundary="_000_88898E4BEB46491B9F64748E22785010mimectl_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "idr@ietf.org" , "robert@raszuk.net" 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, 02 Mar 2012 18:09:42 -0000 --_000_88898E4BEB46491B9F64748E22785010mimectl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the checksum is correct and the packet length matches the actual packet = length I think you could assume just the attribute length was incorrect for= some reason. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: Tony Li [tony.li@tony.li] Sent: Friday, March 02, 2012 10:49 AM To: Smith, Donald Cc: robert@raszuk.net; idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt On Mar 2, 2012, at 9:43 AM, Smith, Donald wrote: > That was my assumption too (packet length is correct but some attribute l= ength is incorrect). How do you know that it was the attribute length and not the message length= ? In reality, all you can tell is that they are inconsistent. Tony ________________________________ This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. --_000_88898E4BEB46491B9F64748E22785010mimectl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If the = checksum is correct and the packet length matches the actual packet length = I think you could assume just the attribute length was incorrect for some r= eason.
 
(coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Sm= ith@qwest.com
From: Tony Li [to= ny.li@tony.li]
Sent: Friday, March 02, 2012 10:49 AM
To: Smith, Donald
Cc: robert@raszuk.net; idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt<= br>

On Mar 2, 2012, at 9:43 AM, Smith, Donald wrote:

> That was my assumption too (packet length is correct but some attribut= e length is incorrect).


How do you know that it was the attribute length and not the message length= ?   In reality, all you can tell is that they are inconsistent.
Tony



This communication is the pr= operty of CenturyLink and may contain confidential or privileged informatio= n. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy<= br> all copies of the communication and any attachments.
 --_000_88898E4BEB46491B9F64748E22785010mimectl_-- From tony.li@tony.li Fri Mar 2 10:17:29 2012 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 D20BD21E802D for ; Fri, 2 Mar 2012 10:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 FSRDLuvKWZGi for ; Fri, 2 Mar 2012 10:17:29 -0800 (PST) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4DC21E8019 for ; Fri, 2 Mar 2012 10:17:28 -0800 (PST) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta06.emeryville.ca.mail.comcast.net with comcast id gf831i0021u4NiLA6iHUHd; Fri, 02 Mar 2012 18:17:28 +0000 Received: from [10.155.34.217] ([128.107.239.233]) by omta21.emeryville.ca.mail.comcast.net with comcast id giHE1i00f52qHCY8hiHHTC; Fri, 02 Mar 2012 18:17:26 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Tony Li In-Reply-To: <88898E4B-EB46-491B-9F64-748E22785010@mimectl> Date: Fri, 2 Mar 2012 10:17:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> , <4F505BA5.5070707@raszuk.net> , <4F50FB26.6090602@raszuk.net> , <32F442E8-8592-421F-919C-0C56D973D72B@tony.li> <88898E4B-EB46-491B-9F64-748E22785010@mimectl> To: "Smith, Donald" X-Mailer: Apple Mail (2.1257) Cc: "idr@ietf.org" , "robert@raszuk.net" 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, 02 Mar 2012 18:17:29 -0000 On Mar 2, 2012, at 10:09 AM, Smith, Donald wrote: > If the checksum is correct and the packet length matches the actual = packet length I think you could assume just the attribute length was = incorrect for some reason. I'm sorry. We are talking about BGP here, yes??? This is IDR, yes??? The checksum is on the TCP packet, which is the transport wrapper for = the byte stream. The IP packet length only gives you the length of the = TCP segment and has no bearing whatsoever on BGP. It is completely orthogonal to the message length or attribute length. Tony From adam.simpson@alcatel-lucent.com Fri Mar 2 11:25:46 2012 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 A3CA921E801F for ; Fri, 2 Mar 2012 11:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 B7jmJLeGo6Fj for ; Fri, 2 Mar 2012 11:25:45 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED9D21E8019 for ; Fri, 2 Mar 2012 11:25:45 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q22JPihu019564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Mar 2012 13:25:44 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q22JPhKt010863 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 13:25:43 -0600 Received: from USNAVSXCHMBSC1.ndc.alcatel-lucent.com ([135.3.39.146]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 2 Mar 2012 13:25:43 -0600 From: "Simpson, Adam (Adam)" To: Enke Chen , "idr@ietf.org" Date: Fri, 2 Mar 2012 13:25:53 -0600 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt Thread-Index: Acz39WrScpEI9qTwS+GYkngaB9HvUQAsqvuQ Message-ID: References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <4F4FF078.8050106@cisco.com> In-Reply-To: <4F4FF078.8050106@cisco.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 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, 02 Mar 2012 19:25:46 -0000 Enke, If this is the assumption then I think it should be stated explicitly. But this still does not address the root of my concern. Suppose, hypothetic= ally, some implementation builds a correct 8-byte aggregator attribute but = reports that it is 12-bytes long and adds 12 bytes for it when computing th= e total path attributes length. If the treat-as-withdraw logic is enabled t= he receiver could incorrectly conclude that all the NLRI were upfront and m= iss that there was in fact a single 4-byte NLRI field at the end. The recei= ver misses it because it jumped to the end of the Update on the basis of tr= usting length fields that were consistent, but unfortunately consistently w= rong. Wouldn't it have been safer to reset the session? -Adam > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Enke Chen > Sent: Thursday, March 01, 2012 4:56 PM > To: idr@ietf.org > Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt >=20 > Hi, Adam: >=20 > Not sure if we need extra text. The receiver must use the attribute > length encoded in the message to continue parsing the message. >=20 > -- Enke >=20 > On 3/1/12 12:55 PM, Simpson, Adam (Adam) wrote: > > Authors, > > > > Thank you for your work on this. > > > > One topic that I would like see discussed more thoroughly in a next > version of the draft is how attribute-length errors should be handled > and whether it's even appropriate for these types of errors to fall > under the scope of the treat-as-withdrawn or attribute-discard > approaches. > > > > In section 5 of the current draft you give examples of a malformed > community attribute as one with a length that is not a multiple of 4 > bytes and a malformed aggregator attribute as one with a length that is > not 6 or 8 bytes. The trouble I have with treating these types of > errors using treat-as-withdrawn or attribute-discard is that you are > forcing the receiver of a malformed Update message to guess what the > sender actually encoded. If an aggregator attribute with a reported > length of 7 bytes is received did the sender encode 6 bytes and > incorrectly put 7 in the length field or did they put an extra byte of > garbage in the attribute? > > > > Fundamentally, I think it would be better to restrict treat-as- > withdraw and attribute-discard to cases where the length of an > attribute is not in question. If you disagree then I think you must add > text to the draft that describes what an implementation should assume > when it sees a length error such as the example discussed above - e.g. > should it assume the "closest" valid value? There is probably a small > chance of making a wrong "guess" that actually results in successful > parsing of the message but if that chance is at all greater than 0 it > seems we are taking treat-as-wthdrawn a step too far. > > > > Adam > > > >> -----Original Message----- > >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf > Of > >> internet-drafts@ietf.org > >> Sent: Thursday, December 15, 2011 6:39 PM > >> To: i-d-announce@ietf.org > >> Cc: idr@ietf.org > >> Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-01.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 : 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 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From enkechen@cisco.com Fri Mar 2 11:36:47 2012 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 D42D121F85FD for ; Fri, 2 Mar 2012 11:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 1YJC3ejti+Mn for ; Fri, 2 Mar 2012 11:36:46 -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 DB6F521F85FC for ; Fri, 2 Mar 2012 11:36:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=5642; q=dns/txt; s=iport; t=1330717006; x=1331926606; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=xlVGlESVRXgM5bIQTt+T06Cuwtv59UFaswToeHsLseE=; b=aPQjtvIG5OsdGD74sRAoTqcTxd1fdsgmQKwhwLLH5dCTUg1oy4ciAmAV d4ZXP/Kjha6IeWLPJQxjIa/3S8cbINisOVDMkAldwnpAD3TYCfNL2TBmM ax6ZfMZT9U+Zn5luI7XiKLFGlVCqJBuXC00uuTx14rBhWaZC3YkNCHbC6 U=; X-IronPort-AV: E=Sophos;i="4.73,519,1325462400"; d="scan'208";a="34017647" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 02 Mar 2012 19:36:46 +0000 Received: from dhcp-171-71-139-175.cisco.com (dhcp-171-71-139-175.cisco.com [171.71.139.175]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q22JakcY013455; Fri, 2 Mar 2012 19:36:46 GMT Message-ID: <4F512280.6020307@cisco.com> Date: Fri, 02 Mar 2012 11:41:52 -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: "Simpson, Adam (Adam)" References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <4F4FF078.8050106@cisco.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 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 19:36:47 -0000 Adam, There is a tradeoff - impact on one route vs all routes carried over the session in your example. That is why the draft states that the error conditions must be logged and analyzed. -- Enke On 3/2/12 11:25 AM, Simpson, Adam (Adam) wrote: > Enke, > > If this is the assumption then I think it should be stated explicitly. > > But this still does not address the root of my concern. Suppose, hypothetically, some implementation builds a correct 8-byte aggregator attribute but reports that it is 12-bytes long and adds 12 bytes for it when computing the total path attributes length. If the treat-as-withdraw logic is enabled the receiver could incorrectly conclude that all the NLRI were upfront and miss that there was in fact a single 4-byte NLRI field at the end. The receiver misses it because it jumped to the end of the Update on the basis of trusting length fields that were consistent, but unfortunately consistently wrong. Wouldn't it have been safer to reset the session? > > -Adam > >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of >> Enke Chen >> Sent: Thursday, March 01, 2012 4:56 PM >> To: idr@ietf.org >> Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt >> >> Hi, Adam: >> >> Not sure if we need extra text. The receiver must use the attribute >> length encoded in the message to continue parsing the message. >> >> -- Enke >> >> On 3/1/12 12:55 PM, Simpson, Adam (Adam) wrote: >>> Authors, >>> >>> Thank you for your work on this. >>> >>> One topic that I would like see discussed more thoroughly in a next >> version of the draft is how attribute-length errors should be handled >> and whether it's even appropriate for these types of errors to fall >> under the scope of the treat-as-withdrawn or attribute-discard >> approaches. >>> In section 5 of the current draft you give examples of a malformed >> community attribute as one with a length that is not a multiple of 4 >> bytes and a malformed aggregator attribute as one with a length that is >> not 6 or 8 bytes. The trouble I have with treating these types of >> errors using treat-as-withdrawn or attribute-discard is that you are >> forcing the receiver of a malformed Update message to guess what the >> sender actually encoded. If an aggregator attribute with a reported >> length of 7 bytes is received did the sender encode 6 bytes and >> incorrectly put 7 in the length field or did they put an extra byte of >> garbage in the attribute? >>> Fundamentally, I think it would be better to restrict treat-as- >> withdraw and attribute-discard to cases where the length of an >> attribute is not in question. If you disagree then I think you must add >> text to the draft that describes what an implementation should assume >> when it sees a length error such as the example discussed above - e.g. >> should it assume the "closest" valid value? There is probably a small >> chance of making a wrong "guess" that actually results in successful >> parsing of the message but if that chance is at all greater than 0 it >> seems we are taking treat-as-wthdrawn a step too far. >>> Adam >>> >>>> -----Original Message----- >>>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf >> Of >>>> internet-drafts@ietf.org >>>> Sent: Thursday, December 15, 2011 6:39 PM >>>> To: i-d-announce@ietf.org >>>> Cc: idr@ietf.org >>>> Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-01.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 : 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 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr From adam.simpson@alcatel-lucent.com Fri Mar 2 11:47:39 2012 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 4993621E8048 for ; Fri, 2 Mar 2012 11:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.932 X-Spam-Level: X-Spam-Status: No, score=-9.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 qXiij54S0b45 for ; Fri, 2 Mar 2012 11:47:38 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5140421E803D for ; Fri, 2 Mar 2012 11:47:38 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q22JlWn9012718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Mar 2012 13:47:33 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q22JlV8w014194 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 13:47:31 -0600 Received: from USNAVSXCHMBSC1.ndc.alcatel-lucent.com ([135.3.39.146]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 2 Mar 2012 13:47:31 -0600 From: "Simpson, Adam (Adam)" To: Enke Chen Date: Fri, 2 Mar 2012 13:47:51 -0600 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt Thread-Index: Acz4q9AejnpEJ9sVSsi+LGIy68AhBgAAHJZA Message-ID: References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <4F4FF078.8050106@cisco.com> <4F512280.6020307@cisco.com> In-Reply-To: <4F512280.6020307@cisco.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 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, 02 Mar 2012 19:47:39 -0000 I agree, but I think there has been a general consensus in these discussion= s that we should keep the new/revised error handling procedures as simple a= s possible. Using treat as withdraw with length-related attribute errors is= going to increase implementation complexity for what I suspect is very lit= tle net benefit. -Adam > -----Original Message----- > From: Enke Chen [mailto:enkechen@cisco.com] > Sent: Friday, March 02, 2012 2:42 PM > To: Simpson, Adam (Adam) > Cc: idr@ietf.org; Enke Chen > Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt >=20 > Adam, >=20 > There is a tradeoff - impact on one route vs all routes carried over > the > session in your example. That is why the draft states that the error > conditions must be logged and analyzed. >=20 > -- Enke >=20 > On 3/2/12 11:25 AM, Simpson, Adam (Adam) wrote: > > Enke, > > > > If this is the assumption then I think it should be stated > explicitly. > > > > But this still does not address the root of my concern. Suppose, > hypothetically, some implementation builds a correct 8-byte aggregator > attribute but reports that it is 12-bytes long and adds 12 bytes for it > when computing the total path attributes length. If the treat-as- > withdraw logic is enabled the receiver could incorrectly conclude that > all the NLRI were upfront and miss that there was in fact a single 4- > byte NLRI field at the end. The receiver misses it because it jumped to > the end of the Update on the basis of trusting length fields that were > consistent, but unfortunately consistently wrong. Wouldn't it have been > safer to reset the session? > > > > -Adam > > > >> -----Original Message----- > >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf > Of > >> Enke Chen > >> Sent: Thursday, March 01, 2012 4:56 PM > >> To: idr@ietf.org > >> Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt > >> > >> Hi, Adam: > >> > >> Not sure if we need extra text. The receiver must use the attribute > >> length encoded in the message to continue parsing the message. > >> > >> -- Enke > >> > >> On 3/1/12 12:55 PM, Simpson, Adam (Adam) wrote: > >>> Authors, > >>> > >>> Thank you for your work on this. > >>> > >>> One topic that I would like see discussed more thoroughly in a next > >> version of the draft is how attribute-length errors should be > handled > >> and whether it's even appropriate for these types of errors to fall > >> under the scope of the treat-as-withdrawn or attribute-discard > >> approaches. > >>> In section 5 of the current draft you give examples of a malformed > >> community attribute as one with a length that is not a multiple of 4 > >> bytes and a malformed aggregator attribute as one with a length that > is > >> not 6 or 8 bytes. The trouble I have with treating these types of > >> errors using treat-as-withdrawn or attribute-discard is that you are > >> forcing the receiver of a malformed Update message to guess what the > >> sender actually encoded. If an aggregator attribute with a reported > >> length of 7 bytes is received did the sender encode 6 bytes and > >> incorrectly put 7 in the length field or did they put an extra byte > of > >> garbage in the attribute? > >>> Fundamentally, I think it would be better to restrict treat-as- > >> withdraw and attribute-discard to cases where the length of an > >> attribute is not in question. If you disagree then I think you must > add > >> text to the draft that describes what an implementation should > assume > >> when it sees a length error such as the example discussed above - > e.g. > >> should it assume the "closest" valid value? There is probably a > small > >> chance of making a wrong "guess" that actually results in successful > >> parsing of the message but if that chance is at all greater than 0 > it > >> seems we are taking treat-as-wthdrawn a step too far. > >>> Adam > >>> > >>>> -----Original Message----- > >>>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf > >> Of > >>>> internet-drafts@ietf.org > >>>> Sent: Thursday, December 15, 2011 6:39 PM > >>>> To: i-d-announce@ietf.org > >>>> Cc: idr@ietf.org > >>>> Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-01.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 : 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 > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www.ietf.org/mailman/listinfo/idr From enkechen@cisco.com Fri Mar 2 11:52:32 2012 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 AAC1E21F84A0 for ; Fri, 2 Mar 2012 11:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 pNZkLA47sE5P for ; Fri, 2 Mar 2012 11:52:31 -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 ADBAB21F849A for ; Fri, 2 Mar 2012 11:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=6759; q=dns/txt; s=iport; t=1330717951; x=1331927551; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=z/rliTEPltXZHBgxliaTbiSHlqm1qawXAxVDYULxe+4=; b=dP+183OJvj7hiQh08VdMtwz1wqu1cRFO5RISyQpn1KI4uxIzhO17wHkg Iwmcs2yb/0A7GqbkLkOtzRCsXB8VsFM1sD9ORnQDYYjYTkcEjX6khH8eE 7+g/3j99OFaV25df3LnEw+DiFf4OgBwz8aWxTztX78yeOc4Tn/+NfaB4T w=; X-IronPort-AV: E=Sophos;i="4.73,519,1325462400"; d="scan'208";a="34021492" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 02 Mar 2012 19:52:31 +0000 Received: from dhcp-171-71-139-175.cisco.com (dhcp-171-71-139-175.cisco.com [171.71.139.175]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q22JqVK9003243; Fri, 2 Mar 2012 19:52:31 GMT Message-ID: <4F512631.7070909@cisco.com> Date: Fri, 02 Mar 2012 11:57:37 -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: "Simpson, Adam (Adam)" References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <4F4FF078.8050106@cisco.com> <4F512280.6020307@cisco.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 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 19:52:32 -0000 Well, the case of the "attr length of 3000 bytes" in the field states loudly for using "treat-as-withdraw". -- Enke On 3/2/12 11:47 AM, Simpson, Adam (Adam) wrote: > I agree, but I think there has been a general consensus in these discussions that we should keep the new/revised error handling procedures as simple as possible. Using treat as withdraw with length-related attribute errors is going to increase implementation complexity for what I suspect is very little net benefit. > > -Adam > >> -----Original Message----- >> From: Enke Chen [mailto:enkechen@cisco.com] >> Sent: Friday, March 02, 2012 2:42 PM >> To: Simpson, Adam (Adam) >> Cc: idr@ietf.org; Enke Chen >> Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt >> >> Adam, >> >> There is a tradeoff - impact on one route vs all routes carried over >> the >> session in your example. That is why the draft states that the error >> conditions must be logged and analyzed. >> >> -- Enke >> >> On 3/2/12 11:25 AM, Simpson, Adam (Adam) wrote: >>> Enke, >>> >>> If this is the assumption then I think it should be stated >> explicitly. >>> But this still does not address the root of my concern. Suppose, >> hypothetically, some implementation builds a correct 8-byte aggregator >> attribute but reports that it is 12-bytes long and adds 12 bytes for it >> when computing the total path attributes length. If the treat-as- >> withdraw logic is enabled the receiver could incorrectly conclude that >> all the NLRI were upfront and miss that there was in fact a single 4- >> byte NLRI field at the end. The receiver misses it because it jumped to >> the end of the Update on the basis of trusting length fields that were >> consistent, but unfortunately consistently wrong. Wouldn't it have been >> safer to reset the session? >>> -Adam >>> >>>> -----Original Message----- >>>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf >> Of >>>> Enke Chen >>>> Sent: Thursday, March 01, 2012 4:56 PM >>>> To: idr@ietf.org >>>> Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt >>>> >>>> Hi, Adam: >>>> >>>> Not sure if we need extra text. The receiver must use the attribute >>>> length encoded in the message to continue parsing the message. >>>> >>>> -- Enke >>>> >>>> On 3/1/12 12:55 PM, Simpson, Adam (Adam) wrote: >>>>> Authors, >>>>> >>>>> Thank you for your work on this. >>>>> >>>>> One topic that I would like see discussed more thoroughly in a next >>>> version of the draft is how attribute-length errors should be >> handled >>>> and whether it's even appropriate for these types of errors to fall >>>> under the scope of the treat-as-withdrawn or attribute-discard >>>> approaches. >>>>> In section 5 of the current draft you give examples of a malformed >>>> community attribute as one with a length that is not a multiple of 4 >>>> bytes and a malformed aggregator attribute as one with a length that >> is >>>> not 6 or 8 bytes. The trouble I have with treating these types of >>>> errors using treat-as-withdrawn or attribute-discard is that you are >>>> forcing the receiver of a malformed Update message to guess what the >>>> sender actually encoded. If an aggregator attribute with a reported >>>> length of 7 bytes is received did the sender encode 6 bytes and >>>> incorrectly put 7 in the length field or did they put an extra byte >> of >>>> garbage in the attribute? >>>>> Fundamentally, I think it would be better to restrict treat-as- >>>> withdraw and attribute-discard to cases where the length of an >>>> attribute is not in question. If you disagree then I think you must >> add >>>> text to the draft that describes what an implementation should >> assume >>>> when it sees a length error such as the example discussed above - >> e.g. >>>> should it assume the "closest" valid value? There is probably a >> small >>>> chance of making a wrong "guess" that actually results in successful >>>> parsing of the message but if that chance is at all greater than 0 >> it >>>> seems we are taking treat-as-wthdrawn a step too far. >>>>> Adam >>>>> >>>>>> -----Original Message----- >>>>>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf >>>> Of >>>>>> internet-drafts@ietf.org >>>>>> Sent: Thursday, December 15, 2011 6:39 PM >>>>>> To: i-d-announce@ietf.org >>>>>> Cc: idr@ietf.org >>>>>> Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-01.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 : 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 >>>> _______________________________________________ >>>> Idr mailing list >>>> Idr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/idr From shares@ndzh.com Mon Mar 5 06:41:11 2012 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 6ED5021F85DD for ; Mon, 5 Mar 2012 06:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.365 X-Spam-Level: * X-Spam-Status: No, score=1.365 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 wX0uUmh4YHxC for ; Mon, 5 Mar 2012 06:41:07 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [63.208.161.199]) by ietfa.amsl.com (Postfix) with ESMTP id C729B21F85B1 for ; Mon, 5 Mar 2012 06:41:06 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; Received: from SKH2012HPLT (unverified [64.112.195.202]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3149912-1945496 for multiple; Mon, 05 Mar 2012 09:40:57 -0500 From: "Susan Hares" To: Date: Mon, 5 Mar 2012 09:40:31 -0500 Message-ID: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01CCFAB4.10AC3400" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acz61uBlkDjofv9/R0W0yyxZy63EwA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: [Idr] WG adoption call 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 Mar 2012 14:41:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0055_01CCFAB4.10AC3400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is to start a 2 week WG call for Adoption of draft-ymbk-rfd-usable-02.txt. Please send support or comments to the mailing list. The WG call for adoption will last from 3/5 to 3/19. We'll summarize this before the IDR meeting. Sue and John ---------------------------- Here's document info: http://datatracker.ietf.org/doc/draft-ymbk-rfd-usable/ Abstract: Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well-connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits, to reduce the high risks with RFD, with the result being damping a non-trivial amount of long term churn without penalizing well-behaved prefixes' normal convergence process. C. Pelsser, R. Bush (IIJ) K. Patel, P. Mohapatra (Cisco Systems) O. Maenel (Loughborough University) ------=_NextPart_000_0055_01CCFAB4.10AC3400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

This is to = start a 2 week WG call for Adoption of = draft-ymbk-rfd-usable-02.txt.

 

Please send = support or comments to the mailing list.  The WG call for adoption = will last from

3/5 to 3/19.  = We’ll summarize this before the IDR meeting.

 

Sue and = John

 

----------------------------

 

 

Here’s = document info:  

 

http://da= tatracker.ietf.org/doc/draft-ymbk-rfd-usable/

 

Abstract: =

 

   Route = Flap Damping (RFD) was first proposed to reduce BGP churn = in

   = routers.  Unfortunately, RFD was found to severely penalize sites = for

   being = well-connected because topological richness amplifies = the

   number = of update messages exchanged.  Many operators have turned = RFD

   = off.  Based on experimental measurement, this document = recommends

   = adjusting a few RFD algorithmic constants and limits, to reduce = the

   high = risks with RFD, with the result being damping a = non-trivial

   amount = of long term churn without penalizing well-behaved = prefixes'

   normal = convergence process.

 

C. Pelsser, R. Bush = (IIJ)

K. Patel, P. = Mohapatra (Cisco Systems)

O. Maenel = (Loughborough University)

 

 

 

 

 

 

 

 

------=_NextPart_000_0055_01CCFAB4.10AC3400-- From randy@psg.com Mon Mar 5 06:48:59 2012 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 C173721F8624 for ; Mon, 5 Mar 2012 06:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 EDd-zdjVvoCN for ; Mon, 5 Mar 2012 06:48:59 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 695A021F8601 for ; Mon, 5 Mar 2012 06:48:59 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S4ZDe-000GCb-56; Mon, 05 Mar 2012 14:48:58 +0000 Date: Mon, 05 Mar 2012 23:48:57 +0900 Message-ID: From: Randy Bush To: Susan Hares In-Reply-To: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> References: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] WG adoption call 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 Mar 2012 14:48:59 -0000 > This is to start a 2 week WG call for Adoption of > draft-ymbk-rfd-usable-02.txt. > > Please send support or comments to the mailing list. The WG call for > adoption will last from and, while the issue on the table is whether or not this work should be adopted by idr, not the minutae of its content, the authors would gladly take constructive content suggestions before the march 12th dreadline. send text :) randy From warren@kumari.net Mon Mar 5 07:01:04 2012 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 6AD4821F8779 for ; Mon, 5 Mar 2012 07:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.478 X-Spam-Level: X-Spam-Status: No, score=-106.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 GiXME-8m4BYl for ; Mon, 5 Mar 2012 07:01:04 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id DFB7C21F855B for ; Mon, 5 Mar 2012 07:01:03 -0800 (PST) Received: from dhcp-172-19-119-93.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id BC1221B41873; Mon, 5 Mar 2012 10:01:02 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> Date: Mon, 5 Mar 2012 10:01:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7F57089A-6083-49FB-8CFD-E826DD0E03B6@kumari.net> References: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> To: "Susan Hares" X-Mailer: Apple Mail (2.1084) Cc: idr@ietf.org Subject: Re: [Idr] WG adoption call 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 Mar 2012 15:01:04 -0000 On Mar 5, 2012, at 9:40 AM, Susan Hares wrote: > =20 > This is to start a 2 week WG call for Adoption of = draft-ymbk-rfd-usable-02.txt. Support -- have read, discussed and commented. Actually, to be 100% honest, I thought that we had already done an = adoption call and accepted this (but apparently I am misremembering...) W > =20 > Please send support or comments to the mailing list. The WG call for = adoption will last from > 3/5 to 3/19. We=92ll summarize this before the IDR meeting. > =20 > Sue and John > =20 > ---------------------------- > =20 > =20 > Here=92s document info: =20 > =20 > http://datatracker.ietf.org/doc/draft-ymbk-rfd-usable/ > =20 > Abstract: > =20 > Route Flap Damping (RFD) was first proposed to reduce BGP churn in > routers. Unfortunately, RFD was found to severely penalize sites = for > being well-connected because topological richness amplifies the > number of update messages exchanged. Many operators have turned = RFD > off. Based on experimental measurement, this document recommends > adjusting a few RFD algorithmic constants and limits, to reduce the > high risks with RFD, with the result being damping a non-trivial > amount of long term churn without penalizing well-behaved prefixes' > normal convergence process. > =20 > C. Pelsser, R. Bush (IIJ) > K. Patel, P. Mohapatra (Cisco Systems) > O. Maenel (Loughborough University) > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From tony.li@tony.li Mon Mar 5 08:12:28 2012 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 1CD2B21F87E1 for ; Mon, 5 Mar 2012 08:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 KcIUlo+2i97R for ; Mon, 5 Mar 2012 08:12:27 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA5021F87DF for ; Mon, 5 Mar 2012 08:12:27 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta13.westchester.pa.mail.comcast.net with comcast id hs8N1i0021GhbT85DsCTUi; Mon, 05 Mar 2012 16:12:27 +0000 Received: from dhcp-10-155-71-200.cisco.com ([128.107.239.233]) by omta07.westchester.pa.mail.comcast.net with comcast id hsCF1i00t52qHCY3TsCJz1; Mon, 05 Mar 2012 16:12:25 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Tony Li In-Reply-To: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> Date: Mon, 5 Mar 2012 08:12:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> To: "Susan Hares" X-Mailer: Apple Mail (2.1257) Cc: idr@ietf.org Subject: Re: [Idr] WG adoption call 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 Mar 2012 16:12:28 -0000 On Mar 5, 2012, at 6:40 AM, Susan Hares wrote: > This is to start a 2 week WG call for Adoption of = draft-ymbk-rfd-usable-02.txt. > =20 > Please send support or comments to the mailing list. The WG call for = adoption will last from > 3/5 to 3/19. We=92ll summarize this before the IDR meeting. I support adoption. Tony From gdawra@cisco.com Mon Mar 5 08:18:26 2012 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 C2FA821F8855 for ; Mon, 5 Mar 2012 08:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 jIzXili0fJEI for ; Mon, 5 Mar 2012 08:18:26 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1130621F8852 for ; Mon, 5 Mar 2012 08:18:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gdawra@cisco.com; l=576; q=dns/txt; s=iport; t=1330964306; x=1332173906; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=IljNcqDFVtLGnR/XbiO37yusbhjHhSjSC7v4B1jrHEY=; b=FAtqDyKBtkK3qhFKof9JEltOW1riQ/Hm+ubR76f7b1xDhkXzLbmuMEBm kRrkLClBbuMC1oQ0GiheTh9x3vKKF7+Vm/Kvds97PZWhavaGc4CI7JMfk wXS2dxpv4cdn/UOn8jiYAcck2WN1Uar7VIti9Ng3yK00iGrzMB0gZdR+x w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJvmVE+tJV2Y/2dsb2JhbABCtGmBB4F9AQEBBAEBAQ8BClELEgEIGFULJQIEAQ0FIodlC6BbAZZxBJBdBIgdjSGQEoJj X-IronPort-AV: E=Sophos;i="4.73,534,1325462400"; d="scan'208";a="63852488" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 05 Mar 2012 16:18:25 +0000 Received: from xht-rcd-x01-p.cisco.com (xht-rcd-x01-p.cisco.com [173.37.178.212]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q25GIPI3011805; Mon, 5 Mar 2012 16:18:25 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.137]) by xht-rcd-x01-p.cisco.com ([173.37.178.212]) with mapi id 14.02.0283.003; Mon, 5 Mar 2012 08:18:25 -0800 From: "Gaurav Dawra (gdawra)" To: Tony Li , Susan Hares Thread-Topic: [Idr] WG adoption call Thread-Index: AQHM+uuWkDjofv9/R0W0yyxZy63EwA== Date: Mon, 5 Mar 2012 16:18:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18752.005 x-tm-as-result: No--31.723800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <36BB60AF53C2EF4B8E400F91DC0904D2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] WG adoption call 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 Mar 2012 16:18:26 -0000 Support Adoption. -Gaurav On 3/5/12 8:12 AM, "Tony Li" wrote: > >On Mar 5, 2012, at 6:40 AM, Susan Hares wrote: > >> This is to start a 2 week WG call for Adoption of >>draft-ymbk-rfd-usable-02.txt. >> =20 >> Please send support or comments to the mailing list. The WG call for >>adoption will last from >> 3/5 to 3/19. We=B9ll summarize this before the IDR meeting. > > >I support adoption. > >Tony > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From adam.simpson@alcatel-lucent.com Mon Mar 5 11:03:44 2012 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 906C621F88C1 for ; Mon, 5 Mar 2012 11:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 hehEbIlfXwtZ for ; Mon, 5 Mar 2012 11:03:43 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 889A221F88AE for ; Mon, 5 Mar 2012 11:03:43 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q25J3gQn000310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Mar 2012 13:03:42 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q25J3g7D023843 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Mar 2012 13:03:42 -0600 Received: from USNAVSXCHMBSC1.ndc.alcatel-lucent.com ([135.3.39.146]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 5 Mar 2012 13:03:41 -0600 From: "Simpson, Adam (Adam)" To: Enke Chen Date: Mon, 5 Mar 2012 13:03:39 -0600 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt Thread-Index: Acz4rgRwKKAcyRaqQKGZ5O46ScasgACUohkg Message-ID: References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <4F4FF078.8050106@cisco.com> <4F512280.6020307@cisco.com> <4F512631.7070909@cisco.com> In-Reply-To: <4F512631.7070909@cisco.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 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, 05 Mar 2012 19:03:44 -0000 I think there is a major difference between a 3000-byte optional transitive= attribute that is new and unknown vs. a standardized attribute such as agg= regator or extended community. A router receiving the optional transitive a= ttribute for the first time has no idea whether 3000 bytes is a correct/val= id length or not but it certainly knows that a 12-byte aggregator attribute= is invalid. > -----Original Message----- > From: Enke Chen [mailto:enkechen@cisco.com] > Sent: Friday, March 02, 2012 2:58 PM > To: Simpson, Adam (Adam) > Cc: idr@ietf.org; Enke Chen > Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt >=20 > Well, the case of the "attr length of 3000 bytes" in the field states > loudly for using "treat-as-withdraw". >=20 > -- Enke >=20 > On 3/2/12 11:47 AM, Simpson, Adam (Adam) wrote: > > I agree, but I think there has been a general consensus in these > discussions that we should keep the new/revised error handling > procedures as simple as possible. Using treat as withdraw with length- > related attribute errors is going to increase implementation complexity > for what I suspect is very little net benefit. > > > > -Adam > > > >> -----Original Message----- > >> From: Enke Chen [mailto:enkechen@cisco.com] > >> Sent: Friday, March 02, 2012 2:42 PM > >> To: Simpson, Adam (Adam) > >> Cc: idr@ietf.org; Enke Chen > >> Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt > >> > >> Adam, > >> > >> There is a tradeoff - impact on one route vs all routes carried over > >> the > >> session in your example. That is why the draft states that the > error > >> conditions must be logged and analyzed. > >> > >> -- Enke > >> > >> On 3/2/12 11:25 AM, Simpson, Adam (Adam) wrote: > >>> Enke, > >>> > >>> If this is the assumption then I think it should be stated > >> explicitly. > >>> But this still does not address the root of my concern. Suppose, > >> hypothetically, some implementation builds a correct 8-byte > aggregator > >> attribute but reports that it is 12-bytes long and adds 12 bytes for > it > >> when computing the total path attributes length. If the treat-as- > >> withdraw logic is enabled the receiver could incorrectly conclude > that > >> all the NLRI were upfront and miss that there was in fact a single > 4- > >> byte NLRI field at the end. The receiver misses it because it jumped > to > >> the end of the Update on the basis of trusting length fields that > were > >> consistent, but unfortunately consistently wrong. Wouldn't it have > been > >> safer to reset the session? > >>> -Adam > >>> > >>>> -----Original Message----- > >>>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf > >> Of > >>>> Enke Chen > >>>> Sent: Thursday, March 01, 2012 4:56 PM > >>>> To: idr@ietf.org > >>>> Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling- > 01.txt > >>>> > >>>> Hi, Adam: > >>>> > >>>> Not sure if we need extra text. The receiver must use the > attribute > >>>> length encoded in the message to continue parsing the message. > >>>> > >>>> -- Enke > >>>> > >>>> On 3/1/12 12:55 PM, Simpson, Adam (Adam) wrote: > >>>>> Authors, > >>>>> > >>>>> Thank you for your work on this. > >>>>> > >>>>> One topic that I would like see discussed more thoroughly in a > next > >>>> version of the draft is how attribute-length errors should be > >> handled > >>>> and whether it's even appropriate for these types of errors to > fall > >>>> under the scope of the treat-as-withdrawn or attribute-discard > >>>> approaches. > >>>>> In section 5 of the current draft you give examples of a > malformed > >>>> community attribute as one with a length that is not a multiple of > 4 > >>>> bytes and a malformed aggregator attribute as one with a length > that > >> is > >>>> not 6 or 8 bytes. The trouble I have with treating these types of > >>>> errors using treat-as-withdrawn or attribute-discard is that you > are > >>>> forcing the receiver of a malformed Update message to guess what > the > >>>> sender actually encoded. If an aggregator attribute with a > reported > >>>> length of 7 bytes is received did the sender encode 6 bytes and > >>>> incorrectly put 7 in the length field or did they put an extra > byte > >> of > >>>> garbage in the attribute? > >>>>> Fundamentally, I think it would be better to restrict treat-as- > >>>> withdraw and attribute-discard to cases where the length of an > >>>> attribute is not in question. If you disagree then I think you > must > >> add > >>>> text to the draft that describes what an implementation should > >> assume > >>>> when it sees a length error such as the example discussed above - > >> e.g. > >>>> should it assume the "closest" valid value? There is probably a > >> small > >>>> chance of making a wrong "guess" that actually results in > successful > >>>> parsing of the message but if that chance is at all greater than 0 > >> it > >>>> seems we are taking treat-as-wthdrawn a step too far. > >>>>> Adam > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On > Behalf > >>>> Of > >>>>>> internet-drafts@ietf.org > >>>>>> Sent: Thursday, December 15, 2011 6:39 PM > >>>>>> To: i-d-announce@ietf.org > >>>>>> Cc: idr@ietf.org > >>>>>> Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-01.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 : 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 > >>>> _______________________________________________ > >>>> Idr mailing list > >>>> Idr@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/idr From bhavani@cisco.com Mon Mar 5 11:25:56 2012 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 013DD21F88E5 for ; Mon, 5 Mar 2012 11:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 sW3Q4iGEpmOE for ; Mon, 5 Mar 2012 11:25:54 -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 A7EC921F88E1 for ; Mon, 5 Mar 2012 11:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bhavani@cisco.com; l=9942; q=dns/txt; s=iport; t=1330975554; x=1332185154; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=L4lFSgFI4CgD4MDc+VUg30oIvTu84Ff9aB8P3jQAMsA=; b=PWMbsDUZULYJL5bYUP8DUkpC2w7WgCqB/fJQB5Ie99JkRpT/O+aPZRsC jyGvI1E7oAPCGdlVO8j7mDLXnvVNSf879j1gpUmlCf9TMXpTdSw9qCcAw VQEPnngpy9zvYQSk+MYy4IRuVRXNNdekU6eXX03ViwdO0gIUcs7ZYYQ+q E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8HAH0SVU+rRDoG/2dsb2JhbABDgkVEsVyBB4F9AQEBBAEBAQ8BChBBChELGAkWDwkDAgECARUwEwYCAQEeh2QBC5k/AZ5yjTuDIgSIUIxuhWGKMYME X-IronPort-AV: E=Sophos;i="4.73,535,1325462400"; d="scan'208,217";a="34493527" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 05 Mar 2012 19:25:54 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q25JPs2J012872 for ; Mon, 5 Mar 2012 19:25:54 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 11:25:54 -0800 Received: from [10.21.96.183] ([10.21.96.183]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 11:25:54 -0800 Message-ID: <4F551341.1040207@cisco.com> Date: Mon, 05 Mar 2012 11:25:53 -0800 From: Bhavani Parise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: idr@ietf.org References: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> In-Reply-To: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> Content-Type: multipart/alternative; boundary="------------070702070902020707070700" X-OriginalArrivalTime: 05 Mar 2012 19:25:54.0115 (UTC) FILETIME=[C8525930:01CCFB05] Subject: Re: [Idr] WG adoption call 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 Mar 2012 19:25:56 -0000 This is a multi-part message in MIME format. --------------070702070902020707070700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Support Adoption regards, Bhavani On 3/5/2012 6:40 AM, Susan Hares wrote: > > This is to start a 2 week WG call for Adoption of > draft-ymbk-rfd-usable-02.txt. > > Please send support or comments to the mailing list. The WG call for > adoption will last from > > 3/5 to 3/19. We'll summarize this before the IDR meeting. > > Sue and John > > ---------------------------- > > Here's document info: > > http://datatracker.ietf.org/doc/draft-ymbk-rfd-usable/ > > Abstract: > > Route Flap Damping (RFD) was first proposed to reduce BGP churn in > > routers. Unfortunately, RFD was found to severely penalize sites for > > being well-connected because topological richness amplifies the > > number of update messages exchanged. Many operators have turned RFD > > off. Based on experimental measurement, this document recommends > > adjusting a few RFD algorithmic constants and limits, to reduce the > > high risks with RFD, with the result being damping a non-trivial > > amount of long term churn without penalizing well-behaved prefixes' > > normal convergence process. > > C. Pelsser, R. Bush (IIJ) > > K. Patel, P. Mohapatra (Cisco Systems) > > O. Maenel (Loughborough University) > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------070702070902020707070700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Support Adoption

regards,
Bhavani

On 3/5/2012 6:40 AM, Susan Hares wrote:

 

This is to start a 2 week WG call for Adoption of draft-ymbk-rfd-usable-02.txt.

 

Please send support or comments to the mailing list.  The WG call for adoption will last from

3/5 to 3/19.  We’ll summarize this before the IDR meeting.

 

Sue and John

 

----------------------------

 

 

Here’s document info:  

 

http://datatracker.ietf.org/doc/draft-ymbk-rfd-usable/

 

Abstract:

 

   Route Flap Damping (RFD) was first proposed to reduce BGP churn in

   routers.  Unfortunately, RFD was found to severely penalize sites for

   being well-connected because topological richness amplifies the

   number of update messages exchanged.  Many operators have turned RFD

   off.  Based on experimental measurement, this document recommends

   adjusting a few RFD algorithmic constants and limits, to reduce the

   high risks with RFD, with the result being damping a non-trivial

   amount of long term churn without penalizing well-behaved prefixes'

   normal convergence process.

 

C. Pelsser, R. Bush (IIJ)

K. Patel, P. Mohapatra (Cisco Systems)

O. Maenel (Loughborough University)

 

 

 

 

 

 

 

 



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

--------------070702070902020707070700-- From enkechen@cisco.com Mon Mar 5 11:37:06 2012 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 4A4FF21F893F for ; Mon, 5 Mar 2012 11:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 UPbAe3MyRfdT for ; Mon, 5 Mar 2012 11:37:05 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2377321F88C2 for ; Mon, 5 Mar 2012 11:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=8399; q=dns/txt; s=iport; t=1330976224; x=1332185824; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Esj9sYSjbdfykqgIdWRpEV2MKK2l0aDLleHqlZPh7vU=; b=L9lr6Lm3H78/PNiE2/nQGF0mVoRlNzrLTRttp/t9Kw0VdeDGK9WXvsSd qlfJbw+sEPjdBSUUAiA7UgDzujRSdFQ2vpCbAzF36gNSI9oLWSf9z7TlZ hVKpUeL7fOHA/lqNmgKqNAr+3RsK5S9miJTY+yMKvcwtVYa5PtBGJ01TQ Q=; X-IronPort-AV: E=Sophos;i="4.73,535,1325462400"; d="scan'208";a="32019218" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 05 Mar 2012 19:37:04 +0000 Received: from dhcp-171-71-139-175.cisco.com (dhcp-171-71-139-175.cisco.com [171.71.139.175]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q25Jb4b2020140; Mon, 5 Mar 2012 19:37:04 GMT Message-ID: <4F551719.9010208@cisco.com> Date: Mon, 05 Mar 2012 11:42:17 -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: "Simpson, Adam (Adam)" References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <4F4FF078.8050106@cisco.com> <4F512280.6020307@cisco.com> <4F512631.7070909@cisco.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 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 19:37:06 -0000 Adam, Consistent behavior is simpler operationally and more desirable. Whether a particular attribute is recognized or not can vary from router to router, and from release to release. I am not sure if you know the details of the well-publicized "3000 byte attribute" incident in which the attribute length was inconsistency with the total attribute length. Session resetting was the behavior and that was causing a huge problem in the field. -- Enke On 3/5/12 11:03 AM, Simpson, Adam (Adam) wrote: > I think there is a major difference between a 3000-byte optional transitive attribute that is new and unknown vs. a standardized attribute such as aggregator or extended community. A router receiving the optional transitive attribute for the first time has no idea whether 3000 bytes is a correct/valid length or not but it certainly knows that a 12-byte aggregator attribute is invalid. > >> -----Original Message----- >> From: Enke Chen [mailto:enkechen@cisco.com] >> Sent: Friday, March 02, 2012 2:58 PM >> To: Simpson, Adam (Adam) >> Cc: idr@ietf.org; Enke Chen >> Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt >> >> Well, the case of the "attr length of 3000 bytes" in the field states >> loudly for using "treat-as-withdraw". >> >> -- Enke >> >> On 3/2/12 11:47 AM, Simpson, Adam (Adam) wrote: >>> I agree, but I think there has been a general consensus in these >> discussions that we should keep the new/revised error handling >> procedures as simple as possible. Using treat as withdraw with length- >> related attribute errors is going to increase implementation complexity >> for what I suspect is very little net benefit. >>> -Adam >>> >>>> -----Original Message----- >>>> From: Enke Chen [mailto:enkechen@cisco.com] >>>> Sent: Friday, March 02, 2012 2:42 PM >>>> To: Simpson, Adam (Adam) >>>> Cc: idr@ietf.org; Enke Chen >>>> Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt >>>> >>>> Adam, >>>> >>>> There is a tradeoff - impact on one route vs all routes carried over >>>> the >>>> session in your example. That is why the draft states that the >> error >>>> conditions must be logged and analyzed. >>>> >>>> -- Enke >>>> >>>> On 3/2/12 11:25 AM, Simpson, Adam (Adam) wrote: >>>>> Enke, >>>>> >>>>> If this is the assumption then I think it should be stated >>>> explicitly. >>>>> But this still does not address the root of my concern. Suppose, >>>> hypothetically, some implementation builds a correct 8-byte >> aggregator >>>> attribute but reports that it is 12-bytes long and adds 12 bytes for >> it >>>> when computing the total path attributes length. If the treat-as- >>>> withdraw logic is enabled the receiver could incorrectly conclude >> that >>>> all the NLRI were upfront and miss that there was in fact a single >> 4- >>>> byte NLRI field at the end. The receiver misses it because it jumped >> to >>>> the end of the Update on the basis of trusting length fields that >> were >>>> consistent, but unfortunately consistently wrong. Wouldn't it have >> been >>>> safer to reset the session? >>>>> -Adam >>>>> >>>>>> -----Original Message----- >>>>>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf >>>> Of >>>>>> Enke Chen >>>>>> Sent: Thursday, March 01, 2012 4:56 PM >>>>>> To: idr@ietf.org >>>>>> Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling- >> 01.txt >>>>>> Hi, Adam: >>>>>> >>>>>> Not sure if we need extra text. The receiver must use the >> attribute >>>>>> length encoded in the message to continue parsing the message. >>>>>> >>>>>> -- Enke >>>>>> >>>>>> On 3/1/12 12:55 PM, Simpson, Adam (Adam) wrote: >>>>>>> Authors, >>>>>>> >>>>>>> Thank you for your work on this. >>>>>>> >>>>>>> One topic that I would like see discussed more thoroughly in a >> next >>>>>> version of the draft is how attribute-length errors should be >>>> handled >>>>>> and whether it's even appropriate for these types of errors to >> fall >>>>>> under the scope of the treat-as-withdrawn or attribute-discard >>>>>> approaches. >>>>>>> In section 5 of the current draft you give examples of a >> malformed >>>>>> community attribute as one with a length that is not a multiple of >> 4 >>>>>> bytes and a malformed aggregator attribute as one with a length >> that >>>> is >>>>>> not 6 or 8 bytes. The trouble I have with treating these types of >>>>>> errors using treat-as-withdrawn or attribute-discard is that you >> are >>>>>> forcing the receiver of a malformed Update message to guess what >> the >>>>>> sender actually encoded. If an aggregator attribute with a >> reported >>>>>> length of 7 bytes is received did the sender encode 6 bytes and >>>>>> incorrectly put 7 in the length field or did they put an extra >> byte >>>> of >>>>>> garbage in the attribute? >>>>>>> Fundamentally, I think it would be better to restrict treat-as- >>>>>> withdraw and attribute-discard to cases where the length of an >>>>>> attribute is not in question. If you disagree then I think you >> must >>>> add >>>>>> text to the draft that describes what an implementation should >>>> assume >>>>>> when it sees a length error such as the example discussed above - >>>> e.g. >>>>>> should it assume the "closest" valid value? There is probably a >>>> small >>>>>> chance of making a wrong "guess" that actually results in >> successful >>>>>> parsing of the message but if that chance is at all greater than 0 >>>> it >>>>>> seems we are taking treat-as-wthdrawn a step too far. >>>>>>> Adam >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On >> Behalf >>>>>> Of >>>>>>>> internet-drafts@ietf.org >>>>>>>> Sent: Thursday, December 15, 2011 6:39 PM >>>>>>>> To: i-d-announce@ietf.org >>>>>>>> Cc: idr@ietf.org >>>>>>>> Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-01.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 : 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 >>>>>> _______________________________________________ >>>>>> Idr mailing list >>>>>> Idr@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/idr From adam.simpson@alcatel-lucent.com Mon Mar 5 14:18:04 2012 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 D020B21E8035 for ; Mon, 5 Mar 2012 14:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 MVW1ynSg4XvL for ; Mon, 5 Mar 2012 14:18:03 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CF85A21E8034 for ; Mon, 5 Mar 2012 14:18:03 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q25MI2en027975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Mar 2012 16:18:02 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q25MI2WZ024470 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Mar 2012 16:18:02 -0600 Received: from USNAVSXCHMBSC1.ndc.alcatel-lucent.com ([135.3.39.146]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 5 Mar 2012 16:18:02 -0600 From: "Simpson, Adam (Adam)" To: Enke Chen Date: Mon, 5 Mar 2012 16:17:57 -0600 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt Thread-Index: Acz7HdQWsfKIgiZ8TkKC5QWA/oL1lA== Message-ID: <87649EB8-D62D-471E-80DB-603C009B057A@alcatel-lucent.com> References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <4F4FF078.8050106@cisco.com> <4F512280.6020307@cisco.com> <4F512631.7070909@cisco.com> <4F551719.9010208@cisco.com> In-Reply-To: <4F551719.9010208@cisco.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 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, 05 Mar 2012 22:18:05 -0000 Enke, Yes, I know the incident you are referring to. For treat as withdraw to hav= e successfully avoided session reset with this error the receiver would hav= e had to correctly guess whether the total path attribute length was correc= t or whether the individual attribute lengths were correct. Your earlier em= ail suggested that the individual lengths are the ones to trust and use to = skip to the end of the Update. I think that statement needs to appear in th= e draft and we need to keep in mind that this will not avoid session reset = whenever an individual attribute reports a length different than the number= of bytes encoded.=20 -Adam On Mar 5, 2012, at 2:37 PM, "Enke Chen" wrote: > Adam, >=20 > Consistent behavior is simpler operationally and more desirable. =20 > Whether a particular attribute is recognized or not can vary from router= =20 > to router, and from release to release. >=20 > I am not sure if you know the details of the well-publicized "3000 byte=20 > attribute" incident in which the attribute length was inconsistency with= =20 > the total attribute length. Session resetting was the behavior and=20 > that was causing a huge problem in the field. >=20 > -- Enke >=20 > On 3/5/12 11:03 AM, Simpson, Adam (Adam) wrote: >> I think there is a major difference between a 3000-byte optional transit= ive attribute that is new and unknown vs. a standardized attribute such as = aggregator or extended community. A router receiving the optional transitiv= e attribute for the first time has no idea whether 3000 bytes is a correct/= valid length or not but it certainly knows that a 12-byte aggregator attrib= ute is invalid. >>=20 >>> -----Original Message----- >>> From: Enke Chen [mailto:enkechen@cisco.com] >>> Sent: Friday, March 02, 2012 2:58 PM >>> To: Simpson, Adam (Adam) >>> Cc: idr@ietf.org; Enke Chen >>> Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt >>>=20 >>> Well, the case of the "attr length of 3000 bytes" in the field states >>> loudly for using "treat-as-withdraw". >>>=20 >>> -- Enke >>>=20 >>> On 3/2/12 11:47 AM, Simpson, Adam (Adam) wrote: >>>> I agree, but I think there has been a general consensus in these >>> discussions that we should keep the new/revised error handling >>> procedures as simple as possible. Using treat as withdraw with length- >>> related attribute errors is going to increase implementation complexity >>> for what I suspect is very little net benefit. >>>> -Adam >>>>=20 >>>>> -----Original Message----- >>>>> From: Enke Chen [mailto:enkechen@cisco.com] >>>>> Sent: Friday, March 02, 2012 2:42 PM >>>>> To: Simpson, Adam (Adam) >>>>> Cc: idr@ietf.org; Enke Chen >>>>> Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt >>>>>=20 >>>>> Adam, >>>>>=20 >>>>> There is a tradeoff - impact on one route vs all routes carried over >>>>> the >>>>> session in your example. That is why the draft states that the >>> error >>>>> conditions must be logged and analyzed. >>>>>=20 >>>>> -- Enke >>>>>=20 >>>>> On 3/2/12 11:25 AM, Simpson, Adam (Adam) wrote: >>>>>> Enke, >>>>>>=20 >>>>>> If this is the assumption then I think it should be stated >>>>> explicitly. >>>>>> But this still does not address the root of my concern. Suppose, >>>>> hypothetically, some implementation builds a correct 8-byte >>> aggregator >>>>> attribute but reports that it is 12-bytes long and adds 12 bytes for >>> it >>>>> when computing the total path attributes length. If the treat-as- >>>>> withdraw logic is enabled the receiver could incorrectly conclude >>> that >>>>> all the NLRI were upfront and miss that there was in fact a single >>> 4- >>>>> byte NLRI field at the end. The receiver misses it because it jumped >>> to >>>>> the end of the Update on the basis of trusting length fields that >>> were >>>>> consistent, but unfortunately consistently wrong. Wouldn't it have >>> been >>>>> safer to reset the session? >>>>>> -Adam >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf >>>>> Of >>>>>>> Enke Chen >>>>>>> Sent: Thursday, March 01, 2012 4:56 PM >>>>>>> To: idr@ietf.org >>>>>>> Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling- >>> 01.txt >>>>>>> Hi, Adam: >>>>>>>=20 >>>>>>> Not sure if we need extra text. The receiver must use the >>> attribute >>>>>>> length encoded in the message to continue parsing the message. >>>>>>>=20 >>>>>>> -- Enke >>>>>>>=20 >>>>>>> On 3/1/12 12:55 PM, Simpson, Adam (Adam) wrote: >>>>>>>> Authors, >>>>>>>>=20 >>>>>>>> Thank you for your work on this. >>>>>>>>=20 >>>>>>>> One topic that I would like see discussed more thoroughly in a >>> next >>>>>>> version of the draft is how attribute-length errors should be >>>>> handled >>>>>>> and whether it's even appropriate for these types of errors to >>> fall >>>>>>> under the scope of the treat-as-withdrawn or attribute-discard >>>>>>> approaches. >>>>>>>> In section 5 of the current draft you give examples of a >>> malformed >>>>>>> community attribute as one with a length that is not a multiple of >>> 4 >>>>>>> bytes and a malformed aggregator attribute as one with a length >>> that >>>>> is >>>>>>> not 6 or 8 bytes. The trouble I have with treating these types of >>>>>>> errors using treat-as-withdrawn or attribute-discard is that you >>> are >>>>>>> forcing the receiver of a malformed Update message to guess what >>> the >>>>>>> sender actually encoded. If an aggregator attribute with a >>> reported >>>>>>> length of 7 bytes is received did the sender encode 6 bytes and >>>>>>> incorrectly put 7 in the length field or did they put an extra >>> byte >>>>> of >>>>>>> garbage in the attribute? >>>>>>>> Fundamentally, I think it would be better to restrict treat-as- >>>>>>> withdraw and attribute-discard to cases where the length of an >>>>>>> attribute is not in question. If you disagree then I think you >>> must >>>>> add >>>>>>> text to the draft that describes what an implementation should >>>>> assume >>>>>>> when it sees a length error such as the example discussed above - >>>>> e.g. >>>>>>> should it assume the "closest" valid value? There is probably a >>>>> small >>>>>>> chance of making a wrong "guess" that actually results in >>> successful >>>>>>> parsing of the message but if that chance is at all greater than 0 >>>>> it >>>>>>> seems we are taking treat-as-wthdrawn a step too far. >>>>>>>> Adam >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On >>> Behalf >>>>>>> Of >>>>>>>>> internet-drafts@ietf.org >>>>>>>>> Sent: Thursday, December 15, 2011 6:39 PM >>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>> Cc: idr@ietf.org >>>>>>>>> Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt >>>>>>>>>=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 : 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. >>>>>>>>> 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 >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >=20 From kawamucho@mesh.ad.jp Mon Mar 5 17:19:27 2012 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 9D96C21E8082 for ; Mon, 5 Mar 2012 17:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 TixjgDATzwpK for ; Mon, 5 Mar 2012 17:19:27 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id F111321E807F for ; Mon, 5 Mar 2012 17:19:26 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.160]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q261JQZb006282 for ; Tue, 6 Mar 2012 10:19:26 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q261JQI12477 for idr@ietf.org; Tue, 6 Mar 2012 10:19:26 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id q261JPk8018379 for ; Tue, 6 Mar 2012 10:19:25 +0900 (JST) Received: from mail.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id q261JPhg013089 for ; Tue, 6 Mar 2012 10:19:25 +0900 Received: from [127.0.0.1] (osknet411.sys.biglobe.nec.co.jp [10.84.99.90]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id q261JP48014083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Mar 2012 10:19:25 +0900 Message-ID: <4F55661A.6060509@mesh.ad.jp> Date: Tue, 06 Mar 2012 10:19:22 +0900 From: Seiichi Kawamura User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: idr@ietf.org References: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> In-Reply-To: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBD9DD3611AF6BD04476AAE89" Subject: Re: [Idr] WG adoption call 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 Mar 2012 01:19:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBD9DD3611AF6BD04476AAE89 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable support. Seiichi (2012/03/05 23:40), Susan Hares wrote: > =20 >=20 > This is to start a 2 week WG call for Adoption of > draft-ymbk-rfd-usable-02.txt. >=20 > =20 >=20 > Please send support or comments to the mailing list. The WG call for > adoption will last from=20 >=20 > 3/5 to 3/19. We'll summarize this before the IDR meeting. >=20 > =20 >=20 > Sue and John >=20 > =20 >=20 > ---------------------------- >=20 > =20 >=20 > =20 >=20 > Here's document info: =20 >=20 > =20 >=20 > http://datatracker.ietf.org/doc/draft-ymbk-rfd-usable/ >=20 > =20 >=20 > Abstract:=20 >=20 > =20 >=20 > Route Flap Damping (RFD) was first proposed to reduce BGP churn in >=20 > routers. Unfortunately, RFD was found to severely penalize sites fo= r >=20 > being well-connected because topological richness amplifies the >=20 > number of update messages exchanged. Many operators have turned RFD= >=20 > off. Based on experimental measurement, this document recommends >=20 > adjusting a few RFD algorithmic constants and limits, to reduce the >=20 > high risks with RFD, with the result being damping a non-trivial >=20 > amount of long term churn without penalizing well-behaved prefixes' >=20 > normal convergence process. >=20 > =20 >=20 > C. Pelsser, R. Bush (IIJ) >=20 > K. Patel, P. Mohapatra (Cisco Systems) >=20 > O. Maenel (Loughborough University) >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------enigBD9DD3611AF6BD04476AAE89 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iEYEARECAAYFAk9VZhwACgkQcrhTYfxyMkJRdwCfZDTpjVw27tXDYFHe2GkFaM43 mGoAnRD8pnITuoj3GqS9iKNvNMucIec9 =R//b -----END PGP SIGNATURE----- --------------enigBD9DD3611AF6BD04476AAE89-- From asreekan@cisco.com Mon Mar 5 17:46:20 2012 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 BFEBA21F8771 for ; Mon, 5 Mar 2012 17:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 guunrqRHacqd for ; Mon, 5 Mar 2012 17:46:19 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id AF91321F876D for ; Mon, 5 Mar 2012 17:46:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=asreekan@cisco.com; l=9845; q=dns/txt; s=iport; t=1330998379; x=1332207979; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=R+VCRaFro7kmMOj7ceERYBYuAD9wGMUJqY1lGFWYJjw=; b=Lph2i9fRozQMekaytJe6fC9oRbFaJr7QaTpI2AJ513kQaWVCLtuaejRS 6+jB+gDKIMwrb3UAu1bK0hUZ1kunm3RSlho1UgJTFHqeLeO1tvVrAGMjN kq5Dk/lmkGAjU1wjgEiFN+wTpCZzrL/5yDdQX+gxKssssDThZ0EQAHtmq c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJNrVU+rRDoG/2dsb2JhbABDgkWyI4EHgX0BAQEEEgEJARADPhsCAQgOAwQBAQsGFwEGAUUJCAEBBAESCBqHZAELmV4BnnmPbGMEiFCdAIME X-IronPort-AV: E=Sophos;i="4.73,537,1325462400"; d="scan'208,217";a="32073010" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 06 Mar 2012 01:46:19 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q261kJpr008574; Tue, 6 Mar 2012 01:46:19 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 17:46:19 -0800 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_01CCFB3A.ECE941AE" Date: Mon, 5 Mar 2012 17:46:18 -0800 Message-ID: <96327EF53EF71A48806DE2DFC034D57F10C2FBA0@xmb-sjc-22b.amer.cisco.com> In-Reply-To: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] WG adoption call Thread-Index: Acz61uBlkDjofv9/R0W0yyxZy63EwAAY/VbQ References: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> From: "Arjun Sreekantiah (asreekan)" To: "Susan Hares" , X-OriginalArrivalTime: 06 Mar 2012 01:46:19.0475 (UTC) FILETIME=[ED4BE230:01CCFB3A] Subject: Re: [Idr] WG adoption call 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 Mar 2012 01:46:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFB3A.ECE941AE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support adoption. =20 -Arjun =20 From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, March 05, 2012 6:41 AM To: idr@ietf.org Subject: [Idr] WG adoption call =20 =20 This is to start a 2 week WG call for Adoption of draft-ymbk-rfd-usable-02.txt. =20 Please send support or comments to the mailing list. The WG call for adoption will last from=20 3/5 to 3/19. We'll summarize this before the IDR meeting. =20 Sue and John =20 ---------------------------- =20 =20 Here's document info: =20 =20 http://datatracker.ietf.org/doc/draft-ymbk-rfd-usable/ =20 Abstract:=20 =20 Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well-connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits, to reduce the high risks with RFD, with the result being damping a non-trivial amount of long term churn without penalizing well-behaved prefixes' normal convergence process. =20 C. Pelsser, R. Bush (IIJ) K. Patel, P. Mohapatra (Cisco Systems) O. Maenel (Loughborough University) =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01CCFB3A.ECE941AE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support = adoption.

 

-Arjun

 

From:= idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Susan Hares
Sent: Monday, March 05, 2012 6:41 AM
To: idr@ietf.org
Subject: [Idr] WG adoption call

 

 

This is to start a 2 week WG call for Adoption of draft-ymbk-rfd-usable-02.txt.

 

Please send support or comments to the mailing = list.  The WG call for adoption will last from

3/5 to 3/19.  We’ll summarize this = before the IDR meeting.

 

Sue and John

 

----------------------------

 

 

Here’s document info:  

 

http://da= tatracker.ietf.org/doc/draft-ymbk-rfd-usable/

 

Abstract:

 

   Route = Flap Damping (RFD) was first proposed to reduce BGP churn = in

   = routers.  Unfortunately, RFD was found to severely penalize sites = for

   being well-connected because topological richness amplifies = the

   number = of update messages exchanged.  Many operators have turned = RFD

   = off.  Based on experimental measurement, this document = recommends

   = adjusting a few RFD algorithmic constants and limits, to reduce = the

   high = risks with RFD, with the result being damping a non-trivial

   amount = of long term churn without penalizing well-behaved = prefixes'

   normal convergence process.

 

C. Pelsser, R. Bush = (IIJ)

K. Patel, P. = Mohapatra (Cisco Systems)

O. Maenel = (Loughborough University)

 

 

 

 

 

 

 

 

------_=_NextPart_001_01CCFB3A.ECE941AE-- From bvenkata@cisco.com Mon Mar 5 19:39:11 2012 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 B9C7921E8072 for ; Mon, 5 Mar 2012 19:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.895 X-Spam-Level: X-Spam-Status: No, score=-8.895 tagged_above=-999 required=5 tests=[AWL=1.703, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 3YULOe9ahAlN for ; Mon, 5 Mar 2012 19:39:10 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9D321E8045 for ; Mon, 5 Mar 2012 19:39:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9770; q=dns/txt; s=iport; t=1331005150; x=1332214750; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=ikQyVBgb/FouBEGnlHvajGA+j9YxbU9o5xO9s7LrBYY=; b=Csds29FMcMtN4GrGFTWORStz1ukBuzzjXXpzebWvpm+svz/9tklEKC9o 3tcfLLci61OiYVz7+2tHvtA67eeWqLqQSmuPgO2Vg+9FuSWWnW+J8GR6f lUxXSdAhSz1hhzanaqxV6EzIJ1cfhBMKfQP5J/fDLHA+cpy2KjkWYivmT w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoFAIiFVU+tJXHA/2dsb2JhbABDgkWgd4gbAYkPgQeBfQEBAQQSAQkBEAM+GwIBCA4DBAEBCwYXAQYBRQkIAQEEARIIGodlC5lwAZ8Bj2xjBIhQnQCDAg X-IronPort-AV: E=Sophos;i="4.73,537,1325462400"; d="scan'208,217";a="61006727" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 06 Mar 2012 03:39:10 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q263d9C2031712; Tue, 6 Mar 2012 03:39:09 GMT Received: from xmb-rcd-314.cisco.com ([72.163.63.29]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 21:39:09 -0600 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_01CCFB4A.B07ECE05" Date: Mon, 5 Mar 2012 21:39:08 -0600 Message-ID: In-Reply-To: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] WG adoption call Thread-Index: Acz61uBlkDjofv9/R0W0yyxZy63EwAAc8UEA References: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> From: "Balaji Pitta Venkatachalapathy (bvenkata)" To: "Susan Hares" , X-OriginalArrivalTime: 06 Mar 2012 03:39:09.0725 (UTC) FILETIME=[B0AE0CD0:01CCFB4A] Subject: Re: [Idr] WG adoption call 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 Mar 2012 03:39:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFB4A.B07ECE05 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support adoption. =20 Balaji =20 From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, March 05, 2012 6:41 AM To: idr@ietf.org Subject: [Idr] WG adoption call =20 =20 This is to start a 2 week WG call for Adoption of draft-ymbk-rfd-usable-02.txt. =20 Please send support or comments to the mailing list. The WG call for adoption will last from=20 3/5 to 3/19. We'll summarize this before the IDR meeting. =20 Sue and John =20 ---------------------------- =20 =20 Here's document info: =20 =20 http://datatracker.ietf.org/doc/draft-ymbk-rfd-usable/ =20 Abstract:=20 =20 Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well-connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits, to reduce the high risks with RFD, with the result being damping a non-trivial amount of long term churn without penalizing well-behaved prefixes' normal convergence process. =20 C. Pelsser, R. Bush (IIJ) K. Patel, P. Mohapatra (Cisco Systems) O. Maenel (Loughborough University) =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01CCFB4A.B07ECE05 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support adoption.

 

Balaji

 

From:= = idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Susan Hares
Sent: Monday, March 05, 2012 6:41 = AM
To: idr@ietf.org
Subject: [Idr] WG adoption = call

 

 

This is to = start a 2 week WG call for Adoption of = draft-ymbk-rfd-usable-02.txt.

 

Please send = support or comments to the mailing list.  The WG call for adoption = will last from

3/5 to 3/19.  = We’ll summarize this before the IDR meeting.

 

Sue and = John

 

----------------------------

 

 

Here’s = document info:  

 

http://da= tatracker.ietf.org/doc/draft-ymbk-rfd-usable/

 

Abstract: =

 

   Route = Flap Damping (RFD) was first proposed to reduce BGP churn = in

   = routers.  Unfortunately, RFD was found to severely penalize sites = for

   being = well-connected because topological richness amplifies = the

   number = of update messages exchanged.  Many operators have turned = RFD

   = off.  Based on experimental measurement, this document = recommends

   = adjusting a few RFD algorithmic constants and limits, to reduce = the

   high = risks with RFD, with the result being damping a = non-trivial

   amount = of long term churn without penalizing well-behaved = prefixes'

   normal = convergence process.

 

C. Pelsser, R. Bush = (IIJ)

K. Patel, P. = Mohapatra (Cisco Systems)

O. Maenel = (Loughborough University)

 

 

 

 

 

 

 

 

------_=_NextPart_001_01CCFB4A.B07ECE05-- From shtsuchi@cisco.com Mon Mar 5 21:24:11 2012 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 2984021F8616 for ; Mon, 5 Mar 2012 21:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.106 X-Spam-Level: X-Spam-Status: No, score=-8.106 tagged_above=-999 required=5 tests=[AWL=2.493, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 8FatKPcZPe4o for ; Mon, 5 Mar 2012 21:24: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 7ACF221E804E for ; Mon, 5 Mar 2012 21:24:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=1240; q=dns/txt; s=iport; t=1331011450; x=1332221050; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JZnHzMNlgFgV7n1HZ2//d/hNVwEahEeagBITFiLjMaU=; b=PAarbOTZsKc2fcMPksBtpTHWRdGkoHk6xNVUoT6Iuh57wQOWm4C/E7P4 RbvVEjj/QrycsQaQEF6LMLSyIe0GSoZfXYPfIOQeSVQanMTJysasbJVgl fqIdgQGOD2SPTmfb2LyHO8oyocPbL33mMzi7LJSSMAOtLcNBCts4sPbxX 4=; X-IronPort-AV: E=Sophos;i="4.73,538,1325462400"; d="scan'208";a="34727888" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 06 Mar 2012 05:24:10 +0000 Received: from [64.104.52.51] (dhcp-tmt-wirelessdata-64-104-52-51.cisco.com [64.104.52.51]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q265O96O027570; Tue, 6 Mar 2012 05:24:09 GMT Message-ID: <4F559F79.5080500@cisco.com> Date: Tue, 06 Mar 2012 14:24:09 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: shares@ndzh.com References: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> In-Reply-To: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] WG adoption call 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 Mar 2012 05:24:11 -0000 support adoption! (2012/03/05 23:40), Susan Hares wrote: > This is to start a 2 week WG call for Adoption of draft-ymbk-rfd-usable-02.txt. > > Please send support or comments to the mailing list. The WG call for adoption will last from > > 3/5 to 3/19. We$B!G(Bll summarize this before the IDR meeting. > > Sue and John > > ---------------------------- > > Here$B!G(Bs document info: > > http://datatracker.ietf.org/doc/draft-ymbk-rfd-usable/ > > Abstract: > > Route Flap Damping (RFD) was first proposed to reduce BGP churn in > > routers. Unfortunately, RFD was found to severely penalize sites for > > being well-connected because topological richness amplifies the > > number of update messages exchanged. Many operators have turned RFD > > off. Based on experimental measurement, this document recommends > > adjusting a few RFD algorithmic constants and limits, to reduce the > > high risks with RFD, with the result being damping a non-trivial > > amount of long term churn without penalizing well-behaved prefixes' > > normal convergence process. > > C. Pelsser, R. Bush (IIJ) > > K. Patel, P. Mohapatra (Cisco Systems) > > O. Maenel (Loughborough University) > From shane@castlepoint.net Mon Mar 5 22:29:43 2012 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 2CEAA21F849D for ; Mon, 5 Mar 2012 22:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=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 mfxtotBXPGVt for ; Mon, 5 Mar 2012 22:29:42 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 2F43C21F8458 for ; Mon, 5 Mar 2012 22:29:42 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 01249268063; Mon, 5 Mar 2012 23:29:41 -0700 (MST) Received: from mbpw.castlepoint.net (65-101-252-129.hlrn.qwest.net [65.101.252.129]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 05 Mar 2012 23:29:41 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.101.252.129; client-port=62586; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_DD7889B6-D855-48D1-BE9D-A7EE7C87D6FD" From: Shane Amante In-Reply-To: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> Date: Mon, 5 Mar 2012 23:29:26 -0700 Message-Id: References: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.1257) Cc: idr@ietf.org Subject: Re: [Idr] WG adoption call 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 Mar 2012 06:29:43 -0000 --Apple-Mail=_DD7889B6-D855-48D1-BE9D-A7EE7C87D6FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I support this draft becoming a WG draft. -shane On Mar 5, 2012, at 7:40 AM, Susan Hares wrote: > =20 > This is to start a 2 week WG call for Adoption of = draft-ymbk-rfd-usable-02.txt. > =20 > Please send support or comments to the mailing list. The WG call for = adoption will last from > 3/5 to 3/19. We=92ll summarize this before the IDR meeting. > =20 > Sue and John > =20 > ---------------------------- > =20 > =20 > Here=92s document info: =20 > =20 > http://datatracker.ietf.org/doc/draft-ymbk-rfd-usable/ > =20 > Abstract: > =20 > Route Flap Damping (RFD) was first proposed to reduce BGP churn in > routers. Unfortunately, RFD was found to severely penalize sites = for > being well-connected because topological richness amplifies the > number of update messages exchanged. Many operators have turned = RFD > off. Based on experimental measurement, this document recommends > adjusting a few RFD algorithmic constants and limits, to reduce the > high risks with RFD, with the result being damping a non-trivial > amount of long term churn without penalizing well-behaved prefixes' > normal convergence process. > =20 > C. Pelsser, R. Bush (IIJ) > K. Patel, P. Mohapatra (Cisco Systems) > O. Maenel (Loughborough University) > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_DD7889B6-D855-48D1-BE9D-A7EE7C87D6FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = support this draft becoming a WG = draft.

-shane


On= Mar 5, 2012, at 7:40 AM, Susan Hares wrote:

 
This is to start a 2 week WG call for Adoption of = draft-ymbk-rfd-usable-02.txt.
Please send support or comments to = the mailing list.  The WG call for adoption will last = from
3/5 to 3/19.  We=92ll summarize this before = the IDR meeting.
 
Sue and John
 
Here=92s document info:  
 
To: "'Susan Hares'" , References: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> In-Reply-To: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> Date: Tue, 6 Mar 2012 00:40:18 -0600 Message-ID: <000901ccfb63$ff760340$fe6209c0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CCFB31.B4DB9340" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz61uBlkDjofv9/R0W0yyxZy63EwAAjPdhA Content-Language: en-us Subject: Re: [Idr] WG adoption call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: luayjalil@gmail.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 06:40:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01CCFB31.B4DB9340 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Support adoption Luay From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, March 05, 2012 8:41 AM To: idr@ietf.org Subject: [Idr] WG adoption call This is to start a 2 week WG call for Adoption of draft-ymbk-rfd-usable-02.txt. Please send support or comments to the mailing list. The WG call for adoption will last from 3/5 to 3/19. We'll summarize this before the IDR meeting. Sue and John ---------------------------- Here's document info: http://datatracker.ietf.org/doc/draft-ymbk-rfd-usable/ Abstract: Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well-connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits, to reduce the high risks with RFD, with the result being damping a non-trivial amount of long term churn without penalizing well-behaved prefixes' normal convergence process. C. Pelsser, R. Bush (IIJ) K. Patel, P. Mohapatra (Cisco Systems) O. Maenel (Loughborough University) ------=_NextPart_000_000A_01CCFB31.B4DB9340 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support adoption

 

Luay

 

From:= = idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Susan Hares
Sent: Monday, March 05, 2012 8:41 = AM
To: idr@ietf.org
Subject: [Idr] WG adoption = call

 

 

This is to = start a 2 week WG call for Adoption of = draft-ymbk-rfd-usable-02.txt.

 

Please send = support or comments to the mailing list.  The WG call for adoption = will last from

3/5 to 3/19.  = We’ll summarize this before the IDR meeting.

 

Sue and = John

 

----------------------------

 

 

Here’s = document info:  

 

http://da= tatracker.ietf.org/doc/draft-ymbk-rfd-usable/

 

Abstract: =

 

   Route = Flap Damping (RFD) was first proposed to reduce BGP churn = in

   = routers.  Unfortunately, RFD was found to severely penalize sites = for

   being = well-connected because topological richness amplifies = the

   number = of update messages exchanged.  Many operators have turned = RFD

   = off.  Based on experimental measurement, this document = recommends

   = adjusting a few RFD algorithmic constants and limits, to reduce = the

   high = risks with RFD, with the result being damping a = non-trivial

   amount = of long term churn without penalizing well-behaved = prefixes'

   normal = convergence process.

 

C. Pelsser, R. Bush = (IIJ)

K. Patel, P. = Mohapatra (Cisco Systems)

O. Maenel = (Loughborough University)

 

 

 

 

 

 

 

 

------=_NextPart_000_000A_01CCFB31.B4DB9340-- From jeff.tantsura@ericsson.com Mon Mar 5 23:53:03 2012 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 5AB0A21F878B for ; Mon, 5 Mar 2012 23:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.112, 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 ukQs34Gpa+2P for ; Mon, 5 Mar 2012 23:53:02 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 33AAC21F878E for ; Mon, 5 Mar 2012 23:53:02 -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 q267r16U016030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Mar 2012 01:53:01 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.140]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 6 Mar 2012 02:53:00 -0500 From: Jeff Tantsura To: Susan Hares , "idr@ietf.org" Date: Tue, 6 Mar 2012 02:52:59 -0500 Thread-Topic: [Idr] WG adoption call Thread-Index: Acz61uBlkDjofv9/R0W0yyxZy63EwAAl0AjA Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF61911404A24@EUSAACMS0701.eamcs.ericsson.se> References: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> In-Reply-To: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.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_0ED867EB33AB2B45AAB470D5A64CDBF61911404A24EUSAACMS0701e_" MIME-Version: 1.0 Subject: Re: [Idr] WG adoption call 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 Mar 2012 07:53:03 -0000 --_000_0ED867EB33AB2B45AAB470D5A64CDBF61911404A24EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support Regards, Jeff From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan= Hares Sent: Monday, March 05, 2012 6:41 AM To: idr@ietf.org Subject: [Idr] WG adoption call This is to start a 2 week WG call for Adoption of draft-ymbk-rfd-usable-02.= txt. Please send support or comments to the mailing list. The WG call for adopt= ion will last from 3/5 to 3/19. We'll summarize this before the IDR meeting. Sue and John ---------------------------- Here's document info: http://datatracker.ietf.org/doc/draft-ymbk-rfd-usable/ Abstract: Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well-connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits, to reduce the high risks with RFD, with the result being damping a non-trivial amount of long term churn without penalizing well-behaved prefixes' normal convergence process. C. Pelsser, R. Bush (IIJ) K. Patel, P. Mohapatra (Cisco Systems) O. Maenel (Loughborough University) --_000_0ED867EB33AB2B45AAB470D5A64CDBF61911404A24EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/support

 

Regards,

Jeff

 

From: id= r-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Monday, March 05, 2012 6:41 AM
To: idr@ietf= .org
Subject: [Idr] WG adoption call

<= /div>

 

&n= bsp;

This is to start a 2 week WG call for Ad= option of draft-ymbk-rfd-usable-02.txt.

=  

Please send support or comments t= o the mailing list.  The WG call for adoption will last from

3/5 to 3/19.  We’ll summarize this be= fore the IDR meeting.

 <= /p>

Sue and John

 

----------------------------

 

=  

Here’s document info:  

 

<= a href=3D"http://datatracker.ietf.org/doc/draft-ymbk-rfd-usable/">http://da= tatracker.ietf.org/doc/draft-ymbk-rfd-usable/

 

Abstract:

 

   Route Flap Damping (RFD) was first propose= d to reduce BGP churn in

   routers.  Unfortunately, RFD was fo= und to severely penalize sites for

   being well-connected because t= opological richness amplifies the

   number of update messages excha= nged.  Many operators have turned RFD

   off.  Based on ex= perimental measurement, this document recommends

   adjusting a fe= w RFD algorithmic constants and limits, to reduce the

=

   high risks = with RFD, with the result being damping a non-trivial

=

   amount of l= ong term churn without penalizing well-behaved prefixes'<= /p>

   normal c= onvergence process.

 

C. Pelsser, R. Bush (IIJ)

K. Patel, P. Mohapatra (Cisco S= ystems)

O. Maenel (Loughborough University)

 

 

 

 

 

 

 =

 

= --_000_0ED867EB33AB2B45AAB470D5A64CDBF61911404A24EUSAACMS0701e_-- From shsethur@cisco.com Tue Mar 6 01:21:45 2012 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 B084B21F86C2 for ; Tue, 6 Mar 2012 01:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 y45IiTKRlzNP for ; Tue, 6 Mar 2012 01:21:44 -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 BF07A21F87D3 for ; Tue, 6 Mar 2012 01:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shsethur@cisco.com; l=1503; q=dns/txt; s=iport; t=1331025696; x=1332235296; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=98LORkirqsjj1fJ+TYyyIrGngKTV7j/mrTB+M0kMGTU=; b=bo9jcrStPnQUsyrMBUbMGadu35BC56+OXzloXHeL+QdWj6VOey3ANOUd DQ/eFVjlDTwklMduaEwFTxmgfYxvy4/UMy8lC7nKSmjQPRCIdupYogKaK yicdvOVdaszze/wzCopZ1V933TXc5pCBv3GCaidkwkGoGxk6Psx4R9OJh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAE/WVU+rRDoJ/2dsb2JhbABDtHGBB4F9AQEBBBIBChMKNBcEAgEIDgMEAQELBhcBBgFFCQgBAQQBEggah2QBC5o0AZ8Mj3tjBIhQnQSDBA X-IronPort-AV: E=Sophos;i="4.73,539,1325462400"; d="scan'208";a="34621678" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 06 Mar 2012 09:21:34 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q269LY0b015891; Tue, 6 Mar 2012 09:21:34 GMT Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 01:21:34 -0800 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, 6 Mar 2012 01:21:33 -0800 Message-ID: In-Reply-To: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] WG adoption call Thread-Index: Acz61uBlkDjofv9/R0W0yyxZy63EwAAo6EPg References: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> From: "Shyam Sethuram (shsethur)" To: "Susan Hares" , X-OriginalArrivalTime: 06 Mar 2012 09:21:34.0686 (UTC) FILETIME=[866E4FE0:01CCFB7A] Subject: Re: [Idr] WG adoption call 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 Mar 2012 09:21:45 -0000 Support. thanks--shyam >-----Original Message----- >From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares >Sent: Monday, March 05, 2012 6:41 AM >To: idr@ietf.org >Subject: [Idr] WG adoption call > > > >This is to start a 2 week WG call for Adoption of draft-ymbk-rfd-usable-02.txt. > > > >Please send support or comments to the mailing list. The WG call for adoption will last from > >3/5 to 3/19. We'll summarize this before the IDR meeting. > > > >Sue and John > > > >---------------------------- > > > > > >Here's document info: > > > >http://datatracker.ietf.org/doc/draft-ymbk-rfd-usable/ > > > >Abstract: > > > > Route Flap Damping (RFD) was first proposed to reduce BGP churn in > > routers. Unfortunately, RFD was found to severely penalize sites for > > being well-connected because topological richness amplifies the > > number of update messages exchanged. Many operators have turned RFD > > off. Based on experimental measurement, this document recommends > > adjusting a few RFD algorithmic constants and limits, to reduce the > > high risks with RFD, with the result being damping a non-trivial > > amount of long term churn without penalizing well-behaved prefixes' > > normal convergence process. > > > >C. Pelsser, R. Bush (IIJ) > >K. Patel, P. Mohapatra (Cisco Systems) > >O. Maenel (Loughborough University) > > > > > > > > > > > > > > > > From brian.peter.dickson@gmail.com Wed Mar 7 07:53:58 2012 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 30F3A21F86DA for ; Wed, 7 Mar 2012 07:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3vok3WKjV7vC for ; Wed, 7 Mar 2012 07:53:57 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA1821F86D0 for ; Wed, 7 Mar 2012 07:53:57 -0800 (PST) Received: by werb10 with SMTP id b10so5066653wer.31 for ; Wed, 07 Mar 2012 07:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/RPuIcqfH++aG6rEnpbe622/kQIG7/sphPIWVmL4nRg=; b=tAKr11TfH4rulC11UAl46e4p4bgmCSqo2f95220TpU6CdgKU9+RgebQTzgXlqiiJ6+ B1tTi05gIOWVzuoV5vH4CcLMg0vGPgZ8+HawzPlSJ3GRntb+uudeVoIN8PWgADDTT4Y7 N0qbeVf4oRmMGQo0b2LXfluO73gxMoTy1+v+v5nP/EZgeU9AY0HJRZQnDjy3RRERUSnL rb/0pgRjLKCl96DR+663SsWLq4SPHhM2FK2gfhX9rMQMx27tzSTrtIVpM8Z/wTR8QnHu NqoAGGPEb5iopCuS8aKeMCoUCQUGr1kCH3+CnesNMmAlgazr9BpKWKaQOnvqFEWFVXC3 bsoA== MIME-Version: 1.0 Received: by 10.180.100.33 with SMTP id ev1mr5976132wib.3.1331135636395; Wed, 07 Mar 2012 07:53:56 -0800 (PST) Received: by 10.223.69.3 with HTTP; Wed, 7 Mar 2012 07:53:56 -0800 (PST) In-Reply-To: <000001cce86f$1d18a4f0$5749eed0$@ndzh.com> References: <000001cce86f$1d18a4f0$5749eed0$@ndzh.com> Date: Wed, 7 Mar 2012 10:53:56 -0500 Message-ID: From: Brian Dickson To: Susan Hares Content-Type: multipart/alternative; boundary=f46d04440266c157f804baa92ab1 Cc: idr@ietf.org Subject: Re: [Idr] WGLCon draft-ietf-idr-as0 (second send) 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 Mar 2012 15:53:58 -0000 --f46d04440266c157f804baa92ab1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Support. (I supported this from -00 revision, and that support has not changed. Just thought I'd clarify that.) The changes have clarified things quite well, and I think it needs no more changes. Brian Dickson On Fri, Feb 10, 2012 at 10:41 PM, Susan Hares wrote: > ** ** > > This is to start a 2 week WGLC on:**** > > ** ** > > Codification of AS 0 processing.**** > > draft-ietf-idr-as0-03**** > > ** ** > > WGLC runs from 2/11/2012 =96 2/25/2012.**** > > ** ** > > Please send comments to list. **** > > ** ** > > Sue and John **** > > ------------------------**** > > ** ** > > ** ** > > http://datatracker.ietf.org/doc/draft-ietf-idr-as0/**** > > ** ** > > This document proscribes the use of AS 0 in BGP OPEN and AS_PATH /**** > > AS4_PATH BGP attribute.**** > > ** ** > > ** ** > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --f46d04440266c157f804baa92ab1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Support.

(I supported this from -00 revision, and that support has n= ot changed. Just thought I'd clarify that.)

The changes have cla= rified things quite well, and I think it needs no more changes.

Bria= n Dickson

On Fri, Feb 10, 2012 at 10:41 PM, Susan Hare= s <shares@ndzh.com<= /a>> wrote:

_______________= ________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr


--f46d04440266c157f804baa92ab1-- From ietf@cdl.asgaard.org Wed Mar 7 13:21:51 2012 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 9D8B011E809B for ; Wed, 7 Mar 2012 13:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 BFWFp8zL8KkQ for ; Wed, 7 Mar 2012 13:21:51 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0C74311E809A for ; Wed, 7 Mar 2012 13:21:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 32A60C6F2A7 for ; Wed, 7 Mar 2012 21:21:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnwp8pc8Uv-o for ; Wed, 7 Mar 2012 21:21:48 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id AC400C6F299 for ; Wed, 7 Mar 2012 21:21:48 +0000 (UTC) From: Christopher LILJENSTOLPE Content-Type: multipart/signed; boundary="Apple-Mail=_1001295F-7127-4487-BC64-1EA711F39E1B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Wed, 7 Mar 2012 13:21:44 -0800 Message-Id: <7F59252A-7F68-4891-B48F-4B0D4E56EB7E@cdl.asgaard.org> To: idr@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [Idr] draft-ietf-idr-as0-03 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 Mar 2012 21:21:51 -0000 --Apple-Mail=_1001295F-7127-4487-BC64-1EA711F39E1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 Chris -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf Check my calendar availability: https://tungle.me/cdl --Apple-Mail=_1001295F-7127-4487-BC64-1EA711F39E1B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBAgAGBQJPV9FqAAoJEGmx2Mt/+Iw/14UH+QG/kQ08bz9dZUEITbdPfMx4 fm5Fhp/vrHRx2WLcRd+1/L5hyOtA7UCHweeP/p3LsSUUs/f/k7vP989Yw7fkaMjf qLnKR+ZD4iDdQ97t213sX+H7SaiROGaPUQgH/Eoka2swUPyJDhsNCc3wBjEOs1ts OGHNXOEqTUUcJqIjln10MW3zzAipj4fH1cPnyYiEwxNF09hMa5ehfqt/c2y37EEm vhYXUvKp4oTPpPYAndEpSK3dkmBESM3ai/jG/w4kD3Z84ze72TByGuN59BFtZVLs ed4qcNwSMv5nHi6YlnFnItv8l4+/n2aaQUBHzOJvnW+9GqEReR/ID11Pj7/AH9w= =w0b4 -----END PGP SIGNATURE----- --Apple-Mail=_1001295F-7127-4487-BC64-1EA711F39E1B-- From kotikalapudi.sriram@nist.gov Wed Mar 7 16:10:32 2012 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 ADBC721F8557 for ; Wed, 7 Mar 2012 16:10:32 -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 LhAFxooyuc6K for ; Wed, 7 Mar 2012 16:10:32 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id CA82621F8555 for ; Wed, 7 Mar 2012 16:10:31 -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.355.2; Wed, 7 Mar 2012 19:10:07 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 7 Mar 2012 19:07:18 -0500 From: "Sriram, Kotikalapudi" To: "idr@ietf.org" Date: Wed, 7 Mar 2012 19:07:17 -0500 Thread-Topic: [Idr] WGLCon draft-ietf-idr-as0 (second send) Thread-Index: AQHM/L7s1vCPRjXFQkGV7+vt2JB8Ww== 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] WGLCon draft-ietf-idr-as0 (second send) 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 Mar 2012 00:10:32 -0000 Support. The following comments are meant to hopefully help the authors improve clarity in a few places in the document. Draft says: [I-D.ietf-sidr-iana-objects] specifies that AS number zero in a ROA is used to mark an NLRI which is to be marked as Invalid. Consider changing the above sentence and elaborate as follows: [I-D.ietf-sidr-iana-objects] specifies that AS number zero in a ROA is used to mark an NLRI which is to be marked as Invalid, if routed. That is, by creating the ROA with AS number 0, the owner of the NLRI is declaring that the NLRI must not be originated by any AS. Draft says: As at least two implementations discard routes containing AS 0 (and to allow approaches such as the above) this document codifies this behavior. Consider changing the above sentence as follows for clarity: At least two implementations discard routes containing AS 0. To allow approaches such as the above, this document codifies this behavior. Typo: May be use to identify non-routed networks" ([IANA.AS_Numbers]). s/use/used/ Sriram From christopher.morrow@gmail.com Wed Mar 7 20:41:08 2012 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 AFE0721F856D for ; Wed, 7 Mar 2012 20:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 TLTBOCxjiAAp for ; Wed, 7 Mar 2012 20:41:07 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D101B21F856C for ; Wed, 7 Mar 2012 20:41:07 -0800 (PST) Received: by obbta4 with SMTP id ta4so161997obb.31 for ; Wed, 07 Mar 2012 20:41:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pu0hC8zFgHp2s7ReM1YZfFRHckvc67WiRIMG1vmX4Jg=; b=HB2pfeQWweu/WwjNABMrDj6EFp3YX48zsh3ZUXIlIT0UW0+A4QqCHcTCTMK9YwEb3m J2BI8P42wfM3rnOD9YDnRA0pQsealoLMKujtOAyyVq7vaLJleyUddgMFRKKIKHKFBmPZ EJeJl2IErPYNALfHX8PFei89oL8ItM3pYgR0YpXkHjJQ6jXVE6WrfhOwQK1kPF3XzA3B psxrtHYpZBQ4OD+hvg3PqUjJhUyFXBLgZLfJRs6dpxbFuAliLTOyaq0/+mj+wqHBZ13I MM2r98AawZVQM+LapA0gNVnOOMPMO+PYI4FfBPjRp1WNy3Zh8HrZIgxqRh/a0fWkoYkF W9Pw== MIME-Version: 1.0 Received: by 10.60.4.106 with SMTP id j10mr1865795oej.47.1331181667536; Wed, 07 Mar 2012 20:41:07 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.182.139.106 with HTTP; Wed, 7 Mar 2012 20:41:07 -0800 (PST) In-Reply-To: <7F59252A-7F68-4891-B48F-4B0D4E56EB7E@cdl.asgaard.org> References: <7F59252A-7F68-4891-B48F-4B0D4E56EB7E@cdl.asgaard.org> Date: Wed, 7 Mar 2012 23:41:07 -0500 X-Google-Sender-Auth: T7d3tibQBCg_bBIRwJ2L3yEojQ0 Message-ID: From: Christopher Morrow To: Christopher LILJENSTOLPE Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-as0-03 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 Mar 2012 04:41:08 -0000 On Wed, Mar 7, 2012 at 4:21 PM, Christopher LILJENSTOLPE wrote: > +1 thanks for the reminder... This still looks like a good thing to me as well. -chris From randy@psg.com Wed Mar 7 22:33:59 2012 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 DFFD621F868A for ; Wed, 7 Mar 2012 22:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 MVQJGsS5AjCZ for ; Wed, 7 Mar 2012 22:33:59 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA2121F866E for ; Wed, 7 Mar 2012 22:33:59 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S5WvE-00006V-Tj; Thu, 08 Mar 2012 06:33:57 +0000 Date: Thu, 08 Mar 2012 15:33:55 +0900 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org" Subject: Re: [Idr] WGLCon draft-ietf-idr-as0 (second send) 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 Mar 2012 06:34:00 -0000 > Draft says: > [I-D.ietf-sidr-iana-objects] specifies that AS number zero in a ROA > is used to mark an NLRI which is to be marked as Invalid. > > Consider changing the above sentence and elaborate as follows: > > [I-D.ietf-sidr-iana-objects] specifies that AS number zero in a ROA > is used to mark an NLRI which is to be marked as Invalid, if routed. > That is, by creating the ROA with AS number 0, the owner of the > NLRI is declaring that the NLRI must not be originated by any AS. no. that is up to local policy in the router. and do note that if there are two roas 666.42.7.11 AS 0 666.42.7.11 AS 42 and an announcement comes in for 666.42.7.11 _42$ it will be marked as valid randy From kotikalapudi.sriram@nist.gov Thu Mar 8 07:09:29 2012 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 782D521F8736 for ; Thu, 8 Mar 2012 07:09:29 -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 DW5bnyv0CCuS for ; Thu, 8 Mar 2012 07:09:28 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF8D21F8725 for ; Thu, 8 Mar 2012 07:09:27 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 8 Mar 2012 10:09:18 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 8 Mar 2012 10:06:19 -0500 From: "Sriram, Kotikalapudi" To: Randy Bush Date: Thu, 8 Mar 2012 10:09:25 -0500 Thread-Topic: [Idr] WGLCon draft-ietf-idr-as0 (second send) Thread-Index: Acz89QSDOqeMHDoEQKy9a1QQ4weYwQARj55Q Message-ID: References: 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="us-ascii" MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] WGLCon draft-ietf-idr-as0 (second send) 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 Mar 2012 15:09:29 -0000 > >no. that is up to local policy in the router. > >and do note that if there are two roas > 666.42.7.11 AS 0 > 666.42.7.11 AS 42 >and an announcement comes in for > 666.42.7.11 _42$ >it will be marked as valid Understood your point, but still the draft says: "[I-D.ietf-sidr-iana-objects] specifies that AS number zero in a ROA is used to mark an NLRI which is to be marked as Invalid." The sentence says "... an NLRI which is to be marked as _Invalid_" but your example above contradicts that as it shows that the NLRI could be marked as _Valid_ (if there was another ROA). Sriram From internet-drafts@ietf.org Sun Mar 11 01:36:35 2012 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 B7A9A21F850B; Sun, 11 Mar 2012 01:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 ODImgNL37ewD; Sun, 11 Mar 2012 01:36:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3682321F852C; Sun, 11 Mar 2012 01:36:35 -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: 4.00 Message-ID: <20120311093635.29616.91711.idtracker@ietfa.amsl.com> Date: Sun, 11 Mar 2012 01:36:35 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as4octet-extcomm-generic-subtype-05.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: Sun, 11 Mar 2012 09:36:35 -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 : Generic Subtype for BGP Four-octet AS specific extended = community Author(s) : Dhananjaya Rao Pradosh Mohapatra Jeffrey Haas Filename : draft-ietf-idr-as4octet-extcomm-generic-subtype-05.txt Pages : 6 Date : 2012-03-11 Maintaining the current best practices with communities, ISPs and enterprises that are assigned a 4-octet AS number may want the BGP UPDATE messages they receive from their customers or peers to include a 4-octet AS specific BGP extended community. This document defines a new sub-type within the four-octet AS specific extended community to facilitate this practice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4octet-extcomm-generic= -subtype-05.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-as4octet-extcomm-generic-= subtype-05.txt From jhaas@slice.pfrc.org Sun Mar 11 12:22:31 2012 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 047B521F86EA for ; Sun, 11 Mar 2012 12:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.869 X-Spam-Level: X-Spam-Status: No, score=-101.869 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_25=0.6, 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 lYlECRDcmgUH for ; Sun, 11 Mar 2012 12:22:30 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8833721F86E5 for ; Sun, 11 Mar 2012 12:22:30 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 302331703E2; Sun, 11 Mar 2012 15:22:30 -0400 (EDT) Date: Sun, 11 Mar 2012 15:22:30 -0400 From: Jeffrey Haas To: bruno.decraene@orange.com Message-ID: <20120311192230.GC30627@slice> References: <24907_1329908761_4F44CC19_24907_5723_2_53C29892C857584299CBF5D05346208A024146@PEXCVZYM11.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24907_1329908761_4F44CC19_24907_5723_2_53C29892C857584299CBF5D05346208A024146@PEXCVZYM11.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-reserved-extended-communities 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: Sun, 11 Mar 2012 19:22:31 -0000 Bruno, On Wed, Feb 22, 2012 at 11:05:59AM +0000, bruno.decraene@orange.com wrote: > As a reminder, draft-ietf-idr-reserved-extended-communities currently proposes to use the AS number O to get a global space of "generic four-octet AS specific" extended community (as defined in draft-ietf-idr-as4octet-extcomm-generic-subtype) in order to be able to get IANA assigned extended communities values from. (i.e. the equivalent of formerly "well known" RFC 1997 communities). > > Following some discussion on draft-ietf-idr-as0, another option is to use AS number 0x0000FFFF instead of AS 0. This seems also more in line with RFC 1997 which use the same AS number (0xFFFF) for the same purpose (IANA assigned communities). I think using AS 0.65535 (as-dot notation) is probably reasonable given the semantics you are looking for. After spending some additional time thinking about your draft, I believe that the primary desired behavior is to add the ability to create non-transitive well-known communities. Since transitive well-known communities are easiest (and most backward-compatible at the moment) to express as RFC 1997 4-byte communities I would make the following suggestion: - Recommend that IANA set aside the 0.65535 4-byte AS name space using draft-ietf-idr-as4octet-extcomm-generic-subtype. - Recommend that only non-transitive types are registered in the above registry. - Recommend that when a transitive well-known community is registered in the IANA RFC 1997 community that, when appropriate, a non-transitive version of the community be made similarly available in the new registry. The above captures the spirit of backward compatibility in draft-ietf-idr-as4octet-extcomm-generic-subtype: : Therefore, for backward compatibility with existing deployments and : to avoid inconsistencies between standard communities and 4-octet : extended communities, Autonomous Systems that use 2-octet Autonomous : System numbers SHOULD use standard 2-octet communities as defined in : RFC1997 rather than the 4-octet AS specific extended community as : defined in this document. -- Jeff (not officially speaking for the other as4octet authors, but probably capturing the spirit of our discussion) From jhaas@slice.pfrc.org Sun Mar 11 13:05:17 2012 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 1D85821F8667 for ; Sun, 11 Mar 2012 13:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.163 X-Spam-Level: X-Spam-Status: No, score=-102.163 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 WjI8jOMfxRUQ for ; Sun, 11 Mar 2012 13:05:16 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1B05421F85C0 for ; Sun, 11 Mar 2012 13:05:16 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id DC7481703DF; Sun, 11 Mar 2012 16:05:15 -0400 (EDT) Date: Sun, 11 Mar 2012 16:05:15 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20120311200515.GE30627@slice> References: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: idr@ietf.org Subject: Re: [Idr] WG adoption call 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: Sun, 11 Mar 2012 20:05:17 -0000 On Mon, Mar 05, 2012 at 09:40:31AM -0500, Susan Hares wrote: > This is to start a 2 week WG call for Adoption of > draft-ymbk-rfd-usable-02.txt. I'd like to support adoption of this draft as a WG document. Comments to the authors: - Do you really want this on standards track? I think informational would be a lower bar to publication as an RFC. - The Pelsser document is the foundation of this work. While psg.com is pretty long-lived, would the authors consider publication of the documentation elsewhere so the URL is likely to be even more survivable. Perhaps as an informational RFC on its own? - The metrics noted in Table 1 are, effectively, vendor particular. One of (many) ugly details that has dogged RFC 2439 is that its metrics are not what is present in most implementations. I think this presents a minor issue with respect to normative references. It's also one of the reasons I recommend informational. -- Jeff (who wishes someone would take some of their copious spare time and issue an 2439-bis that reflects reality someone better.) From randy@psg.com Mon Mar 12 05:28:20 2012 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 E790C21F876C for ; Mon, 12 Mar 2012 05:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 EmprDrmC70hh for ; Mon, 12 Mar 2012 05:28:20 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5962C21F876A for ; Mon, 12 Mar 2012 05:28:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S74ML-000ENl-QY; Mon, 12 Mar 2012 12:28:17 +0000 Date: Mon, 12 Mar 2012 21:28:16 +0900 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20120311200515.GE30627@slice> References: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> <20120311200515.GE30627@slice> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org, Susan Hares Subject: Re: [Idr] WG adoption call 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 Mar 2012 12:28:21 -0000 > - Do you really want this on standards track? I think informational > would be a lower bar to publication as an RFC. it modifies parameters in a standards track rfc > - The Pelsser document is the foundation of this work. While psg.com > is pretty long-lived, would the authors consider publication of the > documentation elsewhere so the URL is likely to be even more > survivable. it was a paper in PAM. we may be able to fix the cite presuming PAM papers are free to download. > - The metrics noted in Table 1 are, effectively, vendor particular. > One of (many) ugly details that has dogged RFC 2439 is that its > metrics are not what is present in most implementations. I think > this presents a minor issue with respect to normative references. > It's also one of the reasons I recommend informational. there is spare horizontal space for a couple more vendors if you think that would enhance things. > -- Jeff (who wishes someone would take some of their copious spare > time and issue an 2439-bis that reflects reality someone better.) i admire your ambition :) randy From randy@psg.com Mon Mar 12 05:33:11 2012 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 3B28C21F8767 for ; Mon, 12 Mar 2012 05:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 TpLDze6c9NEy for ; Mon, 12 Mar 2012 05:33:10 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id AF58021F8764 for ; Mon, 12 Mar 2012 05:33:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S74R4-000EOl-4T; Mon, 12 Mar 2012 12:33:10 +0000 Date: Mon, 12 Mar 2012 21:33:08 +0900 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: References: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> <20120311200515.GE30627@slice> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org, Susan Hares Subject: Re: [Idr] WG adoption call 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 Mar 2012 12:33:11 -0000 >> - The Pelsser document is the foundation of this work. While psg.com >> is pretty long-lived, would the authors consider publication of the >> documentation elsewhere so the URL is likely to be even more >> survivable. http://pam2011.gatech.edu/papers/pam2011--Pelsser.pdf randy From jhaas@slice.pfrc.org Mon Mar 12 06:40:15 2012 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 6828C21F8776 for ; Mon, 12 Mar 2012 06:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.162 X-Spam-Level: X-Spam-Status: No, score=-102.162 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 TiXfyeC7OChZ for ; Mon, 12 Mar 2012 06:40:14 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A22FB21F8772 for ; Mon, 12 Mar 2012 06:40:14 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1E2DC1703CF; Mon, 12 Mar 2012 09:40:14 -0400 (EDT) Date: Mon, 12 Mar 2012 09:40:14 -0400 From: Jeffrey Haas To: Randy Bush Message-ID: <20120312134014.GB25264@slice> References: <005401ccfadd$f97f07b0$ec7d1710$@ndzh.com> <20120311200515.GE30627@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: idr@ietf.org, Susan Hares Subject: Re: [Idr] WG adoption call 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 Mar 2012 13:40:15 -0000 On Mon, Mar 12, 2012 at 09:28:16PM +0900, Randy Bush wrote: > > - Do you really want this on standards track? I think informational > > would be a lower bar to publication as an RFC. > > it modifies parameters in a standards track rfc > [...] >From Table 1, where do you trace back either vendor's numbers to RFC 2439? The 15 minute half-life, perhaps. That mostly my point. While a piece of the general suppression algorithm is implemented from the RFC by multiple vendors, the exact algorithm, floating point metrics, etc. are not. (Never mind tracking of path data.) You're thus not really making recommendations on parameters in the RFC. You're making recommendations of vendor knobs on implementations that are vaguely tied to the RFC. > > - The metrics noted in Table 1 are, effectively, vendor particular. > > One of (many) ugly details that has dogged RFC 2439 is that its > > metrics are not what is present in most implementations. I think > > this presents a minor issue with respect to normative references. > > It's also one of the reasons I recommend informational. > > there is spare horizontal space for a couple more vendors if you think > that would enhance things. I think getting some more data points would be good, but the general idea is there. -- Jeff From internet-drafts@ietf.org Mon Mar 12 10:00:48 2012 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 19DD621F8863; Mon, 12 Mar 2012 10:00:48 -0700 (PDT) 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 ici9AOuhZp3n; Mon, 12 Mar 2012 10:00:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F63521F8846; Mon, 12 Mar 2012 10:00:47 -0700 (PDT) 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: 4.00 Message-ID: <20120312170043.2012.96377.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 10:00:43 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp4-mibv2-13.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 Mar 2012 17:00:48 -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 : Definitions of Managed Objects for the Fourth Version of= Border Gateway Protocol (BGP-4), Second Version Author(s) : Jeffrey Haas Filename : draft-ietf-idr-bgp4-mibv2-13.txt Pages : 45 Date : 2012-03-12 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the Border Gateway Protocol, Version 4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-13.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-bgp4-mibv2-13.txt From jgs@juniper.net Tue Mar 13 12:08:55 2012 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 9456621F860F for ; Tue, 13 Mar 2012 12:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 F8s9DPcY8FEg for ; Tue, 13 Mar 2012 12:08:54 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7634D21F860D for ; Tue, 13 Mar 2012 12:08:48 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKT1+bP0RRCwPmfuIrxaKxWkD2iFMY3R3f@postini.com; Tue, 13 Mar 2012 12:08:48 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 13 Mar 2012 12:08:32 -0700 From: John Scudder To: "idr@ietf.org List" Date: Tue, 13 Mar 2012 12:08:31 -0700 Thread-Topic: IETF-83 draft IDR agenda posted Thread-Index: Ac0BTK5c0vZ1/K19TLeN9Q808aDJAg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] IETF-83 draft IDR agenda posted 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, 13 Mar 2012 19:08:55 -0000 Folks, Our draft agenda is at http://www.ietf.org/proceedings/83/agenda/agenda-83-= idr.txt If you requested a slot, please double-check. If you didn't request a slot = but meant to, please do so at once. The agenda is subject to revision of course. --John From robert@raszuk.net Tue Mar 13 14:12:29 2012 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 DC16021F8690 for ; Tue, 13 Mar 2012 14:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 VsZOrdjvJpSu for ; Tue, 13 Mar 2012 14:12:29 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 0B81921F8697 for ; Tue, 13 Mar 2012 14:12:28 -0700 (PDT) Received: (qmail 20253 invoked by uid 399); 13 Mar 2012 21:12:28 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.31.181.251) by mail1310.opentransfer.com with ESMTPM; 13 Mar 2012 21:12:28 -0000 X-Originating-IP: 83.31.181.251 Message-ID: <4F5FB83D.1080405@raszuk.net> Date: Tue, 13 Mar 2012 22:12:29 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "idr@ietf.org List" References: <20120305035326.31140.39844.idtracker@ietfa.amsl.com> In-Reply-To: <20120305035326.31140.39844.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120305035326.31140.39844.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Idr] draft-djsmith-bgp-flowspec-oid-00.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: Tue, 13 Mar 2012 21:12:30 -0000 Hi, I have a question to the authors of "Revised Validation Procedure for BGP Flow Specifications". Effectively the entire draft is about this section: 4. Revised Validation Procedure Step (a) of the validation procedure specified in [RFC5575], section 6 is OPTIONAL for IBGP learned flow specification NLRIs. This OPTIONAL behavior MAY be configurable on BGP speakers, however, step (a) of the validation procedure SHOULD be disabled by default for IBGP learned flow specification NRLIs. Question: How can you disable step (a) of RFC5575 section 6 or make it optional and still allow for step (b) if step (b) uses a product of step (a) ? Regards, R. PS. In the current commercial implementation of RFC5575 disabling validation is just one line configuration: "no-validate from-ibgp-rr-rc"; where "from-ibgp-rr-rc" is your policy. From internet-drafts@ietf.org Tue Mar 13 14:55:48 2012 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 5F4D521E8028; Tue, 13 Mar 2012 14:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 sx9TUYdRPUv7; Tue, 13 Mar 2012 14:55:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D6221E8017; Tue, 13 Mar 2012 14:55:47 -0700 (PDT) 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: 4.00 Message-ID: <20120313215547.8172.43663.idtracker@ietfa.amsl.com> Date: Tue, 13 Mar 2012 14:55:47 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-operational-message-00.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, 13 Mar 2012 21:55:48 -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 : BGP OPERATIONAL Message Author(s) : David Freedman Robert Raszuk Rob Shakir Filename : draft-ietf-idr-operational-message-00.txt Pages : 29 Date : 2012-02-29 The BGP Version 4 routing protocol (RFC4271) is now used in many ways, crossing boundaries of administrative and technical responsibility. The protocol lacks an operational messaging plane which could be utilised to diagnose, troubleshoot and inform upon various conditions across these boundaries, securely, during protocol operation, without disruption. This document proposes a new BGP message type, the OPERATIONAL message, which can be used to effect such a messaging plane for use both between and within Autonomous Systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-operational-message-00.t= xt 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-operational-message-00.txt From jgs@juniper.net Wed Mar 14 12:08:32 2012 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 5D74721F8843 for ; Wed, 14 Mar 2012 12:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 rK9zN7qLl9Vu for ; Wed, 14 Mar 2012 12:08:31 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 53AB021F8842 for ; Wed, 14 Mar 2012 12:08:31 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKT2Dsroy80/1+tV7XPuUv496jH0HJERi1@postini.com; Wed, 14 Mar 2012 12:08:31 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 14 Mar 2012 12:08:01 -0700 From: John Scudder To: John Scudder Date: Wed, 14 Mar 2012 12:08:00 -0700 Thread-Topic: [Idr] IETF-83 draft IDR agenda posted Thread-Index: Ac0CFcYtpQL6Q5HlRKeUk4uPIffTAg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] IETF-83 draft IDR agenda posted 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, 14 Mar 2012 19:08:32 -0000 The agenda has been updated. It is not yet final -- there are a few more pe= nding requests we're considering. You'll notice something new -- Jeff Haas contributed a BGP MIBv2 Update sli= de deck but proposes to discuss it on the list. There's a URL for the deck = on the agenda. I encourage people to review the deck and discuss on the lis= t prior to the meeting. If questions arise that would benefit from in-perso= n followup, we will add a slot for MIB discussion. Thanks to Jeff for takin= g the initiative and I hope we'll be doing more of this for 'update' presen= tations. --John =20 On Mar 13, 2012, at 3:08 PM, John Scudder wrote: > Folks, >=20 > Our draft agenda is at http://www.ietf.org/proceedings/83/agenda/agenda-8= 3-idr.txt >=20 > If you requested a slot, please double-check. If you didn't request a slo= t but meant to, please do so at once. >=20 > The agenda is subject to revision of course. >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jhaas@slice.pfrc.org Thu Mar 15 11:19:18 2012 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 C827521F87D2 for ; Thu, 15 Mar 2012 11:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.167 X-Spam-Level: X-Spam-Status: No, score=-102.167 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 wuc7KqhlFgnN for ; Thu, 15 Mar 2012 11:19:18 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2411A21F87B0 for ; Thu, 15 Mar 2012 11:19:18 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C444A1703D8; Thu, 15 Mar 2012 14:19:17 -0400 (EDT) Date: Thu, 15 Mar 2012 14:19:17 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20120315181917.GA1617@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Idr] IETF 83 - BGP MIBv2 Update - prefix Textual Conventions 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 Mar 2012 18:19:18 -0000 Working Group, As per prior plenary discussion on making more effect use of working group session time, please find my BGP MIBv2 update slides on the proceedings page: http://www.ietf.org/proceedings/83/slides/slides-83-idr-0.pdf The bulk of the presentation is self explanatory. I'd like to thank Bert Wijnen for additional MIB feedback. I suspect we'll get a bit more feedback from him since he discovered bugs as part of doing derivative work for the SIDR MIB. Draft -13 [1] reflects his comments as of the IETF 83 posting cutoff. One item I would like to draw the working group's further attention to is covered on slides 5-7. As part of analyzing the requirements for the multicast next-gen VPN [2] MIBs that Jeffrey Zhang (zzhang@juniper.net) is working on, we briefly considered exposing MVPN routing state in BGP via the BGP MIBv2. Per prior presentations and discussions on design goals for the BGP MIBv2, we wanted one MIB that was capable of being re-used for various types of reachability that was being carried in BGP. However, the primary goal was to be able to carry IPv6 reachability. RFC 6514 can be briefly examined to see the different types of reachability that are being passed around in BGP. The reachability is distinguished within the same AFI/SAFI by a "Route Type" field within the prefix with type specific encodings following. The BGP MIBv2 presents prefixes using the following two objects: bgp4V2NlriPrefixType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the IP address prefix in the Network Layer Reachability Information field. The value of this object is derived from the appropriate value from the bgp4V2NlriAfi field. Where an appropriate InetAddressType is not available, the value of the object must be unknown(0)." ::= { bgp4V2NlriEntry 4 } bgp4V2NlriPrefix OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "An IP address prefix in the Network Layer Reachability Information field. This object is an IP address containing the prefix with length specified by bgp4V2NlriPrefixLen. Any bits beyond the length specified by bgp4V2NlriPrefixLen are zeroed. An implementation is required to support IPv4 prefixes. In this case, the object length is (0..4). An implementation MAY support IPv6 prefixes. In this case, the object length is (0..16)" REFERENCE "RFC 4271, Section 4.3." ::= { bgp4V2NlriEntry 5 } The general goal of the "InetAddressType/InetAddress" textual conventions [3] is to provide a level of generality for MIB objects that are "addresses". Our initial design guidance for the BGP MIBv2 was to make use of these TCs to help represent both IPv4 and IPv6 addresses - and it does this well. As part of investigating encoding MVPN prefixes in the BGP MIBv2, I sent mail to the ietfmibs mailing list to discuss this possibility. After a few exchanges, it was suggested that since the information is BGP specific that this was not the best fit for the INET-ADDRESS-MIB and that we should consider a BGP TC specifically for this purpose. If we were to consider such a TC, we would make it "IANA maintained". This would permit us to issue the initial MIB but permit IANA to maintain the code points as new protocol elements are added. I.e. we don't have to have a MIB document stuck as an I-D forever. The current INET-ADDRESS-MIB is an example of such a MIB. After further discussion with Jeffrey Zhang, we determined that there wasn't a strong incentive to continue the MVPN MIB work as a BGP MIBv2 extension, We may see future requirements from other BGP-based address families. My recommendation would be that we proceed with the work to create a BGP Prefix TC MIB with an explicit goal of being backward compatible with the INET-ADDRESS-MIB. However, the WG may also come to the decision to not pursue making this MIB completely general purpose and just worry about IPv4/IPv6. With regard to standards advancement, the new BGP Prefix MIB shouldn't unnecessarily hinder the BGP MIBv2. I would like the WG to come to some consensus as to whether we (very likely, I) take on the work to make such a prefix TC MIB. If the discussion becomes interesting enough, Sue and John have agreed to grant us discussion time at the upcoming IDR session in Paris. -- Jeff [1] http://tools.ietf.org/html/draft-ietf-idr-bgp4-mibv2-13 [2] http://tools.ietf.org/html/rfc6514 [3] http://tools.ietf.org/html/rfc4001 From heas@shrubbery.net Wed Mar 21 10:38:37 2012 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 E536B21E801A; Wed, 21 Mar 2012 10:38:36 -0700 (PDT) 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 Bm3DwxCg1rLm; Wed, 21 Mar 2012 10:38:36 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DFE21F8569; Wed, 21 Mar 2012 10:38:24 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id A4BDC88B70; Wed, 21 Mar 2012 17:38:23 +0000 (UTC) Date: Wed, 21 Mar 2012 17:38:23 +0000 From: heasley To: "Bert Wijnen (IETF)" Message-ID: <20120321173823.GB75903@shrubbery.net> References: <0E2C44659B4E4C22A58EDF7E0A834092@BertLaptop> <4F5FB239.7090009@bwijnen.net> <4F68A20F.5000506@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F68A20F.5000506@bwijnen.net> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jeffrey Haas , idr@IETF.ORG, sidr wg list Subject: Re: [Idr] [sidr] BGP4 MIB module 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, 21 Mar 2012 17:38:37 -0000 Tue, Mar 20, 2012 at 04:28:15PM +0100, Bert Wijnen (IETF): > So I had been in discussion with Jeff in order to see > if we could get the BGP4-mibv2 module in good shape. > > Below is out discussion. > > Those who are interested in this MIB module at all > may want to take a look to make sure they agree with > the changes being proposed. > > The most modules we're discussion are: > > - drafts/draft-ietf-idr-bgp4-mibv2-13.txt > - drafts/draft-ietf-idr-bgp4-mibv2-tc-mib-03.txt > > In fact I had below discussion on bgp4-mibv2-12.txt, > which resulted in revision 13. I'm disappointed in the speed at which this draft has progressed. I do understand that mibs are often partially gated for/by trial implementation (or so I've been told), but I have the impression its pace is wholly due to the complexity of the proposed mib. I also feel that there is a fair amount of fluff that we find unnecessary for network management and would be better suited to a separate mib; the RIBs, for example. bgp4-mibv2 ("lite"), bgp4-ribs, etc; or some approach that would allow the necessities of peer state, nlri counts, and the like to progress without the fluff and thus be more timely. As such, I am unsure why its been brought to the sidr list, but I am hoping that no attempt will be made to add SIDR-related stuff to this mib and further delay adoption. From bertietf@bwijnen.net Tue Mar 20 08:28:23 2012 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 3566C21F85A4; Tue, 20 Mar 2012 08:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 evtErvmRfVhv; Tue, 20 Mar 2012 08:28:22 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id CAB2621F85AA; Tue, 20 Mar 2012 08:28:18 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SA0yu-00064Z-51; Tue, 20 Mar 2012 16:28:18 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SA0yt-0005T3-St; Tue, 20 Mar 2012 16:28:16 +0100 Message-ID: <4F68A20F.5000506@bwijnen.net> Date: Tue, 20 Mar 2012 16:28:15 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jeffrey Haas , sidr wg list , idr@IETF.ORG References: <0E2C44659B4E4C22A58EDF7E0A834092@BertLaptop> <4F5FB239.7090009@bwijnen.net> In-Reply-To: <4F5FB239.7090009@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd41cafc88c9eb0867ebd1beb2fb90d88e4 X-Mailman-Approved-At: Thu, 22 Mar 2012 08:03:58 -0700 Subject: [Idr] BGP4 MIB module 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, 20 Mar 2012 15:28:23 -0000 So I had been in discussion with Jeff in order to see if we could get the BGP4-mibv2 module in good shape. Below is out discussion. Those who are interested in this MIB module at all may want to take a look to make sure they agree with the changes being proposed. The most modules we're discussion are: - drafts/draft-ietf-idr-bgp4-mibv2-13.txt - drafts/draft-ietf-idr-bgp4-mibv2-tc-mib-03.txt In fact I had below discussion on bgp4-mibv2-12.txt, which resulted in revision 13. On 3/13/12 9:46 PM, Bert Wijnen (IETF) wrote: > On 3/11/12 7:36 PM, Jeffrey Haas wrote: >> Bert, >> >> On Jan 17, 2012, at 9:28 AM, Bert Wijnen (IETF) wrote: >> >>> First, should we have this discussion on the SIDR list? >>> Maybe we can get folk motivated to move this forward >>> that way? >> >> I'm massively behind on SIDR, but will be looking at it today. >> >>> I had to get a new SMICng key first. >> >> Thanks for doing that. >> >>> >>> With the new MIB modules I get: >>> >>> C:\bw\smicng\work>smicng bgp4v2.inc >>> E: f(bgp4v2.mi2), (176,5) Item "bgp4V2PeerLocalAddrType" has invalid value for >>> MAX-ACCESS >>> E: f(bgp4v2.mi2), (185,5) Item "bgp4V2PeerLocalAddr" has invalid value for >>> MAX-ACCESS >>> W: f(bgp4v2.mi2), (1015,13) Row "bgp4V2NlriEntry" does not have a consistent >>> indexing schem >>> e - index items from current table must come after index items from other tables >>> W: f(bgp4v2.mi2), (1516,13) Row "bgp4V2AdjRibsOutEntry" does not have a >>> consistent indexing >>> scheme - cannot specify an index item from additional "base row" >>> bgp4V2NlriEntry, since ca >>> n have only one "base row" which is bgp4V2PeerEntry >>> E: f(bgp4v2.mi2), (1627,16) OBJECT-TYPE "bgp4V2PeerLocalAddr" is not in a >>> MANDATORY or cond >>> itional group for module "BGP4V2-MIB" >>> E: f(bgp4v2.mi2), (1635,16) OBJECT-TYPE "bgp4V2PeerRemoteAddr" is not in a >>> MANDATORY or con >>> ditional group for module "BGP4V2-MIB" >>> E: f(bgp4v2.mi2), (1643,16) OBJECT-TYPE "bgp4V2NlriPrefix" is not in a MANDATORY >>> or conditi >>> onal group for module "BGP4V2-MIB" >>> >>> *** 5 errors and 2 warnings in parsing >>> >>> C:\bw\smicng\work> >>> >>> W.r.t. >>> E: f(bgp4v2.mi2), (176,5) Item "bgp4V2PeerLocalAddrType" has invalid value for >>> MAX-ACCESS >>> E: f(bgp4v2.mi2), (185,5) Item "bgp4V2PeerLocalAddr" has invalid value for >>> MAX-ACCESS >>> >>> You have >>> INDEX { >>> bgp4V2PeerInstance, >>> bgp4V2PeerRemoteAddrType, >>> bgp4V2PeerRemoteAddr >>> } >>> >>> So why are the LOCAL addrtype and addr not-accessible? >>> Or should they be part of the index? >> >> At one point the local address items were part of the index for the table. After some discussion with implementors, they preferred >> that it be left as it is in the existing BGP-4 MIB case. While this is unfortunate, it makes sense. >> >> In BGP, it is typically the case that you'll have a single peering session to a given destination peer address. However, there are >> some corner case peering scenarios where two local addresses on a given router may peer with the same destination address from the >> same instance. This is a *very* uncommon case and it lead to some minor tweaks in the BGP language when RFC 4271 was published. >> >> The problem with putting the local address into the key is that it removes the determinism from the index. If the local address is >> not configured, as may be the case for ebgp peering, you may not know what it would be. In the case of some ibgp, it's also >> possible the local address may change based on what TCP decided it needed. Instead of catering to these uncertain cases, it was >> cleaner to remove the local address from the index. >> >> I have changed these back to read-only. >> > > good. > >>> >>> W.r.t. >>> W: f(bgp4v2.mi2), (1015,13) Row "bgp4V2NlriEntry" does not have a consistent >>> indexing schem >>> e - index items from current table must come after index items from other tables >>> >>> You have: >>> >>> INDEX { >>> bgp4V2PeerInstance, >>> bgp4V2NlriAfi, >>> bgp4V2NlriSafi, >>> bgp4V2NlriPrefixType, >>> bgp4V2NlriPrefix, >>> bgp4V2NlriPrefixLen, >>> bgp4V2PeerRemoteAddrType, >>> bgp4V2PeerRemoteAddr, >>> bgp4V2NlriIndex >>> } >>> ::= { bgp4V2NlriTable 1 } >>> >>> So pls explain to me that indexing so I can form an opinion if that is OK or >>> not. Besides the warning from SMICng, I also wonder why >>> NlriIndex is the last index column, while it is the first column in the >>> table. >> >> The above up to nlri-index is a natural order walk for BGP. It's also largely what is used in the existing 4273 MIB: >> >> bgp4PathAttrEntry OBJECT-TYPE >> SYNTAX Bgp4PathAttrEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "Information about a path to a network." >> INDEX { bgp4PathAttrIpAddrPrefix, >> bgp4PathAttrIpAddrPrefixLen, >> bgp4PathAttrPeer } >> ::= { bgp4PathAttrTable 1 } >> >> Thus, walk all of a given instance. There's no guarantee that 10/8 in one instance is the same as another, especially since the >> instance may map to a VPN VRF. >> Walk a given prefix and peer, as it is in the older table. The prefixes are walked on a per afi/safi basis since the families are >> also incomparable. You then want to see the prefix from all peers. >> >> The nlriindex covers two cases: Multiple routes in RFC 3107 (which I don't believe anyone implements) and BGP add-path. You want >> to see all routes from a given peer and the nlri index lets you see more than one >> >> Hopefully the ordering makes sense in the index. >> >> I now see what you mean about the fact that the object for nlriindex precedes things like the afi and safi. It's mostly just been >> this way for a while. If you feel strongly that it should be re-ordered, we could probably do that since we haven't hit RFC, but >> it will have impact on anyone that may have an in-flight implementation of this. Thus far our fixes have had only minor impact. >> The above is still a warning I get in the revision 13. Would be good to have some comments from (other) implementers or those who plan to implement >> >>> >>> W.r.t. >>> W: f(bgp4v2.mi2), (1516,13) Row "bgp4V2AdjRibsOutEntry" does not have a >>> consistent indexing >>> scheme - cannot specify an index item from additional "base row" >>> bgp4V2NlriEntry, since ca >>> n have only one "base row" which is bgp4V2PeerEntry >>> >>> You have: >>> INDEX { >>> bgp4V2PeerInstance, >>> bgp4V2NlriAfi, >>> bgp4V2NlriSafi, >>> bgp4V2NlriPrefixType, >>> bgp4V2NlriPrefix, >>> bgp4V2NlriPrefixLen, >>> bgp4V2PeerRemoteAddrType, >>> bgp4V2PeerRemoteAddr, >>> bgp4V2AdjRibsOutIndex >>> } >>> ::= { bgp4V2AdjRibsOutTable 1 } >>> >>> Pls explain indexing scheme, so I can form an opinion. >> >> The scheme is identical to the prior explanation. The primary difference is since this is sending routes rather than receiving >> them, we may advertise different routes on egress, hence an OutIndex instead of the prior NlriIndex. >> Same question here >> >>> >>> W.r.t. >>> E: f(bgp4v2.mi2), (1627,16) OBJECT-TYPE "bgp4V2PeerLocalAddr" is not in a >>> MANDATORY or cond >>> itional group for module "BGP4V2-MIB" >>> E: f(bgp4v2.mi2), (1635,16) OBJECT-TYPE "bgp4V2PeerRemoteAddr" is not in a >>> MANDATORY or con >>> ditional group for module "BGP4V2-MIB" >>> E: f(bgp4v2.mi2), (1643,16) OBJECT-TYPE "bgp4V2NlriPrefix" is not in a MANDATORY >>> or conditi >>> onal group for module "BGP4V2-MIB" >>> >>> I thought you were going to do them as comments in a DESCRIPTION clause? >> >> I'm sorry, I've lost track of what we may have discussed with regard to a description update. >> > I saw in your other email that you found it. > WIll check if/when you send new mib module. > OK, seems fixed in rev 13. > And again, our discussion probably should be copied to wg list. > If you agree, I can just copy our conversation to it. > > Bert >> -- Jeff >> >> > From shares@ndzh.com Sat Mar 24 21:26:50 2012 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 5C35221E8020 for ; Sat, 24 Mar 2012 21:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 9Kp61m+IR8sb for ; Sat, 24 Mar 2012 21:26:49 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [63.208.161.199]) by ietfa.amsl.com (Postfix) with ESMTP id 9555821E8011 for ; Sat, 24 Mar 2012 21:26:49 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=130.129.64.203; Received: from SKH2012HPLT (unverified [130.129.64.203]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3203337-1945496 for multiple; Sat, 24 Mar 2012 23:26:42 -0500 From: "Susan Hares" To: Date: Sun, 25 Mar 2012 00:26:18 -0400 Message-ID: <00ee01cd0a3f$7bb131c0$73139540$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EF_01CD0A1D.F4A11860" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0KPvl5cAU9PmAvQv2ZdxEc/WsKkQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: [Idr] draft-ietf-idr-as4octet-extcomm-generic-subtype-05.tx - WGLC 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: Sun, 25 Mar 2012 04:26:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00EF_01CD0A1D.F4A11860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is to start a WG last call on: draft-ietf-idr-as4octet-extcomm-generic-subtype-05.txt It will run from 3/25/2012 to 4/8/2012 found at: http://tools.ietf.org/wg/idr/draft-ietf-idr-reserved-extended-communities Sue and John ------=_NextPart_000_00EF_01CD0A1D.F4A11860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is to = start a WG last call on:

 

draft-ietf-idr-as4octet-extcomm-generic-subtype-05.txt<= o:p>

 

It will run from 3/25/2012 to 4/8/2012 =

 

found at:

 

http://tools.ietf.org/wg/idr/draft-ietf-idr-reserved-extended-c= ommunities

 

 

Sue and = John

 

------=_NextPart_000_00EF_01CD0A1D.F4A11860-- From jgs@juniper.net Sun Mar 25 07:10:28 2012 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 9082721F84D9 for ; Sun, 25 Mar 2012 07:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 9jIz9VAbjlB7 for ; Sun, 25 Mar 2012 07:10:28 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id A0CD121F84D6 for ; Sun, 25 Mar 2012 07:10:26 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKT28nUizirv7WqK5YpfSJq3Pz9AujDbNh@postini.com; Sun, 25 Mar 2012 07:10:27 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Sun, 25 Mar 2012 07:10:17 -0700 From: John Scudder To: "idr@ietf.org List" Date: Sun, 25 Mar 2012 07:10:16 -0700 Thread-Topic: draft-ietf-idr-as4octet-extcomm-generic-subtype-05.tx - WGLC Thread-Index: Ac0KkQEBqjNzTJprQ8CiJTdDLrFYXg== Message-ID: <784BCA56-0C35-457B-86E8-72D55152C1D5@juniper.net> References: <00ee01cd0a3f$7bb131c0$73139540$@ndzh.com> In-Reply-To: <00ee01cd0a3f$7bb131c0$73139540$@ndzh.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 Cc: Hares Susan Subject: Re: [Idr] draft-ietf-idr-as4octet-extcomm-generic-subtype-05.tx - WGLC 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: Sun, 25 Mar 2012 14:10:28 -0000 Correct link for the draft: http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-= 05 --John On Mar 25, 2012, at 6:26 AM, Susan Hares wrote: This is to start a WG last call on: draft-ietf-idr-as4octet-extcomm-generic-subtype-05.txt It will run from 3/25/2012 to 4/8/2012 found at: http://tools.ietf.org/wg/idr/draft-ietf-idr-reserved-extended-communities Sue and John From zubair.ahmad@orange.com Sun Mar 25 13:51:22 2012 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 B843521E802D for ; Sun, 25 Mar 2012 13:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=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 EVmA4EIMEZZ8 for ; Sun, 25 Mar 2012 13:51:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 74B3C21E801A for ; Sun, 25 Mar 2012 13:51:21 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 364012DC123 for ; Sun, 25 Mar 2012 22:51:20 +0200 (CEST) Received: from PWEXCB10.usa.francetelecom.fr (unknown [10.112.0.69]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D4F384C015 for ; Sun, 25 Mar 2012 22:51:19 +0200 (CEST) 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_01CD0AC9.02947DE8" Date: Sun, 25 Mar 2012 16:51:11 -0400 Message-ID: <16133_1332708680_4F6F8548_16133_12406_1_7C5C5ED440632B4DAE601971324975F504A7BBE3@PWEXCB10.usa.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPLS 2012 International Conference - Call for Papers Thread-Index: Ac0KyQJ8Oq7LAuI+THW0N4K7JVAfbw== From: To: X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.25.202415 Subject: [Idr] MPLS 2012 International Conference - Call for Papers 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: Sun, 25 Mar 2012 20:51:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0AC9.02947DE8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 The MPLS 2012 International Conference, the 15th Annual International Confe= rence on MPLS and Related Technologies, will be held October 28 - 31, 2012,= in Washington, DC. The Technical Program Committee is soliciting abstracts= summarizing a proposed presentation representing original/unpublished work= covering cutting-edge topics. Presentations covering new technologies and operational experience are soli= cited from network equipment vendors, service/ transport providers, governm= ent agencies, the research community and enterprise users. The deadline for= submission of presentation proposals is April 30, 2012. If you want furthe= r information on MPLS 2012 or want to submit a presentation abstract, pleas= e see the following URL: =20 http://www.isocore.com/mpls2012/call_for_papers/cfp.htm =20 Many of these topics have been of interest to the members of IDR working gr= oup in the past and many people active on this list have been presenters at= past events. Regards, =20 Zubair Ahmad (Technical Program Committee, MPLS 2012) ___________________________________________________________________________= ______________________________________________ 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 authorisation. 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 is not liable for message= s that have been modified, changed or falsified. Thank you. ------_=_NextPart_001_01CD0AC9.02947DE8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
 
= The MPLS 2012 International Conference, the 15t= h Annual International Conference o= n MPLS and Related Technologies, will be held October 28 - 31, 2012, in Washington, DC. The Technical Program = Committee is soliciting abstracts s= ummarizing a proposed presentation representing original/unpublished work covering cutting-edge topics.=
=
=
= Presentations covering new technologies and ope= rational experience are solicited f= rom network equipment vendors, serv= ice/ transport providers, government agencies, the research community = and enterprise users. The deadline = for submission of presentation proposals is April 30, 2012. If you want further information on MPLS 2012 or wa= nt to submit a presentation abstrac= t, please see the following URL:
=  
=
=
=
= Many of these topics have been of interest to&n= bsp;the members of IDR working group in the past and many people active on this list have been presenters at past events.
=
=
= Regards,
=  
= = Zubair Ahmad (Technical Program Committee, MPLS 2012)
______________________________________________________________________=
___________________________________________________

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 authorisation.
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 is not liable for message=
s that have been modified, changed or falsified.
Thank you.
= ------_=_NextPart_001_01CD0AC9.02947DE8-- From jgs@juniper.net Sun Mar 25 22:30:21 2012 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 DACD721F853C for ; Sun, 25 Mar 2012 22:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 FqQ7xX8tCrix for ; Sun, 25 Mar 2012 22:30:20 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id AF40C21F84B5 for ; Sun, 25 Mar 2012 22:30:20 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKT2/+7F5rh+DiB9Imayevctng3IvxPQPF@postini.com; Sun, 25 Mar 2012 22:30:20 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Sun, 25 Mar 2012 22:29:41 -0700 From: John Scudder To: "idr@ietf.org List" Date: Sun, 25 Mar 2012 22:29:41 -0700 Thread-Topic: Taking IDR minutes today, collaborative tool Thread-Index: Ac0LEXFxj/mb9DKmQOWhK7dJYWAHpw== Message-ID: <6311C231-B3A0-4777-B56C-75C452150DFA@juniper.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 Subject: [Idr] Taking IDR minutes today, collaborative tool 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, 26 Mar 2012 05:30:22 -0000 Folks, For anyone willing to help with meeting notes, here is a URL for a collabor= ative note-taking tool (Etherpad, provided courtesy Henrik Levkowetz), feel= free to use it: http://tools.ietf.org/wg/idr/minutes Of course, also feel free to send notes in any other format you may like. W= e would certainly appreciate any help with notes. TIA. --John From david.freedman@uk.clara.net Mon Mar 26 00:31:10 2012 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 782A921F83EF for ; Mon, 26 Mar 2012 00:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.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 5MZfeRZCUbhb for ; Mon, 26 Mar 2012 00:31:10 -0700 (PDT) Received: from staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [IPv6:2001:a88:0:fff7::68]) by ietfa.amsl.com (Postfix) with ESMTP id 4771E21F8454 for ; Mon, 26 Mar 2012 00:31:08 -0700 (PDT) Received: from [195.157.10.59] (port=27443 helo=SRVGREXCAS02.claranet.local) by staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [80.168.65.68]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1SC4OR-0002ix-0a for idr@ietf.org (return-path ); Mon, 26 Mar 2012 07:31:07 +0000 Received: from SRVGREXMB02.claranet.local ([10.75.5.12]) by SRVGREXCAS02.claranet.local ([fe80::cd6a:3120:3174:a299%10]) with mapi id 14.01.0339.001; Mon, 26 Mar 2012 08:31:07 +0100 From: David Freedman To: "idr@ietf.org" Thread-Topic: Operational - Implementations Thread-Index: AQHNCyJnM8otgCno7kit/YQ4VIweZQ== Date: Mon, 26 Mar 2012 07:31:05 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.18.6.3] Content-Type: multipart/alternative; boundary="_000_CB95E7DA89293davidfreedmaneuclaranet_" MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean Subject: [Idr] Operational - Implementations 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, 26 Mar 2012 07:31:10 -0000 --_000_CB95E7DA89293davidfreedmaneuclaranet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Further to John's question this morning in Paris, I'd like to share the pat= ch I made to quagga for ADVISORY (one of the precursors to OPERATIONAL) , t= his demonstrates some of the functionality that the ADM and ASM messages in= OPERATIONAL make use of. http://www.convergence.cx/advisory.html --_000_CB95E7DA89293davidfreedmaneuclaranet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Further to John's question this morning in Paris, I'd like to share th= e patch I made to quagga for ADVISORY (one of the precursors to OPERATIONAL= ) , this demonstrates some of the functionality that the ADM and ASM messag= es in OPERATIONAL make use of.

 
--_000_CB95E7DA89293davidfreedmaneuclaranet_-- From xuxiaohu@huawei.com Mon Mar 26 01:23:35 2012 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 B399F21F855A for ; Mon, 26 Mar 2012 01:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.849 X-Spam-Level: X-Spam-Status: No, score=0.849 tagged_above=-999 required=5 tests=[AWL=1.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_BASE64_TEXT=1.753] 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 wpqtTfhKYUeb for ; Mon, 26 Mar 2012 01:23:34 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2014921F8576 for ; Mon, 26 Mar 2012 01:23:31 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AER77164; Mon, 26 Mar 2012 04:23:30 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 26 Mar 2012 01:20:52 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 26 Mar 2012 01:20:50 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.158]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Mon, 26 Mar 2012 16:20:43 +0800 From: Xuxiaohu To: "idr@ietf.org" Thread-Topic: draft-bashandy-idr-bgp-repair-label-03 Thread-Index: Ac0LKG62Z0oP7mVyTVmtlZw8K92vMQ== Date: Mon, 26 Mar 2012 08:20:43 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CDF6D3@szxeml525-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.68] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CDF6D3szxeml525mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 26 Mar 2012 01:25:31 -0700 Subject: [Idr] draft-bashandy-idr-bgp-repair-label-03 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, 26 Mar 2012 08:23:36 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CDF6D3szxeml525mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgY28tYXV0aG9ycyBvZiB0aGUgYWJ2b3ZlIGRyYWZ0LA0KDQoNCg0KSW4geW91IGRyYWZ0LCBp dCBzYWlkIkFzIHVzdWFsLCBlYWNoIFBFIGFsbG9jYXRlcyBhIGxvY2FsIGxhYmVsIGZvciBlYWNo IHByZWZpeCBpdCBjYW4gcmVhY2ggdGhyb3VnaCBhbiBleHRlcm5hbCBuZWlnaGJvciBDRS4gVGhp cyBpcyB0aGUgcHJpbWFyeSBsYWJlbCB1c2VkIGZvciBub3JtYWwgdHJhZmZpYyBmb3J3YXJkaW5n LiIgYW5kICJUbyBwcm92aWRlIHJlcGFpciBwYXRoIGluZm9ybWF0aW9uIHRvIGFsbCBQRXMsIHRo ZSBQRSBhbHNvIGFsbG9jYXRlcyBhIHJlcGFpciBsYWJlbCB0byB0aGUgcHJlZml4IGlmIGl0IGNh biByZWFjaCB0aGF0IHByZWZpeCB2aWEgYW4gZXh0ZXJuYWwgbmVpZ2hib3IuIg0KDQoNCg0KRG9l cyBpdCBtZWFuIHRoZSBleHRlcm5hbCBwYXRoIHdoaWNoIHRoZSByZXBhaXIgbGFiZWwgaXMgYXNz b2NpYXRlZCB3aXRoIGlzIGEgYmVzdCBleHRlcm5hbCBwYXRoPyBJZiBzbywgY291bGQgeW91IGV4 cGxhaW4gd2hhdCdzIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgYWJvdmUgZHJhZnQgYW5kIHRoaXMg ZHJhZnQgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LWlkci1iZXN0LWV4dGVy bmFsLWxvb3AtYXZvaWRhbmNlLTAwKS4NCg0KDQoNCkJSLA0KDQpYaWFvaHUNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CDF6D3szxeml525mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi co-authors of the abvove draft,

 

In you draft, it said"As usual, each PE allocates a local label for= each prefix it can reach through an external neighbor CE. This is the= primary label used for normal traffic forwarding." and "To = provide repair path information to all PEs, the PE also allocates a repair label to the prefix if it can reach that prefix via an exter= nal neighbor."

 

Does it mean the external path which the repair label is associated with= is a best external path? If so, could you explain what's difference betwee= n the above draft and this draft (http://tools.ietf.org/html/draft= -xu-idr-best-external-loop-avoidance-00).

 

BR,

Xiaohu

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CDF6D3szxeml525mbschi_-- From kireeti@juniper.net Mon Mar 26 01:25:52 2012 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 1A67521F8584 for ; Mon, 26 Mar 2012 01:25:52 -0700 (PDT) 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 2u49QfSv-Gkm for ; Mon, 26 Mar 2012 01:25:51 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 94C8921F85B8 for ; Mon, 26 Mar 2012 01:25:49 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKT3AoDCXfsPAiXy1CyAXlvRU0Kmung7NG@postini.com; Mon, 26 Mar 2012 01:25:50 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 26 Mar 2012 01:24:59 -0700 From: Kireeti Kompella To: "idr@ietf.org" Date: Mon, 26 Mar 2012 01:24:55 -0700 Thread-Topic: draft-djsmith-bgp-flowspec Thread-Index: Ac0LKe4D0aeHv096RvG2yabAefw4bw== 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] draft-djsmith-bgp-flowspec 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, 26 Mar 2012 08:25:52 -0000 Hi, [disclaimer: striving for accuracy, not PC-ness; probably won't achieve eit= her] I'd rephrase the problem as: there is no a priori reason that the originato= r of a BGP route ("hey, I have a good path to the destination") should be t= he same as the originator of the flowspec route ("hey, I know what policy t= o apply to traffic matching, among other things, this dest prefix"). These = are quite orthogonal functions.=20 IOW, the authors of the excellent RFC 5575 overstated the validation rules,= and the above draft fixes this. BTW, this applies to both e- and i-BGP; in= fact , perhaps more so to e-BGP, as policies in different ASs may be quite= different.=20 I support the draft; I would suggest the authors include the above in a mor= e accurate and PC phrasing [to forestall the question: what breaks if you c= hange the validation rules?] Kireeti From svshah@cisco.com Mon Mar 26 02:28:00 2012 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 E104A21F8546 for ; Mon, 26 Mar 2012 02:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.229 X-Spam-Level: X-Spam-Status: No, score=-10.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 e6LaKPkBup4F for ; Mon, 26 Mar 2012 02:27:55 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3E73621F859F for ; Mon, 26 Mar 2012 02:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=svshah@cisco.com; l=1126; q=dns/txt; s=iport; t=1332754075; x=1333963675; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=sYvXnEoTim1KU0V8oAmw0sB//yxBj3WCs/dI8uj1ltM=; b=Uq9cvajenBkxG2E9b/215shNZUM+bjKaOKC+KxchPLTwdGMemQWiCapc ViZiBXwkkhUVY/oC3tSDX6oTPZAeqZR2ZoiTy1I3iqyKtVIhx2kagxq2e I7UuAZBl1sn+gdqTihPeLLVhgQiENjCFdmqiFFMKiaolouMDHpBm0bOn4 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABg2cE+rRDoI/2dsb2JhbABEuDGBB4IJAQEBAwESAScCATIDBwUNAQgJBYEPAQEEAQ0FIodjBAGaGJ5DkSgEiFeFKodfjkWBaIMH X-IronPort-AV: E=Sophos;i="4.73,649,1325462400"; d="scan'208";a="37651508" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 26 Mar 2012 09:27:54 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2Q9RsBx013146; Mon, 26 Mar 2012 09:27:54 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 02:27:54 -0700 Received: from 10.21.120.189 ([10.21.120.189]) by xmb-sjc-221.amer.cisco.com ([128.107.191.80]) with Microsoft Exchange Server HTTP-DAV ; Mon, 26 Mar 2012 09:27:54 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 26 Mar 2012 02:27:53 -0700 From: svshah To: Lou Berger , Message-ID: Thread-Topic: Two comments on draft-svshah-bgp-qos-sla-attribute-00.txt Thread-Index: Ac0LMrgvGIgPNFyL7UGvjzGsdFnkMg== In-Reply-To: <4F703067.5010401@labn.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Mar 2012 09:27:54.0363 (UTC) FILETIME=[B8FF6CB0:01CD0B32] Cc: idr@ietf.org Subject: Re: [Idr] Two comments on draft-svshah-bgp-qos-sla-attribute-00.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, 26 Mar 2012 09:28:01 -0000 Hi Lou, Thank you for your comments 1) While agree MPLS Traffic Class may be more used in communication just like Diffserv Class is, it is very explicit to define them as MPLS_EXP just like we would as IP_DSCP for Diffserv classes. This explicit definition will leave no ambiguity for the receiver to instantiate filtering rules 2) Would "SLA" mean QoS only or is SLA generic to mean beyond QoS also? If it is earlier then it seems reasonable to follow your suggestion. In any case, your comment is well taken, we may refer in the draft as you say, with explicit definition of it in the beginning of the draft Shitanshu On 3/26/12 2:01 AM, "Lou Berger" wrote: > Hi, > I have two fairly pedantic comments on the draft: > > 1) Why MPLS_EXP and not MPLS_TC? > > 2) While QoS is used in a couple of RFCs related to DiffServ, its usage > in relationship to DS/TC seems to be more common in marketing usage. I > also thing calling this "QoS signaling" a bit of a stretch. So I > suggest not using QoS in this draft. Perhaps "SLA advertisement" is > sufficient. > > Lou From rajiva@cisco.com Mon Mar 26 03:03:32 2012 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 978B621F8469 for ; Mon, 26 Mar 2012 03:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.007 X-Spam-Level: X-Spam-Status: No, score=-10.007 tagged_above=-999 required=5 tests=[AWL=0.592, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 7nB22X1mDHqI for ; Mon, 26 Mar 2012 03:03:32 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BDFBD21F845C for ; Mon, 26 Mar 2012 03:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1774; q=dns/txt; s=iport; t=1332756212; x=1333965812; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=mGkvHfGFpoz8LV1HoasTklwMTYocInNOF3sznhyQWYk=; b=TwKQfHc7gjE8DBxzuB5X7O+CWzzOnOdT/44Frj7eZIBtw9oX6/BhoRe2 Ams5aK9YBYZMal78le6xyOFKi2/8QcRxlDhyWMy/YJXP0YoL6iDov3BHQ s6BrtCmGjhCVqpMyxDsAFAa7P1/XvaQmon7njDUSgAN94grb83epWEahw I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIk+cE+tJV2d/2dsb2JhbABEuDGBB4IJAQEBBAEBAQ8BHQo0AQMHDAYBCBEEAQEBCgYXAQcmHwkJAQQBEggah2gLmhmeRQSQRWMEiFebToFogwU X-IronPort-AV: E=Sophos;i="4.73,649,1325462400"; d="scan'208";a="69330214" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 26 Mar 2012 10:03:31 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2QA3VpB031678; Mon, 26 Mar 2012 10:03:31 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 05:03:31 -0500 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, 26 Mar 2012 05:03:29 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C07BD9213@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Two comments on draft-svshah-bgp-qos-sla-attribute-00.txt Thread-Index: Ac0LMrgvGIgPNFyL7UGvjzGsdFnkMgABCeDA From: "Rajiv Asati (rajiva)" To: "Shitanshu Shah (svshah)" , "Lou Berger" , X-OriginalArrivalTime: 26 Mar 2012 10:03:31.0217 (UTC) FILETIME=[B2A97810:01CD0B37] Cc: idr@ietf.org Subject: Re: [Idr] Two comments on draft-svshah-bgp-qos-sla-attribute-00.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, 26 Mar 2012 10:03:32 -0000 MPLS_EXP =3D MPLS_TC. Just a terminology change since rfc5462. Cheers, Rajiv > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Shitanshu Shah (svshah) > Sent: Monday, March 26, 2012 5:28 AM > To: Lou Berger; draft-svshah-bgp-qos-sla-attribute@tools.ietf.org > Cc: idr@ietf.org > Subject: Re: [Idr] Two comments on draft-svshah-bgp-qos-sla-attribute-00.txt >=20 >=20 > Hi Lou, >=20 > Thank you for your comments >=20 > 1) While agree MPLS Traffic Class may be more used in communication just > like Diffserv Class is, it is very explicit to define them as MPLS_EXP just > like we would as IP_DSCP for Diffserv classes. This explicit definition will > leave no ambiguity for the receiver to instantiate filtering rules >=20 > 2) Would "SLA" mean QoS only or is SLA generic to mean beyond QoS also? If > it is earlier then it seems reasonable to follow your suggestion. In any > case, your comment is well taken, we may refer in the draft as you say, with > explicit definition of it in the beginning of the draft >=20 > Shitanshu >=20 > On 3/26/12 2:01 AM, "Lou Berger" wrote: >=20 > > Hi, > > I have two fairly pedantic comments on the draft: > > > > 1) Why MPLS_EXP and not MPLS_TC? > > > > 2) While QoS is used in a couple of RFCs related to DiffServ, its usage > > in relationship to DS/TC seems to be more common in marketing usage. I > > also thing calling this "QoS signaling" a bit of a stretch. So I > > suggest not using QoS in this draft. Perhaps "SLA advertisement" is > > sufficient. > > > > Lou >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From randy@psg.com Mon Mar 26 03:46:18 2012 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 2952921F85D2 for ; Mon, 26 Mar 2012 03:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 4ZIUZCO94bsQ for ; Mon, 26 Mar 2012 03:46:17 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A72A121F8599 for ; Mon, 26 Mar 2012 03:46:17 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SC7RG-000ChF-18 for idr@ietf.org; Mon, 26 Mar 2012 10:46:14 +0000 Date: Mon, 26 Mar 2012 12:46:13 +0200 Message-ID: From: Randy Bush To: idr wg User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [Idr] draft-dickson-sidr-route-leak-solns-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, 26 Mar 2012 10:46:18 -0000 [ from my comments at the mic ] i do not think this will fly in the long run, but let my try to at least get it in the best light. o it could and should be said in a page or so in order that people can get it and think it is simple and not imposing o it assumes gao-rexford, which we know is an unsafe assumption, but wtf, it's good in enough cases that we can let it go for the moment o the relationship has to be per prefix not per link, as prefixes with different business models are often sent over the same link o the mark should be determined by the sender, and need not agree with the receiver's perception of the relationship o if the receiver does not like it they can call the sender on the phone, drop the announcement, whatever o this is a significant change to bgp, so idr should be asked to say it's cool before sidr tries to protect it by signing over it o if it is agreed by idr and it is well defined, we know how to sign it in bgpsec, it's like a few more bits on each hop in the as path o as with origin validation and path validation, the router should not do anything on its own, but rather should provide the operator the tools needed to apply policy based on the data o therefore, to use it, the router will have to give the operator some sort of expression over the catenation of the per-as policy markings o but what should an operator do when they see a 'violation' six hops away? randy From lberger@labn.net Mon Mar 26 02:01:36 2012 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 7FD3121F85E1 for ; Mon, 26 Mar 2012 02:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.317 X-Spam-Level: X-Spam-Status: No, score=-98.317 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.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 vfBheU-wDCGZ for ; Mon, 26 Mar 2012 02:01:36 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id D912F21F854D for ; Mon, 26 Mar 2012 02:01:35 -0700 (PDT) Received: (qmail 26664 invoked by uid 0); 26 Mar 2012 09:01:35 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.bluehost.com with SMTP; 26 Mar 2012 09:01:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=k6i603UmPn/NBKYn95FRQSqBO7GsmTO2ZFaofUyQeKU=; b=zIacF4WcvRyLDNYCeFbK41nYo7KGyngoWmrbIWZ1/9mo1ulyQI9IVZOx3t3EqhOHoXWA6pBWpexl9mpuP7yLErXTpw/Br1lEUK35u6BxSVhEI1L13mAv8HlsMu/F5VJP; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1SC5nz-0008DR-69; Mon, 26 Mar 2012 03:01:35 -0600 Message-ID: <4F703067.5010401@labn.net> Date: Mon, 26 Mar 2012 11:01:27 +0200 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: draft-svshah-bgp-qos-sla-attribute@tools.ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} X-Mailman-Approved-At: Mon, 26 Mar 2012 04:26:09 -0700 Cc: idr@ietf.org Subject: [Idr] Two comments on draft-svshah-bgp-qos-sla-attribute-00.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, 26 Mar 2012 09:01:36 -0000 Hi, I have two fairly pedantic comments on the draft: 1) Why MPLS_EXP and not MPLS_TC? 2) While QoS is used in a couple of RFCs related to DiffServ, its usage in relationship to DS/TC seems to be more common in marketing usage. I also thing calling this "QoS signaling" a bit of a stretch. So I suggest not using QoS in this draft. Perhaps "SLA advertisement" is sufficient. Lou From internet-drafts@ietf.org Mon Mar 26 04:35:43 2012 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 354F821F85AA; Mon, 26 Mar 2012 04:35:43 -0700 (PDT) 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 TEtpipP-Uvf1; Mon, 26 Mar 2012 04:35:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B643621F85A5; Mon, 26 Mar 2012 04:35:42 -0700 (PDT) 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: 4.00 Message-ID: <20120326113542.30972.22979.idtracker@ietfa.amsl.com> Date: Mon, 26 Mar 2012 04:35:42 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ix-bgp-route-server-00.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, 26 Mar 2012 11:35:43 -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 : Internet Exchange Route Server Author(s) : Elisa Jasinska Nick Hilliard Robert Raszuk Niels Bakker Filename : draft-ietf-idr-ix-bgp-route-server-00.txt Pages : 11 Date : 2012-03-26 This document outlines a specification for multilateral interconnections at Internet exchange points (IXPs). Multilateral interconnection is a method of exchanging routing information between three or more exterior BGP speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as Internet exchange points (IXPs), to facilitate simplified interconnection between multiple Internet routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-ix-bgp-route-server-00.t= xt 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-ix-bgp-route-server-00.txt From internet-drafts@ietf.org Tue Mar 27 00:38:12 2012 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 BEB7D21F878B; Tue, 27 Mar 2012 00:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 iKA1XITIAH33; Tue, 27 Mar 2012 00:38:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4083721F877C; Tue, 27 Mar 2012 00:38:12 -0700 (PDT) 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: 4.00 Message-ID: <20120327073812.5633.99323.idtracker@ietfa.amsl.com> Date: Tue, 27 Mar 2012 00:38:12 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-nh-cost-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 Mar 2012 07:38:13 -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 : Carrying next-hop cost information in BGP Author(s) : Ilya Varlashkin Robert Raszuk Filename : draft-ietf-idr-bgp-nh-cost-01.txt Pages : 10 Date : 2012-03-27 This document describes new BGP SAFI to exchange cost information to next-hops for the purpose of calculating best path from a peer perspective rather than local BGP speaker own perspective. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-nh-cost-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-nh-cost-01.txt From stephane.litkowski@orange.com Tue Mar 27 02:05:01 2012 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 D498221F88FC; Tue, 27 Mar 2012 02:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.450, 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 FF-KhpxvIPPu; Tue, 27 Mar 2012 02:05:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC9221F88D4; Tue, 27 Mar 2012 02:04:57 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E9F1622C0BB; Tue, 27 Mar 2012 11:04:56 +0200 (CEST) Received: from puexcc41.nanterre.francetelecom.fr (unknown [10.168.74.60]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id CF52E23806C; Tue, 27 Mar 2012 11:04:56 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc41.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 11:04:56 +0200 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 Mar 2012 11:04:55 +0200 Message-ID: <17281_1332839096_4F7182B8_17281_1356_1_4FC3556A36EE3646A09DAA60429F53350804C794@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <00e901cd0bf7$5a41ecf0$0ec5c6d0$@nobulus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ahRE: [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation Thread-Index: AQH3RvAe49uYSLxVSIfvfdRukh0PXAKofSLMlhQac5CAAAOs0A== References: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com> <11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr> <00e901cd0bf7$5a41ecf0$0ec5c6d0$@nobulus.com> From: To: "Ilya Varlashkin" , "IETF MPLS" , X-OriginalArrivalTime: 27 Mar 2012 09:04:56.0953 (UTC) FILETIME=[AE691690:01CD0BF8] X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317 Subject: Re: [Idr] ahRE: [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation 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 Mar 2012 09:05:01 -0000 As said to you offline, I would be interrested with discussing about your t= esting, achieving tns of msec with convergence is something I don't really = see in a real world (otherwise why should we implement TE FRR or LFA ??). Regarding the paradigm of giving VPN info on P, yes I agree with your point= , that is something to care about. Globally the solution proposed, gives a per CE view at P router (not really= per VPN) and I have some scaling concerns about it. Today I'm not pushing this kind of solution as clearly it has some issues a= nd brings concerns , I'm just interrested looking at it and see what could = be the improvement that we could provide to some premium customers. The improvement exists, but it must be clearly measured against scaling con= cern, interop with current FRR mechanism ... As we are more discussing about the solution, rather than the LDP evolution= s, I propose to move the discussion to IDR mailing list ... -----Message d'origine----- De : Ilya Varlashkin [mailto:ilya@nobulus.com]=20 Envoy=E9 : mardi 27 mars 2012 10:55 =C0 : LITKOWSKI Stephane DTF/DERX; 'IETF MPLS' Objet : RE: ahRE: [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation > -----Original Message----- > The best current available mechanism is BGP PIC Edge that relay on IGP=20 > convergence to detect that remote PE is no longer reachable : PIC Edge result > mainly depends on how fast your IGP is converging (sub sec or more). > I've been recently measuring convergence on not very fast RP and found that= even for 10 000 nodes it's less than 900ms. Clearly 10K nodes is unlikely = to be seen in many networks if in any at all. And for real-world sized nets= convergence is like few tens of ms - not really to worry about. =20 > Ahmed solution is an FRR solution so doesn't rely on convergence. As=20 > soon as > a P router detects that the link to the protected PE fails, it will=20 > switch (using > pre-programmed backup NHLFE), so there you are in FRR numbers ...=20 > 50msec > - 100msec depending of implementation ... >=20 If _P_ node needs to do fail-over to backup PE depending on VPN (L3VPN, PWE= , L2VPN etc) then _P_ node needs to have VPN-level knowledge, and that cont= radicts with original idea of P nodes (they shouldn't care what's inside, o= nly how to get to the edge independent of "payload"). > Clearly the solution is today complex, and I hope it could be a bit simplified :) > Because of previous statement I see proposed solution as complication rathe= r than simplification, and because of above mentioned IGP convergence times= the gain seems to be too little when balanced against complexity. =20 /iLya ___________________________________________________________________________= ______________________________________________ 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 authorisation. 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 is not liable for message= s that have been modified, changed or falsified. Thank you. From jgs@juniper.net Tue Mar 27 02:18:20 2012 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 D07BF21F8947 for ; Tue, 27 Mar 2012 02:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 4IaBiaa49A+2 for ; Tue, 27 Mar 2012 02:18:20 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id C800421F8946 for ; Tue, 27 Mar 2012 02:18:19 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT3GF2z0lM7aYfApam6An00KAJZspuh2b@postini.com; Tue, 27 Mar 2012 02:18:19 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 27 Mar 2012 02:16:14 -0700 From: John Scudder To: "idr@ietf.org List" Date: Tue, 27 Mar 2012 02:16:15 -0700 Thread-Topic: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-03.txt Thread-Index: Ac0L+kIFfuQRpF88QX6N13iAB42lbQ== Message-ID: <5933F2F0-30ED-4E83-9325-BD1DCBC70D04@juniper.net> References: <20120327083534.26710.594.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] Fwd: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-03.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 Mar 2012 09:18:20 -0000 FYI. --John Begin forwarded message: From: "internet-drafts@ietf.org" > Subject: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling= -03.txt Date: March 27, 2012 10:35:34 AM GMT+02:00 To: "i-d-announce@ietf.org" > Cc: "grow@ietf.org" > A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Global Routing Operations Working Gro= up of the IETF. Title : Operational Requirements for Enhanced Error Handling Beha= viour in BGP-4 Author(s) : Rob Shakir Filename : draft-ietf-grow-ops-reqs-for-bgp-error-handling-03.txt Pages : 27 Date : 2012-03-27 BGP-4 is utilised as a key intra- and inter-Autonomous System routing protocol in modern IP networks. The failure modes as defined by the original protocol standards are based on a number of assumptions around the impact of session failure. Numerous incidents both in the global Internet routing table and within Service Provider networks have been caused by strict handling of a single invalid UPDATE message causing large-scale failures in one or more Autonomous Systems. This memo describes the current use of BGP-4 within Service Provider networks, and outlines a set of requirements for further work to enhance the mechanisms available to a BGP-4 implementation when erroneous data is detected. Whilst this document does not provide specification of any standard, it is intended as an overview of a set of enhancements to BGP-4 to improve the protocol's robustness to suit its current deployment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-grow-ops-reqs-for-bgp-error-= handling-03.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-grow-ops-reqs-for-bgp-error-h= andling-03.txt _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow From internet-drafts@ietf.org Tue Mar 27 10:04:45 2012 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 3067E21E8241; Tue, 27 Mar 2012 10:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 mqI78Ka4GEtZ; Tue, 27 Mar 2012 10:04:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FEC21E8044; Tue, 27 Mar 2012 10:04:44 -0700 (PDT) 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: 4.00 Message-ID: <20120327170444.13865.64707.idtracker@ietfa.amsl.com> Date: Tue, 27 Mar 2012 10:04:44 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-issues-06.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 Mar 2012 17:04: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 : Issues in Revising BGP-4 (RFC1771 to RFC4271) Author(s) : Andrew S. Lange Filename : draft-ietf-idr-bgp-issues-06.txt Pages : 170 Date : 2012-03-27 This document records the issues discussed and the consensus reached in the Interdomain Routing (IDR) Working Group during its efforts to revise and bring up to date the base specification for the BGP-4 protocol as documented in RFC1771. The document focuses on the changes tracked from August 2002 when the last major push for revision began. The results of these efforts are encoded in RFC4271, which should be taken as normative for any of the issues that were discussed. The discussion here is intended to record how and why some of the changes to BGP were made. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-issues-06.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-issues-06.txt From robert@raszuk.net Tue Mar 27 12:35:11 2012 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 E3A3B21E80EC for ; Tue, 27 Mar 2012 12:35:11 -0700 (PDT) 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 cRXkE+rnZuy2 for ; Tue, 27 Mar 2012 12:35:11 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 207F321E80EB for ; Tue, 27 Mar 2012 12:35:10 -0700 (PDT) Received: (qmail 13776 invoked by uid 399); 27 Mar 2012 19:35:10 -0000 Received: from unknown (HELO ?10.0.1.4?) (pbs:robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPM; 27 Mar 2012 19:35:10 -0000 X-Originating-IP: 79.141.15.165 Message-ID: <4F72166F.6080503@raszuk.net> Date: Tue, 27 Mar 2012 21:35:11 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "idr@ietf.org List" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Idr] AS_SET depreciation (RFC6472) and BGP multipath 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: Tue, 27 Mar 2012 19:35:12 -0000 /In the light of just reissued draft-ietf-idr-bgp-issues-06)/ Hi, As number of BGP implementations allow for configuration of i/eBGP multipath across paths which do not have identical AS_PATH I would like to ask the list what people think is the right current BGP protocol behaviour when advertising best multipath path out ? During discussions of RFC6472 I recall a bit of discussion there on this topic, but no conclusion reached. http://www.ietf.org/mail-archive/web/idr/current/msg04512.html On the other hand http://tools.ietf.org/html/draft-ietf-idr-bgp-issues-06 in section "2.11.3. Documenting IBGP Multipath" says: If in EBGP multipath traffic is split among routers in difference AS, an aggregate SHOULD be formed so as to propagate a route with an accurate AS_PATH. If the resulting aggregate is not more specific than the components, the AS_SET SHOULD NOT be dropped. The question is what an implementation of BGP today should do when multipath is enabled, AS_SET is recommended for depreciation and no new alternative is even proposed to protect against potential loops ? Options seems to be: * Do nothing .. trust that whoever enables multipath across non identical AS_PATHs is a non-transit/stub AS and no loop will happen (ios approach) * Continue to call as_aggregate and still generate AS_SET effectively depreciating RFC6472 (quagga approach) * Propose an alternative encoding to address this case specifically for multipath use cases, but till this is deployed continue use AS_SET * Remove all knobs from shipping BGP implementations and forbid to use paths with different AS_PATH for multipath (junos approach). Regards, R. From tony.li@tony.li Tue Mar 27 13:17:00 2012 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 222B621F869E for ; Tue, 27 Mar 2012 13:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 qyD-O0dkkNF6 for ; Tue, 27 Mar 2012 13:16:59 -0700 (PDT) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3C62421F8686 for ; Tue, 27 Mar 2012 13:16:59 -0700 (PDT) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta07.emeryville.ca.mail.comcast.net with comcast id qk7W1i0021Y3wxoA7kGyJv; Tue, 27 Mar 2012 20:16:58 +0000 Received: from [10.155.34.251] ([128.107.239.233]) by omta15.emeryville.ca.mail.comcast.net with comcast id qkGn1i00X52qHCY8bkGqm8; Tue, 27 Mar 2012 20:16:56 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <4F72166F.6080503@raszuk.net> Date: Tue, 27 Mar 2012 13:16:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> References: <4F72166F.6080503@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1257) Cc: "idr@ietf.org List" Subject: Re: [Idr] AS_SET depreciation (RFC6472) and BGP multipath 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 Mar 2012 20:17:00 -0000 On Mar 27, 2012, at 12:35 PM, Robert Raszuk wrote: > Options seems to be: >=20 > * Do nothing .. trust that whoever enables multipath across non = identical AS_PATHs is a non-transit/stub AS and no loop will happen (ios = approach) >=20 > * Continue to call as_aggregate and still generate AS_SET effectively = depreciating RFC6472 (quagga approach) >=20 > * Propose an alternative encoding to address this case specifically = for multipath use cases, but till this is deployed continue use AS_SET >=20 > * Remove all knobs from shipping BGP implementations and forbid to use = paths with different AS_PATH for multipath (junos approach). Another option might be to simply concatenate AS_PATHs. Yes, this would = lose policy information and mis-represent AS topology to management = stations and the like, but it would not create any risk of looping and = would not require us to reinstitute AS_SET. Tony From robert@raszuk.net Tue Mar 27 13:57:04 2012 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 2102A21E8086 for ; Tue, 27 Mar 2012 13:57:04 -0700 (PDT) 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 o7QxK8WSKmMA for ; Tue, 27 Mar 2012 13:57:03 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 48DB621E8011 for ; Tue, 27 Mar 2012 13:57:03 -0700 (PDT) Received: (qmail 28917 invoked by uid 399); 27 Mar 2012 20:57:02 -0000 Received: from unknown (HELO ?10.0.1.4?) (pbs:robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPM; 27 Mar 2012 20:57:02 -0000 X-Originating-IP: 79.141.15.165 Message-ID: <4F7229A0.1070109@raszuk.net> Date: Tue, 27 Mar 2012 22:57:04 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Tony Li References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> In-Reply-To: <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] AS_SET depreciation (RFC6472) and BGP multipath 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: Tue, 27 Mar 2012 20:57:04 -0000 Hi Tony, >> * Propose an alternative encoding to address this case specifically >> for multipath use cases, but till this is deployed continue use >> AS_SET > > Another option might be to simply concatenate AS_PATHs. Yes, this > would lose policy information and mis-represent AS topology to > management stations and the like, but it would not create any risk of > looping and would not require us to reinstitute AS_SET. Very true. However I am not sure how that would be effectively that much different SIDR wise from issue with AS_SET ;) Said this are there any other issues with AS_SET then SIDR ? R. From jakob.heitz@ericsson.com Tue Mar 27 16:22:15 2012 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 ED0AD21F8510; Tue, 27 Mar 2012 16:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 4zm8RwEPcjw2; Tue, 27 Mar 2012 16:22:15 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 12ED921F8503; Tue, 27 Mar 2012 16:22:12 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2RNMBnw032726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Mar 2012 18:22:11 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 27 Mar 2012 19:22:11 -0400 From: Jakob Heitz To: "robert@raszuk.net" , Tony Li Date: Tue, 27 Mar 2012 19:22:09 -0400 Thread-Topic: [Idr] AS_SET depreciation (RFC6472) and BGP multipath Thread-Index: Ac0MXEbFY14+6gYCQQ+FbKUYTl2BlAAD8zSg Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> In-Reply-To: <4F7229A0.1070109@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 List" , sidr wg list Subject: Re: [Idr] AS_SET depreciation (RFC6472) and BGP multipath 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 Mar 2012 23:22:16 -0000 SIDR wise, to aggregate routes, you would have to aggregate signatures. That means to put both signatures into the aggregate and sign across the pair of them at each subsequent hop. yuck. Alternatively, send both routes and let the end user decide to use them in a multipath. Can you say ebgp add-path? -- Jakob Heitz. -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rober= t Raszuk Sent: Tuesday, March 27, 2012 1:57 PM To: Tony Li Cc: idr@ietf.org List Subject: Re: [Idr] AS_SET depreciation (RFC6472) and BGP multipath Hi Tony, >> * Propose an alternative encoding to address this case specifically >> for multipath use cases, but till this is deployed continue use >> AS_SET > > Another option might be to simply concatenate AS_PATHs. Yes, this > would lose policy information and mis-represent AS topology to > management stations and the like, but it would not create any risk of > looping and would not require us to reinstitute AS_SET. Very true. However I am not sure how that would be effectively that much=20 different SIDR wise from issue with AS_SET ;) Said this are there any other issues with AS_SET then SIDR ? R. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From stephane.litkowski@orange.com Wed Mar 28 05:09:58 2012 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 318F921E818C for ; Wed, 28 Mar 2012 05:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.512, 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 CcPuq6ZTF87m for ; Wed, 28 Mar 2012 05:09:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7C02821E8182 for ; Wed, 28 Mar 2012 05:09:56 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 8CD9318C559; Wed, 28 Mar 2012 14:09:55 +0200 (CEST) Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 728C3238059; Wed, 28 Mar 2012 14:09:55 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 14:09:55 +0200 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: Wed, 28 Mar 2012 14:09:53 +0200 Message-ID: <27841_1332936595_4F72FF93_27841_563_1_4FC3556A36EE3646A09DAA60429F5335080A2D5B@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <4F72E529.4030800@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation Thread-Index: Ac0My/4LNoRXji8nRyuw6EmO8k6gfQAC1BOw References: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com> <11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr> <17281_1332838526_4F71807E_17281_577_1_4FC3556A36EE3646A09DAA60429F53350804C77B@PUEXCBL0.nanterre.francetelecom.fr> <4F72E529.4030800@cisco.com> From: To: "Ahmed Bashandy" X-OriginalArrivalTime: 28 Mar 2012 12:09:55.0488 (UTC) FILETIME=[B010E200:01CD0CDB] X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317 Cc: idr@ietf.org Subject: Re: [Idr] [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation 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, 28 Mar 2012 12:09:58 -0000 [Moving to IDR list ...] Yes, when we are aware about FRR technics, it's clear but there is some lin= es in the doc, that could lead to understand that every P may install a rep= air ... If you are using LDP or ISIS (and especially ISIS which use flooding of LSP= ) to advertise the (NHi,rNHi) or (Nhi,rNHi,Li,Push), every P router will re= ceive the info (could not be the case with LDP ..., but it's not welle deta= illed that your LDP TLV must not be propagated upstream). I don't see somet= hing in the drafts (ISIS or BGP drafts) preventing remote P to install a ba= ckup entry ... Based on Step 4 at =A72.4 of the BGP draft, any P has a route to the BGP ne= xthop, and so is able to compute alternate path ... How do you prevent it to happen ? -----Message d'origine----- De : Ahmed Bashandy [mailto:bashandy@cisco.com]=20 Envoy=E9 : mercredi 28 mars 2012 12:17 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Jeff Tantsura; IETF MPLS Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation The basic idea behind any (IP)FRR mechanism is to have the repairing node p= er-calculate the repair path and be directly connected to the failure point= . This allows the repairing node can make quick and small local modificatio= n to the FIB so that traffic gets re-routed over the per-calculated repair = path within a guaranteed recovery period This draft, just like all (IP)FRR drafts (including those that protect mult= icast traffic), addresses the case of the repairing node being adjacent to= failing network element. Detecting a remote failure is really beyond the s= cope Thanks Ahmed On 3/27/2012 10:55 AM, stephane.litkowski@orange.com wrote: > I totally agree with your point as if the P router is not directly connec= ted to the protected PE, the solution doesn't bring any improvement compare= d to PIC Edge. > The solution as a value for a repairing P connnected to the PE and so det= ecting the failure immediately. > If the repairing P is remote to the failure, we are no more in a FRR case= ... And I think this should be prevented ... > > -----Message d'origine----- > De : Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > Envoy=E9 : mardi 27 mars 2012 10:44 > =C0 : LITKOWSKI Stephane DTF/DERX > Cc : Ilya Varlashkin; IETF MPLS > Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation > > Hi, > > The switchover AFTER the failure has been detected in both cases is: > Prefix independent - ie no RIB->FIB interactions Sub 100ms for=20 > reasonable number of primary/backup pairs > > So the real issue here is reliable and fast failure notification! > > As for this draft - if the repairing P router is not directly connected t= o the primary PE it is subject to the same limitations and would initiate s= witchover on either multihop BFD down or IGP convergence. > Even though it is presumably closer to the failure than ingress PE and co= uld react faster IMHO the complexity introduced is rather significant compa= red to the gain. > > Regards, > Jeff > > On Mar 27, 2012, at 10:21 AM, "stephane.litkowski@orange.com" wrote: > >> Ilya, >> >> The best current available mechanism is BGP PIC Edge that relay on IGP c= onvergence to detect that remote PE is no longer reachable : PIC Edge resul= t mainly depends on how fast your IGP is converging (sub sec or more). >> >> Ahmed solution is an FRR solution so doesn't rely on convergence. As soo= n as a P router detects that the link to the protected PE fails, it will sw= itch (using pre-programmed backup NHLFE), so there you are in FRR numbers .= .. 50msec - 100msec depending of implementation ... >> >> Clearly the solution is today complex, and I hope it could be a bit=20 >> simplified :) >> >> Regards, >> >> Stephane >> >> >> -----Message d'origine----- >> De : mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] De la part=20 >> de Ilya Varlashkin Envoy=E9 : mardi 27 mars 2012 10:08 =C0 : IETF MPLS= =20 >> Objet : [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation >> >> Ahmed, Kamran, >> >> as first expressed at the mic during MPLS session, I'd like to ask you f= or a clarification of the motivation behind the draft. You say that this dr= aft will provide faster switch-over/fail-over time compare to anything alre= ady existing today. Do you have some numbers for comparison? >> >> /iLya >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, 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=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> 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 is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > 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 is not liable for messa= ges that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ 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 authorisation. 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 is not liable for message= s that have been modified, changed or falsified. Thank you. From paul@jakma.org Wed Mar 28 06:10:09 2012 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 7FA9021E8239 for ; Wed, 28 Mar 2012 06:10:09 -0700 (PDT) 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 ikAz48vUnkK2 for ; Wed, 28 Mar 2012 06:10:08 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 475B121E8236 for ; Wed, 28 Mar 2012 06:10:08 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so651635wgb.13 for ; Wed, 28 Mar 2012 06:10:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=CIQJqQqh2vZe8zPV5/LnlescW8NrZxrZkxc2Dut2JCI=; b=j5mk8jgZRiZu78qWqChIQZl2L2WDX92s705nPHa2yVa52z365hxszRqoeY8H5b0TN4 W0aebTBmoJjkB9Iq6g4++sBxY91Q44iuKvOtrLUhJw1hskvBxyseCo3TAfdYrN1ti1de iWHRojw862DGFInWSpmsjPWBgYhBDLtWAYKCWxvfpxv3BLtEXnHyhsGa+MGHvfLTBViu OX5+e3Qrv5EHYKyUNuFcVWZxALXuAt1RFdV96RjJHeoa1wVwcigOQbNky3t23xKulJwd 2e6y5QgOOnBZatpTaA2pbiaY25N/HdsGQFnfmW9YKnlw+S26faESzmzDvozed6O6Zlv/ vGLw== Received: by 10.216.52.14 with SMTP id d14mr16665409wec.35.1332940207273; Wed, 28 Mar 2012 06:10:07 -0700 (PDT) Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk. [130.209.244.4]) by mx.google.com with ESMTPS id k6sm57874255wiy.7.2012.03.28.06.10.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 06:10:05 -0700 (PDT) Date: Wed, 28 Mar 2012 14:10:04 +0100 (BST) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> Message-ID: References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQlw69US8iiOGDegdbHpPJJqGYfbAvrMUxMoVPWjvZ/IcjFlVxSmr0tnjLECzMHj5MLz+hrj Cc: "idr@ietf.org List" , Tony Li , "robert@raszuk.net" , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 13:10:09 -0000 On Tue, 27 Mar 2012, Jakob Heitz wrote: > Alternatively, send both routes and let the end user decide to use them > in a multipath. Can you say ebgp add-path? Where's the document to describe how to do multi-pathing using add-path? E.g. what should happen when there is a non-add-path capable neighbour? regards, -- Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: The Second Law of Thermodynamics: If you think things are in a mess now, just wait! -- Jim Warner From jakob.heitz@ericsson.com Wed Mar 28 07:11:40 2012 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 324D721E8266; Wed, 28 Mar 2012 07:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.135, 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 AAWtHhoLaIo8; Wed, 28 Mar 2012 07:11:39 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D3E7C21E8262; Wed, 28 Mar 2012 07:11:38 -0700 (PDT) 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 q2SEBMgv026611; Wed, 28 Mar 2012 09:11:38 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 28 Mar 2012 10:11:22 -0400 From: Jakob Heitz To: Paul Jakma Date: Wed, 28 Mar 2012 10:11:20 -0400 Thread-Topic: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath Thread-Index: Ac0M5BoLhVc0G6SbQBC7uJyOppR6xgACFkDQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , Tony Li , "robert@raszuk.net" , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 14:11:40 -0000 I don't know. I'm just throwing ideas around. However, it appears that inter AS multipath has a lot of problems. -- Jakob Heitz. -----Original Message----- From: Paul Jakma [mailto:paul@jakma.org]=20 Sent: Wednesday, March 28, 2012 6:10 AM To: Jakob Heitz Cc: robert@raszuk.net; Tony Li; idr@ietf.org List; sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath On Tue, 27 Mar 2012, Jakob Heitz wrote: > Alternatively, send both routes and let the end user decide to use them=20 > in a multipath. Can you say ebgp add-path? Where's the document to describe how to do multi-pathing using add-path?=20 E.g. what should happen when there is a non-add-path capable neighbour? regards, --=20 Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: The Second Law of Thermodynamics: If you think things are in a mess now, just wait! -- Jim Warner From robert@raszuk.net Wed Mar 28 07:32:01 2012 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 259E021E8101 for ; Wed, 28 Mar 2012 07:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[AWL=-0.558, 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 us78W6D4Pkwc for ; Wed, 28 Mar 2012 07:32:00 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 08EB421F88BB for ; Wed, 28 Mar 2012 07:32:00 -0700 (PDT) Received: (qmail 27352 invoked by uid 399); 28 Mar 2012 14:31:59 -0000 Received: from unknown (HELO ?10.0.1.3?) (robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPAM; 28 Mar 2012 14:31:59 -0000 X-Originating-IP: 79.141.15.165 References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> Mime-Version: 1.0 (iPad Mail 8L1) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8L1) From: Robert Raszuk Date: Wed, 28 Mar 2012 16:32:01 +0200 To: Jakob Heitz Cc: "idr@ietf.org List" , Tony Li , Paul Jakma , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 14:32:01 -0000 Jakob, The issue is also about intra-as ibgp multipath not inter-as one. Observe th= at data usually flows into opposite direction then routing ;) Cheers, R. On 28 mar 2012, at 16:11, Jakob Heitz wrote: > I don't know. I'm just throwing ideas around. > However, it appears that inter AS multipath > has a lot of problems. >=20 > -- > Jakob Heitz. >=20 > -----Original Message----- > From: Paul Jakma [mailto:paul@jakma.org]=20 > Sent: Wednesday, March 28, 2012 6:10 AM > To: Jakob Heitz > Cc: robert@raszuk.net; Tony Li; idr@ietf.org List; sidr wg list > Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath >=20 > On Tue, 27 Mar 2012, Jakob Heitz wrote: >=20 >> Alternatively, send both routes and let the end user decide to use them=20= >> in a multipath. Can you say ebgp add-path? >=20 > Where's the document to describe how to do multi-pathing using add-path?=20= > E.g. what should happen when there is a non-add-path capable neighbour? >=20 > regards, > --=20 > Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A > Fortune: > The Second Law of Thermodynamics: > If you think things are in a mess now, just wait! > -- Jim Warner > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Wed Mar 28 07:57:05 2012 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 264F621F87C7; Wed, 28 Mar 2012 07:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 2cQOkXFeZIxS; Wed, 28 Mar 2012 07:57:04 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 777BA21F87BE; Wed, 28 Mar 2012 07:57:04 -0700 (PDT) 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 q2SEutHX006286; Wed, 28 Mar 2012 09:57:03 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 28 Mar 2012 10:56:54 -0400 From: Jakob Heitz To: Robert Raszuk Date: Wed, 28 Mar 2012 10:56:52 -0400 Thread-Topic: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath Thread-Index: Ac0M75QQymtUp79iSAiomQKXD5VYPgAAk1/g Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , Tony Li , Paul Jakma , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 14:57:05 -0000 The issue is SIDR can not aggregate multiple paths. Solutions I can think of: 1. Aggregate the signatures of the paths being aggregated. 2. Don't aggregate, but send both paths.=20 Should SIDR work on path aggregation? Are there other possibilities? -- Jakob Heitz. -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net]=20 Sent: Wednesday, March 28, 2012 7:32 AM To: Jakob Heitz Cc: Paul Jakma; idr@ietf.org List; Tony Li; sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath Jakob, The issue is also about intra-as ibgp multipath not inter-as one. Observe t= hat data usually flows into opposite direction then routing ;) Cheers, R. On 28 mar 2012, at 16:11, Jakob Heitz wrote: > I don't know. I'm just throwing ideas around. > However, it appears that inter AS multipath > has a lot of problems. >=20 > -- > Jakob Heitz. >=20 > -----Original Message----- > From: Paul Jakma [mailto:paul@jakma.org]=20 > Sent: Wednesday, March 28, 2012 6:10 AM > To: Jakob Heitz > Cc: robert@raszuk.net; Tony Li; idr@ietf.org List; sidr wg list > Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath >=20 > On Tue, 27 Mar 2012, Jakob Heitz wrote: >=20 >> Alternatively, send both routes and let the end user decide to use them= =20 >> in a multipath. Can you say ebgp add-path? >=20 > Where's the document to describe how to do multi-pathing using add-path?= =20 > E.g. what should happen when there is a non-add-path capable neighbour? >=20 > regards, > --=20 > Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A > Fortune: > The Second Law of Thermodynamics: > If you think things are in a mess now, just wait! > -- Jim Warner > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From paul@jakma.org Wed Mar 28 09:01:22 2012 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 C061D21F8962 for ; Wed, 28 Mar 2012 09:01:22 -0700 (PDT) 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 EIn7wqmQXbG1 for ; Wed, 28 Mar 2012 09:01:22 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 03F2421F895D for ; Wed, 28 Mar 2012 09:01:21 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so4376605wgb.1 for ; Wed, 28 Mar 2012 09:01:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=+0uEIwsMFKU/8VVCBL7rWE6RgIDCxky52XrXsP6gagY=; b=bPe/ZzXwtj3vq/JeWFkTNCEZwmgCAp6IKd1Cu6mOJZkiLK+K8hEVEjvQRrqW6ZRupd gL7Xdo6jxD3X1M4p7g197eYvB530uobyIpS1Vq78MFP4Aprudpaz6SSG7+l7G1WTRZqG PWPmjZb6bAJawH0eHxqgeyuT3qb4tq4IDGEJVWKhR6DeWMc65iRdcNY7QiQPXwxK4E8c 8QONu62/sDvwYRF8cfS1vmkeWNzcMqM6Xz3OyIIEmqpQEZzi5jp1n8bt4m47bAEd6ZM/ r4KZWzvHB6zDFyMr6jwSDwzxRzyhOryMZk8kqnH+fMB/B21eqjBmzDFBhX3OrmOgP3Gs NweQ== Received: by 10.216.137.74 with SMTP id x52mr17906962wei.77.1332950480973; Wed, 28 Mar 2012 09:01:20 -0700 (PDT) Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk. [130.209.244.4]) by mx.google.com with ESMTPS id n8sm14872598wix.10.2012.03.28.09.01.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 09:01:20 -0700 (PDT) Date: Wed, 28 Mar 2012 17:01:18 +0100 (BST) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> Message-ID: References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQl1ujOaw0YY6+muriwSq7kQaXQzRPijxg5aABDBmNrrxrwNDg+7W1s65pJQWTXeveUL8CfP Cc: "idr@ietf.org List" , Tony Li , Robert Raszuk , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 16:01:22 -0000 On Wed, 28 Mar 2012, Jakob Heitz wrote: > The issue is SIDR can not aggregate multiple paths. > Should SIDR work on path aggregation? If we ever want to make routing state scale sub-linearly (i.e. make IDR "compact") in the size of the internet, then we're almost certainly going to need some form of conglomeration of routing information in some shape or form. Still having support for aggregation in BGP could then be useful. It'd be a shame if we ended up having to choose between scalable and secure routing. (OTOH scalable routing is potentially so far off in the future, and might be so different, that it's hard to say what level of extra engineering or overhead, if any would be justified for SIDR). regards, -- Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: COBOL: Completely Over and Beyond reason Or Logic. From christopher.morrow@gmail.com Wed Mar 28 09:15:17 2012 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 9601A21E808F; Wed, 28 Mar 2012 09:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.556 X-Spam-Level: X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 hLQa7CyKoG2f; Wed, 28 Mar 2012 09:15:16 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9892F21E8135; Wed, 28 Mar 2012 09:15:16 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1789638obb.31 for ; Wed, 28 Mar 2012 09:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BOnqtymFmnekG3Q1PIOEh3AuqVm+jnz08U/tIOi/SDY=; b=BTJGwQ1jxmhIic+rMUaeQ3yzoZJochqSDwFFpzmtsyjA/rgRwa4sGkhlDDtSgLA6PX XrafDYFIlDnGxuIBMrdGmGQiQURKABytJ6mHMmfT9y4JByQqxbo/2LhtdxEU5IGIxFY5 E7IVHvYl+XG66xmf6Kunx4xcusnonH9nvovB0caz7ux2I/QvH/7vqaSKRPlv93PILurw qWJIGjsFZBU0xlvOlmHKcqmU7RUW0sr0T/BnBNDC4cbSrl4IHYCzI9ex4SLVZmE+fLkj LcAHTj3tfl0LPCUMqru44RjPojeWoHxxOuD0Vec1Plv4QiJ5951zlhk4ShwwYdKXfv4K ZoKw== MIME-Version: 1.0 Received: by 10.182.147.106 with SMTP id tj10mr38891209obb.71.1332951316187; Wed, 28 Mar 2012 09:15:16 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 09:15:16 -0700 (PDT) In-Reply-To: References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 28 Mar 2012 12:15:16 -0400 X-Google-Sender-Auth: NpVjtzScSQGFCmEAe1ifE7dHgEI Message-ID: From: Christopher Morrow To: Paul Jakma Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" , Tony Li , Robert Raszuk , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 16:15:17 -0000 On Wed, Mar 28, 2012 at 12:01 PM, Paul Jakma wrote: > On Wed, 28 Mar 2012, Jakob Heitz wrote: > >> The issue is SIDR can not aggregate multiple paths. > > >> Should SIDR work on path aggregation? > > > If we ever want to make routing state scale sub-linearly (i.e. make IDR > "compact") in the size of the internet, then we're almost certainly going to > need some form of conglomeration of routing information in some shape or > form. Still having support for aggregation in BGP could then be useful. or we could have fixed the problem with locator/id separation... oh well. > > It'd be a shame if we ended up having to choose between scalable and secure > routing. it's hardly a choice of one or the other, framing the question in this manner is a 'suckers choice'. It's certianly possible that at some point when aggregation between AS's becomes used properly and effectively... someone will figure out the security properties if this configuration. > (OTOH scalable routing is potentially so far off in the future, and might be > so different, that it's hard to say what level of extra engineering or > overhead, if any would be justified for SIDR). it seems that to date, folk can't seem to figure out the aggregation bits, maybe that will change in the future. -chris From robert@raszuk.net Wed Mar 28 09:29:46 2012 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 4F61721E81BE for ; Wed, 28 Mar 2012 09:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 Txw2xkAfh5SQ for ; Wed, 28 Mar 2012 09:29:45 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5BF21E8191 for ; Wed, 28 Mar 2012 09:29:44 -0700 (PDT) Received: (qmail 29028 invoked by uid 399); 28 Mar 2012 16:29:44 -0000 Received: from unknown (HELO ?10.0.1.4?) (pbs:robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPM; 28 Mar 2012 16:29:44 -0000 X-Originating-IP: 79.141.15.165 Message-ID: <4F733C79.8080600@raszuk.net> Date: Wed, 28 Mar 2012 18:29:45 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , Tony Li , Paul Jakma , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 16:29:46 -0000 Chris, > it seems that to date, folk can't seem to figure out the aggregation > bits, maybe that will change in the future. Let me point out that IBGP multipath is used very commonly today. When you do that you need to advertise something meaningful out to your neighbors. Yes that is open IDR topic no one seems to be actively working on. However let's not block any work on it just because SIDR can not handle some solutions. Are we going to freeze any AS_PATH modifications by operator's policy too ? I mentioned replace-as which all major vendors support. There can be more knobs like this coming in the future. CDNI is just getting extended to BGP (new SAFI) and they have their own uses for AS_PATH being sort of over the top of classic ASes. Regards, R. From jakob.heitz@ericsson.com Wed Mar 28 09:35:29 2012 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 C3E6721F8876 for ; Wed, 28 Mar 2012 09:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 UHGn7LvTzUj3 for ; Wed, 28 Mar 2012 09:35:28 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B0B0621F8873 for ; Wed, 28 Mar 2012 09:35:28 -0700 (PDT) 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 q2SGZQ67001093; Wed, 28 Mar 2012 11:35:28 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 28 Mar 2012 12:35:21 -0400 From: Jakob Heitz To: Ahmed Bashandy Date: Wed, 28 Mar 2012 12:35:18 -0400 Thread-Topic: [Idr] [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation Thread-Index: Ac0My/4LNoRXji8nRyuw6EmO8k6gfQAC1BOwAAovX8A= Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFDA43@EUSAACMS0701.eamcs.ericsson.se> References: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com> <11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr> <17281_1332838526_4F71807E_17281_577_1_4FC3556A36EE3646A09DAA60429F53350804C77B@PUEXCBL0.nanterre.francetelecom.fr> <4F72E529.4030800@cisco.com> <27841_1332936595_4F72FF93_27841_563_1_4FC3556A36EE3646A09DAA60429F5335080A2D5B@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <27841_1332936595_4F72FF93_27841_563_1_4FC3556A36EE3646A09DAA60429F5335080A2D5B@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation 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, 28 Mar 2012 16:35:29 -0000 Ahmed, BGP PIC Edge is not the only existing solution. Look at "5.1.8.4.1. Anycast BGP applied to ABR node failure" in http://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-01 That looks much simpler. How is yours better than this? -- Jakob Heitz. -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of steph= ane.litkowski@orange.com Sent: Wednesday, March 28, 2012 5:10 AM To: Ahmed Bashandy Cc: idr@ietf.org Subject: Re: [Idr] [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivati= on [Moving to IDR list ...] Yes, when we are aware about FRR technics, it's clear but there is some lin= es in the doc, that could lead to understand that every P may install a rep= air ... If you are using LDP or ISIS (and especially ISIS which use flooding of LSP= ) to advertise the (NHi,rNHi) or (Nhi,rNHi,Li,Push), every P router will re= ceive the info (could not be the case with LDP ..., but it's not welle deta= illed that your LDP TLV must not be propagated upstream). I don't see somet= hing in the drafts (ISIS or BGP drafts) preventing remote P to install a ba= ckup entry ... Based on Step 4 at =A72.4 of the BGP draft, any P has a route to the BGP ne= xthop, and so is able to compute alternate path ... How do you prevent it to happen ? -----Message d'origine----- De : Ahmed Bashandy [mailto:bashandy@cisco.com]=20 Envoy=E9 : mercredi 28 mars 2012 12:17 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Jeff Tantsura; IETF MPLS Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation The basic idea behind any (IP)FRR mechanism is to have the repairing node p= er-calculate the repair path and be directly connected to the failure point= . This allows the repairing node can make quick and small local modificatio= n to the FIB so that traffic gets re-routed over the per-calculated repair = path within a guaranteed recovery period This draft, just like all (IP)FRR drafts (including those that protect mult= icast traffic), addresses the case of the repairing node being adjacent to= failing network element. Detecting a remote failure is really beyond the s= cope Thanks Ahmed On 3/27/2012 10:55 AM, stephane.litkowski@orange.com wrote: > I totally agree with your point as if the P router is not directly connec= ted to the protected PE, the solution doesn't bring any improvement compare= d to PIC Edge. > The solution as a value for a repairing P connnected to the PE and so det= ecting the failure immediately. > If the repairing P is remote to the failure, we are no more in a FRR case= ... And I think this should be prevented ... > > -----Message d'origine----- > De : Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > Envoy=E9 : mardi 27 mars 2012 10:44 > =C0 : LITKOWSKI Stephane DTF/DERX > Cc : Ilya Varlashkin; IETF MPLS > Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation > > Hi, > > The switchover AFTER the failure has been detected in both cases is: > Prefix independent - ie no RIB->FIB interactions Sub 100ms for=20 > reasonable number of primary/backup pairs > > So the real issue here is reliable and fast failure notification! > > As for this draft - if the repairing P router is not directly connected t= o the primary PE it is subject to the same limitations and would initiate s= witchover on either multihop BFD down or IGP convergence. > Even though it is presumably closer to the failure than ingress PE and co= uld react faster IMHO the complexity introduced is rather significant compa= red to the gain. > > Regards, > Jeff > > On Mar 27, 2012, at 10:21 AM, "stephane.litkowski@orange.com" wrote: > >> Ilya, >> >> The best current available mechanism is BGP PIC Edge that relay on IGP c= onvergence to detect that remote PE is no longer reachable : PIC Edge resul= t mainly depends on how fast your IGP is converging (sub sec or more). >> >> Ahmed solution is an FRR solution so doesn't rely on convergence. As soo= n as a P router detects that the link to the protected PE fails, it will sw= itch (using pre-programmed backup NHLFE), so there you are in FRR numbers .= .. 50msec - 100msec depending of implementation ... >> >> Clearly the solution is today complex, and I hope it could be a bit=20 >> simplified :) >> >> Regards, >> >> Stephane >> >> >> -----Message d'origine----- >> De : mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] De la part=20 >> de Ilya Varlashkin Envoy=E9 : mardi 27 mars 2012 10:08 =C0 : IETF MPLS=20 >> Objet : [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation >> >> Ahmed, Kamran, >> >> as first expressed at the mic during MPLS session, I'd like to ask you f= or a clarification of the motivation behind the draft. You say that this dr= aft will provide faster switch-over/fail-over time compare to anything alre= ady existing today. Do you have some numbers for comparison? >> >> /iLya >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, 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=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> 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 is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > 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 is not liable for messa= ges that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ 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 authorisation. 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 is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From christopher.morrow@gmail.com Wed Mar 28 09:38:18 2012 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 23BBC21E8234; Wed, 28 Mar 2012 09:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.557 X-Spam-Level: X-Spam-Status: No, score=-103.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 IP-C1YOmCwY5; Wed, 28 Mar 2012 09:38:17 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6410521E8191; Wed, 28 Mar 2012 09:38:10 -0700 (PDT) Received: by ghbg16 with SMTP id g16so973430ghb.31 for ; Wed, 28 Mar 2012 09:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5fbmyIaMKqeSwebjDiIbQam1/AAH6jiqpPOUKR7Bu/M=; b=ouOwJkG2+KvHL6OFhBK/ItUPZ8I0kL3tuWgur85OCHG4sQVBzOwIWaATvWorgat6dl NLMeWeDdLijl+ae86qUF8Z9ozBzlb95+fu9vvDcyFEp0MFX2e50m2H5YKVgQSFBAcJEf 0TxCwkRaLA3+0yz64ygkgPssph4ZU4eWhdmQdyUo2kPBDWRmi1vvJidjGgYbSF6jECyR cuhEM3wqadSYsbXvMK7HpNWfyyJyMs+vLpLe3ArLSAE6pC11pb+1SRGbCFJqNCiuHNnR 57ZitNMzSBQ9pv1IjQz2YpqttPWi4D20Xsk4F37pgk3x/5DMCR4fr6fm/iQgXwEYiSSa QXOg== MIME-Version: 1.0 Received: by 10.60.24.164 with SMTP id v4mr35010478oef.51.1332952689874; Wed, 28 Mar 2012 09:38:09 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 09:38:09 -0700 (PDT) In-Reply-To: <4F733C79.8080600@raszuk.net> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> Date: Wed, 28 Mar 2012 12:38:09 -0400 X-Google-Sender-Auth: kUkfbJ7WVX0vuV2p82qTCnfRrLg Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" , Tony Li , Paul Jakma , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 16:38:18 -0000 On Wed, Mar 28, 2012 at 12:29 PM, Robert Raszuk wrote: > Are we going to freeze any AS_PATH modifications by operator's policy too ? > I mentioned replace-as which all major vendors support. There can be more > knobs like this coming in the future. replace as i think is dealt with .... sign again and pcount=0 and move along. > CDNI is just getting extended to BGP (new SAFI) and they have their own uses > for AS_PATH being sort of over the top of classic ASes. good for them? From robert@raszuk.net Wed Mar 28 09:43:45 2012 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 30C1121E825A for ; Wed, 28 Mar 2012 09:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 wX-9AP3uVHmB for ; Wed, 28 Mar 2012 09:43:44 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 41BF121E80F3 for ; Wed, 28 Mar 2012 09:43:44 -0700 (PDT) Received: (qmail 15704 invoked by uid 399); 28 Mar 2012 16:43:41 -0000 Received: from unknown (HELO ?10.0.1.4?) (pbs:robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPM; 28 Mar 2012 16:43:41 -0000 X-Originating-IP: 79.141.15.165 Message-ID: <4F733FBE.1020902@raszuk.net> Date: Wed, 28 Mar 2012 18:43:42 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , Tony Li , Paul Jakma , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 16:43:45 -0000 >> Are we going to freeze any AS_PATH modifications by operator's policy too ? >> I mentioned replace-as which all major vendors support. There can be more >> knobs like this coming in the future. > > replace as i think is dealt with .... sign again and pcount=0 and move along. replace-as allows to replace any arbitrary match of list of ASes in the AS_PATH by your own AS. Does not need to be the last one. I don't think SIDR has a solution to deal with such policy. Best regards, R. From christopher.morrow@gmail.com Wed Mar 28 09:45:23 2012 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 DE24C21E8268; Wed, 28 Mar 2012 09:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.558 X-Spam-Level: X-Spam-Status: No, score=-103.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 F87qYz3idpXk; Wed, 28 Mar 2012 09:45:23 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4279421E80F3; Wed, 28 Mar 2012 09:45:23 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1825007obb.31 for ; Wed, 28 Mar 2012 09:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+Ge5LcT3qUg4DbDJxMmS/8vUJ2+NlGYHLRryBPreCUE=; b=CivTklSivROsZ5zFWSoSGTbXqSsgolTs+gOTymKrXguT49sP//8LbfI7W5BNNd0Tu8 0FybenzJn4BONWakmhDkqrCRnmZCAxzorI7jDYhYBkScPplp3jjYs8TCxNzZ0F9xa/lW Tzmblaz0w6XV4Oig1UkptT2moLbMnXCGGG2b9QOc0LqjWbnvDXsoD7whp4ZDL2QXOkta 5af0o+9lwXZkZoisdVcDG4k8CvS/NhbNnN9SyQTFMYau/486HaCzqvf/vP6FbQi4nxjU 3RwI4Jun2AmxChyoQq0CUCthNkL8YNMHmiZgUAhAa3EBvcxD/kOgpt68xWxtXzRWLnSU 8f2A== MIME-Version: 1.0 Received: by 10.182.155.68 with SMTP id vu4mr38456879obb.61.1332953122839; Wed, 28 Mar 2012 09:45:22 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 09:45:22 -0700 (PDT) In-Reply-To: <4F733FBE.1020902@raszuk.net> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> Date: Wed, 28 Mar 2012 12:45:22 -0400 X-Google-Sender-Auth: -ZUr_-v_m2YbAL2MLLYop-shfa8 Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" , Tony Li , Paul Jakma , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 16:45:24 -0000 On Wed, Mar 28, 2012 at 12:43 PM, Robert Raszuk wrote: > >>> Are we going to freeze any AS_PATH modifications by operator's policy too >>> ? >>> I mentioned replace-as which all major vendors support. There can be more >>> knobs like this coming in the future. >> >> >> replace as i think is dealt with .... sign again and pcount=0 and move >> along. > > > replace-as allows to replace any arbitrary match of list of ASes in the > AS_PATH by your own AS. Does not need to be the last one. ah yes, was thinking of local-as. the 'replace-as' seems like loop-creation, joy. > I don't think SIDR has a solution to deal with such policy. nope, seems crazy though:) (to use it I mean) From heas@shrubbery.net Wed Mar 28 10:30:11 2012 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 B6B1221E809E; Wed, 28 Mar 2012 10:30:11 -0700 (PDT) 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 95BuxumnM2qD; Wed, 28 Mar 2012 10:30:10 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB5421E804A; Wed, 28 Mar 2012 10:30:10 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 673F888B42; Wed, 28 Mar 2012 17:30:10 +0000 (UTC) Date: Wed, 28 Mar 2012 17:30:10 +0000 From: heasley To: "Murphy, Sandra" Message-ID: <20120328173010.GB72348@shrubbery.net> References: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB73F@Hermes.columbia.ads.sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB73F@Hermes.columbia.ads.sparta.com> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "idr@ietf.org List" , Paul Jakma , "robert@raszuk.net" , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 17:30:11 -0000 Wed, Mar 28, 2012 at 05:00:43PM +0000, Murphy, Sandra: > Replacing ASs in the AS_PATH sounds like a behavior you would want the security protections to prohibit. It would enable attacks. > > Can you explain how you would distinguish legitimate uses of this feature? I've not used this feature, but from cisco's documentation, it doesnt appear to function as raszuk described. http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gtbgpdas.html if local-as is configured for a peer(-group), ie: if configured to peer as a different AS than your own, such as for merging two ASes or changing your ASN, then: "The replace-as keyword is used to prepend only the local autonomous-system number (as configured with the ip-address argument) to the AS_PATH attribute. The autonomous-system number from the local BGP routing process is not prepended." though I think that is unclear, I interpret it to mean that if my ASN is 1 and, I peer as ASN 2 with ebgp peer 3, then a route received from AS 3 will have the path [2 3], but if configured with replace-as, it will be [3]. I do not believe that the feature allows the arbitrary replacement of AS path elements. > --Sandy > > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Robert Raszuk [robert@raszuk.net] > Sent: Wednesday, March 28, 2012 12:43 PM > To: Christopher Morrow > Cc: idr@ietf.org List; Paul Jakma; sidr wg list > Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath > > >> Are we going to freeze any AS_PATH modifications by operator's policy too ? > >> I mentioned replace-as which all major vendors support. There can be more > >> knobs like this coming in the future. > > > > replace as i think is dealt with .... sign again and pcount=0 and move along. > > replace-as allows to replace any arbitrary match of list of ASes in the > AS_PATH by your own AS. Does not need to be the last one. > > I don't think SIDR has a solution to deal with such policy. > > Best regards, > R. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From robert@raszuk.net Wed Mar 28 13:07:10 2012 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 DA18B21F864B for ; Wed, 28 Mar 2012 13:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 Ef+qCHKR4wiU for ; Wed, 28 Mar 2012 13:07:10 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B3B1521F8623 for ; Wed, 28 Mar 2012 13:07:09 -0700 (PDT) Received: (qmail 15980 invoked by uid 399); 28 Mar 2012 20:07:09 -0000 Received: from unknown (HELO ?10.0.1.4?) (pbs:robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPM; 28 Mar 2012 20:07:09 -0000 X-Originating-IP: 79.141.15.165 Message-ID: <4F736F6E.70205@raszuk.net> Date: Wed, 28 Mar 2012 22:07:10 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , Tony Li , Paul Jakma , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 20:07:11 -0000 > the 'replace-as' seems like > loop-creation, joy. Nope. No loops at least in one implementation ... the implementation mandates that you insert your own AS - that is not optional. Rgs, R. From robert@raszuk.net Wed Mar 28 13:23:35 2012 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 EB52121E8083 for ; Wed, 28 Mar 2012 13:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 uB4TjonCxEPM for ; Wed, 28 Mar 2012 13:23:35 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id E897221E8019 for ; Wed, 28 Mar 2012 13:23:34 -0700 (PDT) Received: (qmail 10182 invoked by uid 399); 28 Mar 2012 20:23:34 -0000 Received: from unknown (HELO ?10.0.1.4?) (pbs:robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPM; 28 Mar 2012 20:23:34 -0000 X-Originating-IP: 79.141.15.165 Message-ID: <4F737347.4040206@raszuk.net> Date: Wed, 28 Mar 2012 22:23:35 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: heasley , "Murphy, Sandra" References: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB73F@Hermes.columbia.ads.sparta.com> <20120328173010.GB72348@shrubbery.net> In-Reply-To: <20120328173010.GB72348@shrubbery.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 20:23:36 -0000 > it doesnt appear to function as raszuk described. Let me point out that heasley is looking at completely different knob which has nothing to do with replace as path policy extension. The correct pointer is: http://goo.gl/xVToJ Rgs, R. > Wed, Mar 28, 2012 at 05:00:43PM +0000, Murphy, Sandra: >> Replacing ASs in the AS_PATH sounds like a behavior you would want the security protections to prohibit. It would enable attacks. >> >> Can you explain how you would distinguish legitimate uses of this feature? > > I've not used this feature, but from cisco's documentation, it doesnt appear > to function as raszuk described. > > http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gtbgpdas.html > > if local-as is configured for a peer(-group), ie: if configured to peer as > a different AS than your own, such as for merging two ASes or changing your > ASN, then: > "The replace-as keyword is used to prepend only the local autonomous-system number (as configured with the ip-address argument) to the AS_PATH attribute. The autonomous-system number from the local BGP routing process is not prepended." > > though I think that is unclear, I interpret it to mean that if my ASN is 1 > and, I peer as ASN 2 with ebgp peer 3, then a route received from AS 3 will > have the path [2 3], but if configured with replace-as, it will be [3]. > > I do not believe that the feature allows the arbitrary replacement of AS path > elements. > >> --Sandy >> >> ________________________________________ >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Robert Raszuk [robert@raszuk.net] >> Sent: Wednesday, March 28, 2012 12:43 PM >> To: Christopher Morrow >> Cc: idr@ietf.org List; Paul Jakma; sidr wg list >> Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath >> >>>> Are we going to freeze any AS_PATH modifications by operator's policy too ? >>>> I mentioned replace-as which all major vendors support. There can be more >>>> knobs like this coming in the future. >>> >>> replace as i think is dealt with .... sign again and pcount=0 and move along. >> >> replace-as allows to replace any arbitrary match of list of ASes in the >> AS_PATH by your own AS. Does not need to be the last one. >> >> I don't think SIDR has a solution to deal with such policy. >> >> Best regards, >> R. >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From brian.peter.dickson@gmail.com Wed Mar 28 13:25:08 2012 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 7B11921E802A; Wed, 28 Mar 2012 13:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 RgfpNrj7+kJr; Wed, 28 Mar 2012 13:25:08 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 941C521E8019; Wed, 28 Mar 2012 13:25:07 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so4570386wgb.1 for ; Wed, 28 Mar 2012 13:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6nR4oM1o2kq+HyP99ZpUw+NjW2V8m5esmLE2iXfHQ3I=; b=O0h0RjTM8eDyLASb2X2ph5Z79QDXDZf6AcxT2RpEKt5tMDY53nEg7baXRAzA90oumh g2Wxi//nJtc1zz/1jZh/rQNpGBQMndroRBuLucBDDkLSiT/z9BXwLDWvyCD6aqsTSE+g Tv5/GtWcXJSBD1Vam/CCEYZQ4R1QEDR/h6X23bJG5Gn9ns0D6nCBYSTYL8TPdDGGqATz NCclu8YxcPIZRxQAmA/21ezX1G5OCeC5OCELXCdFbuBy6djBDIJ2pTlpY5FKpDhi59M8 JIjFDG5a95gDNjJfax3ZDVbuMuYz+UrqmagSMl0dorzXt1gugm8Q3urFsFWI0LkyoKZZ NGvg== MIME-Version: 1.0 Received: by 10.216.133.93 with SMTP id p71mr18501949wei.10.1332966306719; Wed, 28 Mar 2012 13:25:06 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Wed, 28 Mar 2012 13:25:06 -0700 (PDT) In-Reply-To: <4F736F6E.70205@raszuk.net> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> <4F736F6E.70205@raszuk.net> Date: Wed, 28 Mar 2012 16:25:06 -0400 Message-ID: From: Brian Dickson To: robert@raszuk.net Content-Type: multipart/alternative; boundary=0016e6dbde5735a74d04bc536740 Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 20:25:08 -0000 --0016e6dbde5735a74d04bc536740 Content-Type: text/plain; charset=ISO-8859-1 Arbitrary AS substitution allows loop creation, even if your own AS is required. All that is needed, is multiple instances of replace-as in the loop. Suppose A replaces B C D with A E F. Suppose B replaces G A with B C D. A received B C D, sends A E F to G. G sends G A E F to B. B sends B C D E F to A. We have a loop, which eventually results in path overflow with E F E F E F etc. at the end of it. On Wed, Mar 28, 2012 at 4:07 PM, Robert Raszuk wrote: > > the 'replace-as' seems like >> loop-creation, joy. >> > > Nope. No loops at least in one implementation ... the implementation > mandates that you insert your own AS - that is not optional. > > Rgs, > R. > > ______________________________**_________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/**listinfo/sidr > --0016e6dbde5735a74d04bc536740 Content-Type: text/html; charset=ISO-8859-1 Arbitrary AS substitution allows loop creation, even if your own AS is required.

All that is needed, is multiple instances of replace-as in the loop.

Suppose A replaces B C D with A E F.

Suppose B replaces G A with B C D.

A received B C D, sends A E F to G.

G sends G A E F to B.
B sends B C D E F to A.

We have a loop, which eventually results in path overflow with E F E F E F etc. at the end of it.

On Wed, Mar 28, 2012 at 4:07 PM, Robert Raszuk <robert@raszuk.net> wrote:

the 'replace-as' seems like
loop-creation, joy.

Nope. No loops at least in one implementation ... the implementation mandates that you insert your own AS - that is not optional.

Rgs,
R.

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

--0016e6dbde5735a74d04bc536740-- From robert@raszuk.net Wed Mar 28 13:30:34 2012 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 7FC1621F87D6 for ; Wed, 28 Mar 2012 13:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 296NdnydAsO2 for ; Wed, 28 Mar 2012 13:30:34 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id C1CD821F8862 for ; Wed, 28 Mar 2012 13:30:32 -0700 (PDT) Received: (qmail 4324 invoked by uid 399); 28 Mar 2012 20:30:25 -0000 Received: from unknown (HELO ?10.0.1.4?) (pbs:robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPM; 28 Mar 2012 20:30:25 -0000 X-Originating-IP: 79.141.15.165 Message-ID: <4F7374DD.7060301@raszuk.net> Date: Wed, 28 Mar 2012 22:30:21 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Brian Dickson References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> <4F736F6E.70205@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 20:30:34 -0000 Brian, The customer's workaround was to erase entire AS_PATH via redistribution. I am not saying that use of this knob is safe. I am saying that it exists in shipping implementations and simply asking what SIDR behaviour should be when such policy is present. That's all. Best, R. > Arbitrary AS substitution allows loop creation, even if your own AS is > required. > > All that is needed, is multiple instances of replace-as in the loop. > > Suppose A replaces B C D with A E F. > > Suppose B replaces G A with B C D. > > A received B C D, sends A E F to G. > > G sends G A E F to B. > B sends B C D E F to A. > > We have a loop, which eventually results in path overflow with E F E F E > F etc. at the end of it. > > On Wed, Mar 28, 2012 at 4:07 PM, Robert Raszuk > wrote: > > > the 'replace-as' seems like > loop-creation, joy. > > > Nope. No loops at least in one implementation ... the implementation > mandates that you insert your own AS - that is not optional. > > Rgs, > R. > > _________________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/__listinfo/sidr > > > From jhaas@slice.pfrc.org Wed Mar 28 13:55:24 2012 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 2F0A221F883D; Wed, 28 Mar 2012 13:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.157 X-Spam-Level: X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 b+E4f+r9d83I; Wed, 28 Mar 2012 13:55:23 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9F42121F8833; Wed, 28 Mar 2012 13:55:23 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8F76C170425; Wed, 28 Mar 2012 16:55:22 -0400 (EDT) Date: Wed, 28 Mar 2012 16:55:22 -0400 From: Jeffrey Haas To: Christopher Morrow Message-ID: <20120328205522.GA16814@slice> References: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" , Tony Li , Paul Jakma , robert@raszuk.net, sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 20:55:24 -0000 Chris, On Wed, Mar 28, 2012 at 12:45:22PM -0400, Christopher Morrow wrote: > ah yes, was thinking of local-as. the 'replace-as' seems like > loop-creation, joy. It can. The use of replace-as is typically in situations where you need to replace private AS numbers with a public number. This is typically done when you have deployments that have a mix of private and public ASes behind a common transit carrier and "remove-private" isn't sufficient. The required behavior in order to avoid problems here is to make sure that the set of ASes involved are behind that common carrier and either are not multi-homed to the wider Internet (unlikely since they have private ASes) or are applying appropriate AS filtering to manually suppress loops. -- Jeff From jhaas@slice.pfrc.org Wed Mar 28 14:03:36 2012 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 F2C7121E8040 for ; Wed, 28 Mar 2012 14:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.159 X-Spam-Level: X-Spam-Status: No, score=-102.159 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 1N1FouYe0Ooh for ; Wed, 28 Mar 2012 14:03:35 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8244D21E800E for ; Wed, 28 Mar 2012 14:03:35 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 5214E17041D; Wed, 28 Mar 2012 17:03:35 -0400 (EDT) Date: Wed, 28 Mar 2012 17:03:35 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20120328210335.GB16814@slice> References: <4F72166F.6080503@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F72166F.6080503@raszuk.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" Subject: Re: [Idr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 21:03:36 -0000 On Tue, Mar 27, 2012 at 09:35:11PM +0200, Robert Raszuk wrote: > /In the light of just reissued draft-ietf-idr-bgp-issues-06)/ > > Hi, > > As number of BGP implementations allow for configuration of i/eBGP > multipath across paths which do not have identical AS_PATH I would > like to ask the list what people think is the right current BGP > protocol behaviour when advertising best multipath path out ? > > During discussions of RFC6472 I recall a bit of discussion there on > this topic, but no conclusion reached. > > http://www.ietf.org/mail-archive/web/idr/current/msg04512.html > > On the other hand > http://tools.ietf.org/html/draft-ietf-idr-bgp-issues-06 in section > "2.11.3. Documenting IBGP Multipath" says: > > If in EBGP multipath traffic is split among routers in difference AS, > an aggregate SHOULD be formed so as to propagate a route with an > accurate AS_PATH. If the resulting aggregate is not more specific > than the components, the AS_SET SHOULD NOT be dropped. > > The question is what an implementation of BGP today should do when > multipath is enabled, AS_SET is recommended for depreciation and no > new alternative is even proposed to protect against potential loops > ? > > Options seems to be: > > * Do nothing .. trust that whoever enables multipath across non > identical AS_PATHs is a non-transit/stub AS and no loop will happen > (ios approach) > > * Continue to call as_aggregate and still generate AS_SET > effectively depreciating RFC6472 (quagga approach) Generating sets is the safest thing to do. > * Propose an alternative encoding to address this case specifically > for multipath use cases, but till this is deployed continue use > AS_SET The likely alternative would be a set of vectors of paths. This would be a massively different AS_PATH and would have significant deployment issues. E.g.: Path A: 7 8 9 10 Path B: 4 5 9 10 Aggregated vector path: 7 8 \ 9 10 / 4 5 > * Remove all knobs from shipping BGP implementations and forbid to > use paths with different AS_PATH for multipath (junos approach). Even junos provides rope. (As was said at the mic at some point at IETF 83, "what's a few meters more?") The feature is safe in cases where the receiving downstream is a stub AS. -- Jeff From jhaas@slice.pfrc.org Wed Mar 28 14:05:20 2012 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 7E61421E8040; Wed, 28 Mar 2012 14:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.161 X-Spam-Level: X-Spam-Status: No, score=-102.161 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 TEglyoKWX9fy; Wed, 28 Mar 2012 14:05:20 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1C93821E800E; Wed, 28 Mar 2012 14:05:20 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id DB75F17041D; Wed, 28 Mar 2012 17:05:19 -0400 (EDT) Date: Wed, 28 Mar 2012 17:05:19 -0400 From: Jeffrey Haas To: Paul Jakma Message-ID: <20120328210519.GC16814@slice> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" , Tony Li , "robert@raszuk.net" , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 21:05:20 -0000 Paul, On Wed, Mar 28, 2012 at 02:10:04PM +0100, Paul Jakma wrote: > Where's the document to describe how to do multi-pathing using > add-path? E.g. what should happen when there is a non-add-path > capable neighbour? In add-path, this is no different than receiving routes from directly attached peers. You should either do Internet-safe multipath or do the less safe multipath knowing that you're in a position to cause problems. Add-path doesn't really change the basic problem of multipath. -- Jeff From robert@raszuk.net Wed Mar 28 14:09:07 2012 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 B7A4921E8097 for ; Wed, 28 Mar 2012 14:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 iDy0t0pbYwA7 for ; Wed, 28 Mar 2012 14:09:07 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 020EA21E800E for ; Wed, 28 Mar 2012 14:09:07 -0700 (PDT) Received: (qmail 24383 invoked by uid 399); 28 Mar 2012 21:09:06 -0000 Received: from unknown (HELO ?10.0.1.4?) (pbs:robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPM; 28 Mar 2012 21:09:06 -0000 X-Originating-IP: 79.141.15.165 Message-ID: <4F737DF4.7030202@raszuk.net> Date: Wed, 28 Mar 2012 23:09:08 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Jeffrey Haas References: <4F72166F.6080503@raszuk.net> <20120328210335.GB16814@slice> In-Reply-To: <20120328210335.GB16814@slice> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 21:09:07 -0000 Jeff, >> * Continue to call as_aggregate and still generate AS_SET >> effectively depreciating RFC6472 (quagga approach) > > Generating sets is the safest thing to do. Glad you said this. I do agree. >> * Propose an alternative encoding to address this case specifically >> for multipath use cases, but till this is deployed continue use >> AS_SET > > The likely alternative would be a set of vectors of paths. This would be a > massively different AS_PATH and would have significant deployment issues. > E.g.: > Path A: 7 8 9 10 > Path B: 4 5 9 10 > > Aggregated vector path: > 7 8 > \ > 9 10 > / > 4 5 Indeed. Almost like you would require a new attribute for that .. however not clear at all how such new attribute even if defined would help. > The feature is safe in cases where the receiving downstream is a > stub AS. IBGP multipath is used quite widely. In fact as I am sure you know in the case you have encapsulation in the core (for example mpls LSPs) there are knobs to skip metric check to the next hop. Best regards, R. From tony.li@tony.li Wed Mar 28 14:16:52 2012 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 E75CE21E8040 for ; Wed, 28 Mar 2012 14:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 QX-S6eEtTu8k for ; Wed, 28 Mar 2012 14:16:51 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADD121E80A2 for ; Wed, 28 Mar 2012 14:16:51 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta09.westchester.pa.mail.comcast.net with comcast id r9CU1i0091ei1Bg599GrUX; Wed, 28 Mar 2012 21:16:51 +0000 Received: from [10.155.34.251] ([128.107.239.233]) by omta24.westchester.pa.mail.comcast.net with comcast id r9Ge1i00F52qHCY3k9Ggax; Wed, 28 Mar 2012 21:16:49 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <4F737DF4.7030202@raszuk.net> Date: Wed, 28 Mar 2012 14:16:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <24F722F3-4D36-40D4-83FE-27B14CB5B9ED@tony.li> References: <4F72166F.6080503@raszuk.net> <20120328210335.GB16814@slice> <4F737DF4.7030202@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1257) Cc: "idr@ietf.org List" Subject: Re: [Idr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 21:16:52 -0000 On Mar 28, 2012, at 2:09 PM, Robert Raszuk wrote: >>> * Continue to call as_aggregate and still generate AS_SET >>> effectively depreciating RFC6472 (quagga approach) >>=20 >> Generating sets is the safest thing to do. >=20 > Glad you said this. I do agree. Understood, but how do you ever secure this? Set SIDR aside for a = second, what would ANY path verification mechanism have to do to secure = the full path? It would seem that the ONLY thing one could reasonably do is to describe = the full topology, and that would seem to require the ability to = describe an arbitrary tree, not just a set of vectors of paths. Tony From jhaas@slice.pfrc.org Wed Mar 28 14:17:43 2012 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 44A7421F843E; Wed, 28 Mar 2012 14:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.163 X-Spam-Level: X-Spam-Status: No, score=-102.163 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 UoED3lGA5iGT; Wed, 28 Mar 2012 14:17:42 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 24B8221E8132; Wed, 28 Mar 2012 14:17:29 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E2C80170421; Wed, 28 Mar 2012 17:17:28 -0400 (EDT) Date: Wed, 28 Mar 2012 17:17:28 -0400 From: Jeffrey Haas To: Jakob Heitz Message-ID: <20120328211728.GD16814@slice> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" , Tony Li , Paul Jakma , Robert Raszuk , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 21:17:43 -0000 On Wed, Mar 28, 2012 at 10:56:52AM -0400, Jakob Heitz wrote: > The issue is SIDR can not aggregate multiple paths. > > Solutions I can think of: > 1. Aggregate the signatures of the paths being aggregated. What are the semantics you're trying to preserve SIDR-wise? We're hitting the realm where Russ White would point out that BGP path validation can't prove how forwarding works. Presume we managed to pass along two distinct paths for the same multi-path route in BGP. What do you do if one doesn't validate? What do you do if they do, but you think this is a form of a "route leak" for one path? As a receiver of the route that is making use of multipath, you can't selectively choose which sub-paths to take. (It's not like we're gettng something like MPLS entropy labels.) > 2. Don't aggregate, but send both paths. That doesn't cover the actual forwarding semantics. > Should SIDR work on path aggregation? > Are there other possibilities? The biggest problem here is "SIDR secures BGP". The issue hasn't been clear in BGP for years, although I'm perhaps of the cynical opinion that it's been a well understood problem space for a while now. The protocol doesn't reflect what is done operationally. The safe thing operationally when aggregating unsafe paths is to generate sets, but some people have never liked sets. And as I mentioned elsewhere, it doesn't matter as long as you take care in where you redistribute such unsafe multipath. There was a reason I wasn't terribly supportive of the deprecating AS_SETs I-D. However, I also knew it was a losing battle. :-) -- Jeff From jhaas@slice.pfrc.org Wed Mar 28 14:23:35 2012 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 93FE821F860E; Wed, 28 Mar 2012 14:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 oRM0dyBtXTVB; Wed, 28 Mar 2012 14:23:35 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD9B21F860B; Wed, 28 Mar 2012 14:23:35 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F04221703F4; Wed, 28 Mar 2012 17:23:34 -0400 (EDT) Date: Wed, 28 Mar 2012 17:23:34 -0400 From: Jeffrey Haas To: Christopher Morrow Message-ID: <20120328212334.GF16814@slice> References: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" , Tony Li , Paul Jakma , robert@raszuk.net, sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 21:23:35 -0000 On Wed, Mar 28, 2012 at 12:45:22PM -0400, Christopher Morrow wrote: > ah yes, was thinking of local-as. the 'replace-as' seems like > loop-creation, joy. For the list, as I mentioned in SIDR, the use of local-AS where the router has more than one local AS will generate AS_SETs in some implementations. In particular, implementations with gated lineages may do this. This is because in pretending to be another AS it's still necessary to throw the global and local ASes in the path to prevent loops in cases where the local AS on one router may not be configured consistently (global) AS-wide. In those implementations, a single AS is simply added prior to the global AS in the path as a sequence or all local ASes as a set. In another implementation, the local ASes are added as a sequence. Adding the additional AS to the path would still require an additional signature step in BGPSEC. Clearly this doesn't work for AS-sets. -- Jeff From jakob.heitz@ericsson.com Wed Mar 28 14:57:06 2012 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 D976B21E80ED for ; Wed, 28 Mar 2012 14:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 pnj4zIFpJnZj for ; Wed, 28 Mar 2012 14:57:06 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 381BA21E80EF for ; Wed, 28 Mar 2012 14:57:06 -0700 (PDT) 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 q2SLumQ0016455; Wed, 28 Mar 2012 16:57:05 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 28 Mar 2012 17:57:01 -0400 From: Jakob Heitz To: Tony Li Date: Wed, 28 Mar 2012 17:57:32 -0400 Thread-Topic: [Idr] AS_SET depreciation (RFC6472) and BGP multipath Thread-Index: Ac0NLbRRJ4DN4Hs7Qp659yEqDYl+cQ== Message-ID: <5FE465B7-5005-4FE4-B97C-0608C9F9A45C@ericsson.com> References: <4F72166F.6080503@raszuk.net> <20120328210335.GB16814@slice> <4F737DF4.7030202@raszuk.net> <24F722F3-4D36-40D4-83FE-27B14CB5B9ED@tony.li> In-Reply-To: <24F722F3-4D36-40D4-83FE-27B14CB5B9ED@tony.li> 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 List" , "robert@raszuk.net" Subject: Re: [Idr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 21:57:07 -0000 This can be done. Like I said before: aggregate the signatures of the paths being aggregated. String all the signed paths together (after wrapping them with a header), a= dd your SKI and destination AS (as normal) and sign over the lot. Question is: does anyone want to? -- Jakob Heitz. On Mar 28, 2012, at 11:17 PM, "Tony Li" wrote: >=20 > On Mar 28, 2012, at 2:09 PM, Robert Raszuk wrote: >=20 >>>> * Continue to call as_aggregate and still generate AS_SET >>>> effectively depreciating RFC6472 (quagga approach) >>>=20 >>> Generating sets is the safest thing to do. >>=20 >> Glad you said this. I do agree. >=20 >=20 > Understood, but how do you ever secure this? Set SIDR aside for a second= , what would ANY path verification mechanism have to do to secure the full = path? >=20 > It would seem that the ONLY thing one could reasonably do is to describe = the full topology, and that would seem to require the ability to describe a= n arbitrary tree, not just a set of vectors of paths. >=20 > Tony >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Wed Mar 28 15:02:51 2012 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 29C3021E80FC; Wed, 28 Mar 2012 15:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 qO+zX15AHvXl; Wed, 28 Mar 2012 15:02:50 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C281B21E80B1; Wed, 28 Mar 2012 15:02:49 -0700 (PDT) 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 q2SM2laZ017641; Wed, 28 Mar 2012 17:02:49 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 28 Mar 2012 18:02:46 -0400 From: Jakob Heitz To: sidr wg list Date: Wed, 28 Mar 2012 18:03:16 -0400 Thread-Topic: [Idr] AS_SET depreciation (RFC6472) and BGP multipath Thread-Index: Ac0NLoGzh7neYzreT06/e8Cqxu9uMA== Message-ID: <1229E370-0830-4815-AFB7-304D1479FC62@ericsson.com> References: <4F72166F.6080503@raszuk.net> <20120328210335.GB16814@slice> <4F737DF4.7030202@raszuk.net> <24F722F3-4D36-40D4-83FE-27B14CB5B9ED@tony.li> <5FE465B7-5005-4FE4-B97C-0608C9F9A45C@ericsson.com> In-Reply-To: <5FE465B7-5005-4FE4-B97C-0608C9F9A45C@ericsson.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 Cc: "idr@ietf.org List" , Tony Li , "robert@raszuk.net" Subject: Re: [Idr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 22:02:51 -0000 including sidr=20 -- Jakob Heitz. On Mar 28, 2012, at 11:57 PM, "Jakob Heitz" wrot= e: > This can be done. > Like I said before: aggregate the signatures of the paths being aggregate= d. > String all the signed paths together (after wrapping them with a header),= add your SKI and destination AS (as normal) and sign over the lot. >=20 > Question is: does anyone want to? >=20 > -- > Jakob Heitz. >=20 >=20 > On Mar 28, 2012, at 11:17 PM, "Tony Li" wrote: >=20 >>=20 >> On Mar 28, 2012, at 2:09 PM, Robert Raszuk wrote: >>=20 >>>>> * Continue to call as_aggregate and still generate AS_SET >>>>> effectively depreciating RFC6472 (quagga approach) >>>>=20 >>>> Generating sets is the safest thing to do. >>>=20 >>> Glad you said this. I do agree. >>=20 >>=20 >> Understood, but how do you ever secure this? Set SIDR aside for a secon= d, what would ANY path verification mechanism have to do to secure the full= path? >>=20 >> It would seem that the ONLY thing one could reasonably do is to describe= the full topology, and that would seem to require the ability to describe = an arbitrary tree, not just a set of vectors of paths. >>=20 >> Tony >>=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 From christopher.morrow@gmail.com Wed Mar 28 15:15:16 2012 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 1CD0121E8101; Wed, 28 Mar 2012 15:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.559 X-Spam-Level: X-Spam-Status: No, score=-103.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 7M8FIXWMr3PE; Wed, 28 Mar 2012 15:15:15 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5347B21E80FB; Wed, 28 Mar 2012 15:15:15 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2212580obb.31 for ; Wed, 28 Mar 2012 15:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OvDZYE8GehlboS1naVrDM7QBFZ4XJdcoNj+7y/yswtE=; b=lqYe5HtQE2U/CxqJFD6XnPE2xCCz0UDUuWFjdV0L9dCPibL6gWQTvMQp6GtrdsY2i6 JvtD0r38EF9L6WBBFBvMWvUUhMrH2SnUelgfdlFv7jc3Trf0rnqQOD2UF5FaO3HeCnY1 lvJRRfb/cyrBEaSDtvEr2k8s6h4dbP/tnCaWIU7zvsteyqeDbXAPQpL3AglV96EtL4wn BY9+Dz2TuBthDZ5cuTSszTInhnWdtcLPBV543qdqE+px1KdugTE80sey9qPwMKt2GDEr /YbOGXCRLGFGBtR/vYlNKw0hiBixXoKdb4oPHBCOLWDmtx02dwHkV3HwM/JVbU+abtPS iSYQ== MIME-Version: 1.0 Received: by 10.182.155.68 with SMTP id vu4mr39979033obb.61.1332972914880; Wed, 28 Mar 2012 15:15:14 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 15:15:14 -0700 (PDT) In-Reply-To: <4F7374DD.7060301@raszuk.net> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> <4F736F6E.70205@raszuk.net> <4F7374DD.7060301@raszuk.net> Date: Wed, 28 Mar 2012 18:15:14 -0400 X-Google-Sender-Auth: Pl6mxZAWlmXnwmU-G4enVt-_ots Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 22:15:16 -0000 On Wed, Mar 28, 2012 at 4:30 PM, Robert Raszuk wrote: > I am saying that it exists in shipping implementations and simply asking > what SIDR behaviour should be when such policy is present. I guess what I wasn't saying was that not every oddball wierdness permitted TODAY in BGP is able to be secured, or validate-able. It's not required that this be the case actually. -chris From stephane.litkowski@orange.com Wed Mar 28 22:46:42 2012 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 4444E21E8051 for ; Wed, 28 Mar 2012 22:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=0.493, 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 nypr4eMI2x-y for ; Wed, 28 Mar 2012 22:46:41 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6303221E8015 for ; Wed, 28 Mar 2012 22:46:40 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 0475222C594; Thu, 29 Mar 2012 07:46:39 +0200 (CEST) Received: from puexcc41.nanterre.francetelecom.fr (unknown [10.168.74.60]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DD6CC35C048; Thu, 29 Mar 2012 07:46:38 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc41.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 07:46:38 +0200 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 Mar 2012 07:46:33 +0200 Message-ID: <19431_1332999998_4F73F73E_19431_9159_1_4FC3556A36EE3646A09DAA60429F5335080A2FBE@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFDA43@EUSAACMS0701.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] [mpls] RE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation vs BGP anycast Thread-Index: Ac0My/4LNoRXji8nRyuw6EmO8k6gfQAC1BOwAAovX8AAGtXkgA== References: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com><11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr><17281_1332838526_4F71807E_17281_577_1_4FC3556A36EE3646A09DAA60429F53350804C77B@PUEXCBL0.nanterre.francetelecom.fr><4F72E529.4030800@cisco.com> <27841_1332936595_4F72FF93_27841_563_1_4FC3556A36EE3646A09DAA60429F5335080A2D5B@PUEXCBL0.nanterre.francetelecom.fr> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFDA43@EUSAACMS0701.eamcs.ericsson.se> From: To: "Jakob Heitz" , "Ahmed Bashandy" X-OriginalArrivalTime: 29 Mar 2012 05:46:38.0896 (UTC) FILETIME=[4F712B00:01CD0D6F] X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.29.42117 Cc: idr@ietf.org Subject: Re: [Idr] [mpls] RE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation vs BGP anycast 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 Mar 2012 05:46:42 -0000 Jakob, BGP Anycast and Ahmed's solution sound very similar. BGP Anycast : - Protector PE definition seems manual as far as I know - LFA used as protection mechanism on P thanks to Anycast feature (same vi= rtual loopback used on primary and repair PE) =3D> 100% coverage not guaran= teed - Still need to advertise virtual loopbacks in ISIS and LDP=20 - Requires also usage of repair label draft to prevent loops - Possibly requires a small change in the way to advertise LDP FEC for vir= tual loopbacks (depending on current vendor implementation) =3D> no PHP req= uired but most vendors are doing PHP by default. - One core state per VPN protected - Possibly suboptimal routing when using centralized protector PEs. BGP-edge-node-frr :=20 - Protector PE definition is automatic (no configuration), and chosen by p= rimary PE and his per CE. - New extension used to signal protection decision to P router - New loopbacks advertised in ISIS and LDP. - Basically more optimal routing (BGP anycast can achieve the same but it = requires a lot of configuration of many different PEs) - One core state per CE protected (per VPN possible but may cause loop) Correct me if I missed something. Regards, Stephane -----Message d'origine----- De : Jakob Heitz [mailto:jakob.heitz@ericsson.com]=20 Envoy=E9 : mercredi 28 mars 2012 18:35 =C0 : Ahmed Bashandy Cc : idr@ietf.org; LITKOWSKI Stephane DTF/DERX Objet : RE: [Idr] [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation Ahmed, BGP PIC Edge is not the only existing solution. Look at "5.1.8.4.1. Anycast BGP applied to ABR node failure" in http://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-01 That looks much simpler. How is yours better than this? -- Jakob Heitz. -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of steph= ane.litkowski@orange.com Sent: Wednesday, March 28, 2012 5:10 AM To: Ahmed Bashandy Cc: idr@ietf.org Subject: Re: [Idr] [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivati= on [Moving to IDR list ...] Yes, when we are aware about FRR technics, it's clear but there is some lin= es in the doc, that could lead to understand that every P may install a rep= air ... If you are using LDP or ISIS (and especially ISIS which use flooding of LSP= ) to advertise the (NHi,rNHi) or (Nhi,rNHi,Li,Push), every P router will re= ceive the info (could not be the case with LDP ..., but it's not welle deta= illed that your LDP TLV must not be propagated upstream). I don't see somet= hing in the drafts (ISIS or BGP drafts) preventing remote P to install a ba= ckup entry ... Based on Step 4 at =A72.4 of the BGP draft, any P has a route to the BGP ne= xthop, and so is able to compute alternate path ... How do you prevent it to happen ? -----Message d'origine----- De : Ahmed Bashandy [mailto:bashandy@cisco.com] Envoy=E9 : mercredi 28 mars= 2012 12:17 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Jeff Tantsura; IETF MPLS= Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation The basic idea behind any (IP)FRR mechanism is to have the repairing node p= er-calculate the repair path and be directly connected to the failure point= . This allows the repairing node can make quick and small local modificatio= n to the FIB so that traffic gets re-routed over the per-calculated repair = path within a guaranteed recovery period This draft, just like all (IP)FRR drafts (including those that protect mult= icast traffic), addresses the case of the repairing node being adjacent to= failing network element. Detecting a remote failure is really beyond the s= cope Thanks Ahmed On 3/27/2012 10:55 AM, stephane.litkowski@orange.com wrote: > I totally agree with your point as if the P router is not directly connec= ted to the protected PE, the solution doesn't bring any improvement compare= d to PIC Edge. > The solution as a value for a repairing P connnected to the PE and so det= ecting the failure immediately. > If the repairing P is remote to the failure, we are no more in a FRR case= ... And I think this should be prevented ... > > -----Message d'origine----- > De : Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > Envoy=E9 : mardi 27 mars 2012 10:44 > =C0 : LITKOWSKI Stephane DTF/DERX > Cc : Ilya Varlashkin; IETF MPLS > Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation > > Hi, > > The switchover AFTER the failure has been detected in both cases is: > Prefix independent - ie no RIB->FIB interactions Sub 100ms for=20 > reasonable number of primary/backup pairs > > So the real issue here is reliable and fast failure notification! > > As for this draft - if the repairing P router is not directly connected t= o the primary PE it is subject to the same limitations and would initiate s= witchover on either multihop BFD down or IGP convergence. > Even though it is presumably closer to the failure than ingress PE and co= uld react faster IMHO the complexity introduced is rather significant compa= red to the gain. > > Regards, > Jeff > > On Mar 27, 2012, at 10:21 AM, "stephane.litkowski@orange.com" wrote: > >> Ilya, >> >> The best current available mechanism is BGP PIC Edge that relay on IGP c= onvergence to detect that remote PE is no longer reachable : PIC Edge resul= t mainly depends on how fast your IGP is converging (sub sec or more). >> >> Ahmed solution is an FRR solution so doesn't rely on convergence. As soo= n as a P router detects that the link to the protected PE fails, it will sw= itch (using pre-programmed backup NHLFE), so there you are in FRR numbers .= .. 50msec - 100msec depending of implementation ... >> >> Clearly the solution is today complex, and I hope it could be a bit=20 >> simplified :) >> >> Regards, >> >> Stephane >> >> >> -----Message d'origine----- >> De : mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] De la part=20 >> de Ilya Varlashkin Envoy=E9 : mardi 27 mars 2012 10:08 =C0 : IETF MPLS= =20 >> Objet : [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation >> >> Ahmed, Kamran, >> >> as first expressed at the mic during MPLS session, I'd like to ask you f= or a clarification of the motivation behind the draft. You say that this dr= aft will provide faster switch-over/fail-over time compare to anything alre= ady existing today. Do you have some numbers for comparison? >> >> /iLya >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, 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=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> 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 is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > 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 is not liable for messa= ges that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ 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 authorisation. 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 is not liable for message= s that have been 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 authorisation. 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 is not liable for message= s that have been modified, changed or falsified. Thank you. From jhaas@slice.pfrc.org Thu Mar 29 00:10:55 2012 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 659F621E811A for ; Thu, 29 Mar 2012 00:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.167 X-Spam-Level: X-Spam-Status: No, score=-102.167 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 CZ0pOdmn0J4i for ; Thu, 29 Mar 2012 00:10:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 13ECC21F857F for ; Thu, 29 Mar 2012 00:10:54 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 61DA1170411; Thu, 29 Mar 2012 03:10:53 -0400 (EDT) Date: Thu, 29 Mar 2012 03:10:53 -0400 From: Jeffrey Haas To: Jakob Heitz Message-ID: <20120329071053.GA6831@slice> References: <4F72166F.6080503@raszuk.net> <20120328210335.GB16814@slice> <4F737DF4.7030202@raszuk.net> <24F722F3-4D36-40D4-83FE-27B14CB5B9ED@tony.li> <5FE465B7-5005-4FE4-B97C-0608C9F9A45C@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5FE465B7-5005-4FE4-B97C-0608C9F9A45C@ericsson.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" , Tony Li , "robert@raszuk.net" Subject: Re: [Idr] AS_SET depreciation (RFC6472) and BGP multipath 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 Mar 2012 07:10:55 -0000 On Wed, Mar 28, 2012 at 05:57:32PM -0400, Jakob Heitz wrote: > This can be done. > Like I said before: aggregate the signatures of the paths being aggregated. > String all the signed paths together (after wrapping them with a header), add your SKI and destination AS (as normal) and sign over the lot. > > Question is: does anyone want to? At minimum, this would further decouple the signature from the actual path. And given multipath covers *many* routes, the result would likely be unwieldy. -- Jeff From jakob.heitz@ericsson.com Thu Mar 29 00:28:28 2012 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 9EA3221F85F6 for ; Thu, 29 Mar 2012 00:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 go61fC6PPWJm for ; Thu, 29 Mar 2012 00:28:27 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5633921F85F3 for ; Thu, 29 Mar 2012 00:28:27 -0700 (PDT) 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 q2T7SNcX020615; Thu, 29 Mar 2012 02:28:26 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 29 Mar 2012 03:28:24 -0400 From: Jakob Heitz To: "stephane.litkowski@orange.com" Date: Thu, 29 Mar 2012 03:28:55 -0400 Thread-Topic: [Idr] [mpls] RE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation vs BGP anycast Thread-Index: Ac0NfYbRZBhM1iKKTtGfW7KUUnDI4Q== Message-ID: <0B142F23-9504-4497-BBAD-415D9B208976@ericsson.com> References: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com> <11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr> <17281_1332838526_4F71807E_17281_577_1_4FC3556A36EE3646A09DAA60429F53350804C77B@PUEXCBL0.nanterre.francetelecom.fr> <4F72E529.4030800@cisco.com> <27841_1332936595_4F72FF93_27841_563_1_4FC3556A36EE3646A09DAA60429F5335080A2D5B@PUEXCBL0.nanterre.francetelecom.fr> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFDA43@EUSAACMS0701.eamcs.ericsson.se> <19431_1332999998_4F73F73E_19431_9159_1_4FC3556A36EE3646A09DAA60429F5335080A2FBE@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <19431_1332999998_4F73F73E_19431_9159_1_4FC3556A36EE3646A09DAA60429F5335080A2FBE@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] [mpls] RE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation vs BGP anycast 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 Mar 2012 07:28:28 -0000 T24gTWFyIDI5LCAyMDEyLCBhdCA3OjQ2IEFNLCAic3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5j b20iIDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4gd3JvdGU6DQoNCj4gSmFrb2IsDQo+ IA0KPiBCR1AgQW55Y2FzdCBhbmQgQWhtZWQncyBzb2x1dGlvbiBzb3VuZCB2ZXJ5IHNpbWlsYXIu DQo+IA0KPiBCR1AgQW55Y2FzdCA6DQo+IC0gUHJvdGVjdG9yIFBFIGRlZmluaXRpb24gc2VlbXMg bWFudWFsIGFzIGZhciBhcyBJIGtub3cNCg0KTm90IGlmIHRoZSBwcm90ZWN0aW5nIFBFIGlzIHRo ZSBwcm90ZWN0b3IuDQoNCj4gLSBMRkEgdXNlZCBhcyBwcm90ZWN0aW9uIG1lY2hhbmlzbSBvbiBQ IHRoYW5rcyB0byBBbnljYXN0IGZlYXR1cmUgKHNhbWUgdmlydHVhbCBsb29wYmFjayB1c2VkIG9u IHByaW1hcnkgYW5kIHJlcGFpciBQRSkgPT4gMTAwJSBjb3ZlcmFnZSBub3QgZ3VhcmFudGVlZA0K DQpJZiBubyBMRkEsIHRoZW4gaXQncyBJR1AgY29udmVyZ2VuY2UuIFNhbWUgd2l0aCBBaG1lZCdz IGRyYWZ0Lg0KDQo+IC0gU3RpbGwgbmVlZCB0byBhZHZlcnRpc2UgdmlydHVhbCBsb29wYmFja3Mg aW4gSVNJUyBhbmQgTERQDQo+IC0gUmVxdWlyZXMgYWxzbyB1c2FnZSBvZiByZXBhaXIgbGFiZWwg ZHJhZnQgdG8gcHJldmVudCBsb29wcw0KDQpXaGF0IGxvb3BzPw0KDQo+IC0gUG9zc2libHkgcmVx dWlyZXMgYSBzbWFsbCBjaGFuZ2UgaW4gdGhlIHdheSB0byBhZHZlcnRpc2UgTERQIEZFQyBmb3Ig dmlydHVhbCBsb29wYmFja3MgKGRlcGVuZGluZyBvbiBjdXJyZW50IHZlbmRvciBpbXBsZW1lbnRh dGlvbikgPT4gbm8gUEhQIHJlcXVpcmVkIGJ1dCBtb3N0IHZlbmRvcnMgYXJlIGRvaW5nIFBIUCBi eSBkZWZhdWx0Lg0KPiAtIE9uZSBjb3JlIHN0YXRlIHBlciBWUE4gcHJvdGVjdGVkDQoNClRoZSBv bmx5IGNvcmUgc3RhdGUgaXMgdGhlIGFsdGVybmF0ZSBwYXRoIHRvIHRoZSBhbnljYXN0Lg0KDQo+ IC0gUG9zc2libHkgc3Vib3B0aW1hbCByb3V0aW5nIHdoZW4gdXNpbmcgY2VudHJhbGl6ZWQgcHJv dGVjdG9yIFBFcy4NCj4gDQo+IEJHUC1lZGdlLW5vZGUtZnJyIDoNCj4gLSBQcm90ZWN0b3IgUEUg ZGVmaW5pdGlvbiBpcyBhdXRvbWF0aWMgKG5vIGNvbmZpZ3VyYXRpb24pLCBhbmQgY2hvc2VuIGJ5 IHByaW1hcnkgUEUgYW5kIGhpcyBwZXIgQ0UuDQo+IC0gTmV3IGV4dGVuc2lvbiB1c2VkIHRvIHNp Z25hbCBwcm90ZWN0aW9uIGRlY2lzaW9uIHRvIFAgcm91dGVyDQo+IC0gTmV3IGxvb3BiYWNrcyBh ZHZlcnRpc2VkIGluIElTSVMgYW5kIExEUC4NCj4gLSBCYXNpY2FsbHkgbW9yZSBvcHRpbWFsIHJv dXRpbmcgKEJHUCBhbnljYXN0IGNhbiBhY2hpZXZlIHRoZSBzYW1lIGJ1dCBpdCByZXF1aXJlcyBh IGxvdCBvZiBjb25maWd1cmF0aW9uIG9mIG1hbnkgZGlmZmVyZW50IFBFcykNCj4gLSBPbmUgY29y ZSBzdGF0ZSBwZXIgQ0UgcHJvdGVjdGVkIChwZXIgVlBOIHBvc3NpYmxlIGJ1dCBtYXkgY2F1c2Ug bG9vcCkNCj4gDQo+IA0KPiBDb3JyZWN0IG1lIGlmIEkgbWlzc2VkIHNvbWV0aGluZy4NCj4gDQo+ IFJlZ2FyZHMsDQo+IA0KPiBTdGVwaGFuZQ0KPiANCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t LS0tDQo+IERlIDogSmFrb2IgSGVpdHogW21haWx0bzpqYWtvYi5oZWl0ekBlcmljc3Nvbi5jb21d DQo+IEVudm95w6kgOiBtZXJjcmVkaSAyOCBtYXJzIDIwMTIgMTg6MzUNCj4gw4AgOiBBaG1lZCBC YXNoYW5keQ0KPiBDYyA6IGlkckBpZXRmLm9yZzsgTElUS09XU0tJIFN0ZXBoYW5lIERURi9ERVJY DQo+IE9iamV0IDogUkU6IFtJZHJdIFttcGxzXSBhaFJFOiBkcmFmdC1iYXNoYW5keS1tcGxzLWxk cC1iZ3AtZnJyLTAwIG1vdGl2YXRpb24NCj4gDQo+IEFobWVkLA0KPiANCj4gQkdQIFBJQyBFZGdl IGlzIG5vdCB0aGUgb25seSBleGlzdGluZyBzb2x1dGlvbi4NCj4gTG9vayBhdCAiNS4xLjguNC4x LiAgQW55Y2FzdCBCR1AgYXBwbGllZCB0byBBQlIgbm9kZSBmYWlsdXJlIg0KPiBpbiBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1wbHMtc2VhbWxlc3MtbXBscy0wMQ0KPiAN Cj4gVGhhdCBsb29rcyBtdWNoIHNpbXBsZXIuIEhvdyBpcyB5b3VycyBiZXR0ZXIgdGhhbiB0aGlz Pw0KPiANCj4gLS0NCj4gSmFrb2IgSGVpdHouDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBpZHItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlkci1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2Ygc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20NCj4gU2Vu dDogV2VkbmVzZGF5LCBNYXJjaCAyOCwgMjAxMiA1OjEwIEFNDQo+IFRvOiBBaG1lZCBCYXNoYW5k eQ0KPiBDYzogaWRyQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbSWRyXSBbbXBsc10gYWhSRTog ZHJhZnQtYmFzaGFuZHktbXBscy1sZHAtYmdwLWZyci0wMCBtb3RpdmF0aW9uDQo+IA0KPiBbTW92 aW5nIHRvIElEUiBsaXN0IC4uLl0NCj4gDQo+IFllcywgd2hlbiB3ZSBhcmUgYXdhcmUgYWJvdXQg RlJSIHRlY2huaWNzLCBpdCdzIGNsZWFyIGJ1dCB0aGVyZSBpcyBzb21lIGxpbmVzIGluIHRoZSBk b2MsIHRoYXQgY291bGQgbGVhZCB0byB1bmRlcnN0YW5kIHRoYXQgZXZlcnkgUCBtYXkgaW5zdGFs bCBhIHJlcGFpciAuLi4NCj4gDQo+IElmIHlvdSBhcmUgdXNpbmcgTERQIG9yIElTSVMgKGFuZCBl c3BlY2lhbGx5IElTSVMgd2hpY2ggdXNlIGZsb29kaW5nIG9mIExTUCkgdG8gYWR2ZXJ0aXNlIHRo ZSAoTkhpLHJOSGkpIG9yIChOaGksck5IaSxMaSxQdXNoKSwgZXZlcnkgUCByb3V0ZXIgd2lsbCBy ZWNlaXZlIHRoZSBpbmZvIChjb3VsZCBub3QgYmUgdGhlIGNhc2Ugd2l0aCBMRFAgLi4uLCBidXQg aXQncyBub3Qgd2VsbGUgZGV0YWlsbGVkIHRoYXQgeW91ciBMRFAgVExWIG11c3Qgbm90IGJlIHBy b3BhZ2F0ZWQgdXBzdHJlYW0pLiBJIGRvbid0IHNlZSBzb21ldGhpbmcgaW4gdGhlIGRyYWZ0cyAo SVNJUyBvciBCR1AgZHJhZnRzKSBwcmV2ZW50aW5nIHJlbW90ZSBQIHRvIGluc3RhbGwgYSBiYWNr dXAgZW50cnkgLi4uDQo+IA0KPiBCYXNlZCBvbiBTdGVwIDQgYXQgwqcyLjQgb2YgdGhlIEJHUCBk cmFmdCwgYW55IFAgaGFzIGEgcm91dGUgdG8gdGhlIEJHUCBuZXh0aG9wLCBhbmQgc28gaXMgYWJs ZSB0byBjb21wdXRlIGFsdGVybmF0ZSBwYXRoIC4uLg0KPiANCj4gSG93IGRvIHlvdSBwcmV2ZW50 IGl0IHRvIGhhcHBlbiA/DQo+IA0KPiANCj4gDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KPiBEZSA6IEFobWVkIEJhc2hhbmR5IFttYWlsdG86YmFzaGFuZHlAY2lzY28uY29tXSBFbnZv ecOpIDogbWVyY3JlZGkgMjggbWFycyAyMDEyIDEyOjE3IMOAIDogTElUS09XU0tJIFN0ZXBoYW5l IERURi9ERVJYIENjIDogSmVmZiBUYW50c3VyYTsgSUVURiBNUExTIE9iamV0IDogUmU6IFttcGxz XSBhaFJFOiBkcmFmdC1iYXNoYW5keS1tcGxzLWxkcC1iZ3AtZnJyLTAwIG1vdGl2YXRpb24NCj4g DQo+IFRoZSBiYXNpYyBpZGVhIGJlaGluZCBhbnkgKElQKUZSUiBtZWNoYW5pc20gaXMgdG8gaGF2 ZSB0aGUgcmVwYWlyaW5nIG5vZGUgcGVyLWNhbGN1bGF0ZSB0aGUgcmVwYWlyIHBhdGggYW5kIGJl IGRpcmVjdGx5IGNvbm5lY3RlZCB0byB0aGUgZmFpbHVyZSBwb2ludC4gVGhpcyBhbGxvd3MgdGhl IHJlcGFpcmluZyBub2RlIGNhbiBtYWtlIHF1aWNrIGFuZCBzbWFsbCBsb2NhbCBtb2RpZmljYXRp b24gdG8gdGhlIEZJQiBzbyB0aGF0IHRyYWZmaWMgZ2V0cyByZS1yb3V0ZWQgb3ZlciB0aGUgcGVy LWNhbGN1bGF0ZWQgcmVwYWlyIHBhdGggd2l0aGluIGEgZ3VhcmFudGVlZCByZWNvdmVyeSBwZXJp b2QNCj4gDQo+IFRoaXMgZHJhZnQsIGp1c3QgbGlrZSBhbGwgKElQKUZSUiBkcmFmdHMgKGluY2x1 ZGluZyB0aG9zZSB0aGF0IHByb3RlY3QgbXVsdGljYXN0IHRyYWZmaWMpLCBhZGRyZXNzZXMgdGhl IGNhc2Ugb2YgdGhlIHJlcGFpcmluZyBub2RlIGJlaW5nIGFkamFjZW50ICB0byBmYWlsaW5nIG5l dHdvcmsgZWxlbWVudC4gRGV0ZWN0aW5nIGEgcmVtb3RlIGZhaWx1cmUgaXMgcmVhbGx5IGJleW9u ZCB0aGUgc2NvcGUNCj4gDQo+IFRoYW5rcw0KPiANCj4gQWhtZWQNCj4gDQo+IA0KPiBPbiAzLzI3 LzIwMTIgMTA6NTUgQU0sIHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIHdyb3RlOg0KPj4g SSB0b3RhbGx5IGFncmVlIHdpdGggeW91ciBwb2ludCBhcyBpZiB0aGUgUCByb3V0ZXIgaXMgbm90 IGRpcmVjdGx5IGNvbm5lY3RlZCB0byB0aGUgcHJvdGVjdGVkIFBFLCB0aGUgc29sdXRpb24gZG9l c24ndCBicmluZyBhbnkgaW1wcm92ZW1lbnQgY29tcGFyZWQgdG8gUElDIEVkZ2UuDQo+PiBUaGUg c29sdXRpb24gYXMgYSB2YWx1ZSBmb3IgYSByZXBhaXJpbmcgUCBjb25ubmVjdGVkIHRvIHRoZSBQ RSBhbmQgc28gZGV0ZWN0aW5nIHRoZSBmYWlsdXJlIGltbWVkaWF0ZWx5Lg0KPj4gSWYgdGhlIHJl cGFpcmluZyBQIGlzIHJlbW90ZSB0byB0aGUgZmFpbHVyZSwgd2UgYXJlIG5vIG1vcmUgaW4gYSBG UlIgY2FzZSAuLi4gQW5kIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgcHJldmVudGVkIC4uLg0KPj4g DQo+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+IERlIDogSmVmZiBUYW50c3VyYSBb bWFpbHRvOmplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tXQ0KPj4gRW52b3nDqSA6IG1hcmRpIDI3 IG1hcnMgMjAxMiAxMDo0NA0KPj4gw4AgOiBMSVRLT1dTS0kgU3RlcGhhbmUgRFRGL0RFUlgNCj4+ IENjIDogSWx5YSBWYXJsYXNoa2luOyBJRVRGIE1QTFMNCj4+IE9iamV0IDogUmU6IFttcGxzXSBh aFJFOiBkcmFmdC1iYXNoYW5keS1tcGxzLWxkcC1iZ3AtZnJyLTAwIG1vdGl2YXRpb24NCj4+IA0K Pj4gSGksDQo+PiANCj4+IFRoZSBzd2l0Y2hvdmVyIEFGVEVSIHRoZSBmYWlsdXJlIGhhcyBiZWVu IGRldGVjdGVkIGluIGJvdGggY2FzZXMgaXM6DQo+PiBQcmVmaXggaW5kZXBlbmRlbnQgLSBpZSBu byBSSUItPkZJQiBpbnRlcmFjdGlvbnMgU3ViIDEwMG1zIGZvcg0KPj4gcmVhc29uYWJsZSBudW1i ZXIgb2YgcHJpbWFyeS9iYWNrdXAgcGFpcnMNCj4+IA0KPj4gU28gdGhlIHJlYWwgaXNzdWUgaGVy ZSBpcyByZWxpYWJsZSBhbmQgZmFzdCBmYWlsdXJlIG5vdGlmaWNhdGlvbiENCj4+IA0KPj4gQXMg Zm9yIHRoaXMgZHJhZnQgLSBpZiB0aGUgcmVwYWlyaW5nIFAgcm91dGVyIGlzIG5vdCBkaXJlY3Rs eSBjb25uZWN0ZWQgdG8gdGhlIHByaW1hcnkgUEUgaXQgaXMgc3ViamVjdCB0byB0aGUgc2FtZSBs aW1pdGF0aW9ucyBhbmQgd291bGQgaW5pdGlhdGUgc3dpdGNob3ZlciBvbiBlaXRoZXIgbXVsdGlo b3AgQkZEIGRvd24gb3IgSUdQIGNvbnZlcmdlbmNlLg0KPj4gRXZlbiB0aG91Z2ggaXQgaXMgcHJl c3VtYWJseSBjbG9zZXIgdG8gdGhlIGZhaWx1cmUgdGhhbiBpbmdyZXNzIFBFIGFuZCBjb3VsZCBy ZWFjdCBmYXN0ZXIgSU1ITyB0aGUgY29tcGxleGl0eSBpbnRyb2R1Y2VkIGlzIHJhdGhlciBzaWdu aWZpY2FudCBjb21wYXJlZCB0byB0aGUgZ2Fpbi4NCj4+IA0KPj4gUmVnYXJkcywNCj4+IEplZmYN Cj4+IA0KPj4gT24gTWFyIDI3LCAyMDEyLCBhdCAxMDoyMSBBTSwgInN0ZXBoYW5lLmxpdGtvd3Nr aUBvcmFuZ2UuY29tIiA8c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+IHdyb3RlOg0KPj4g DQo+Pj4gSWx5YSwNCj4+PiANCj4+PiBUaGUgYmVzdCBjdXJyZW50IGF2YWlsYWJsZSBtZWNoYW5p c20gaXMgQkdQIFBJQyBFZGdlIHRoYXQgcmVsYXkgb24gSUdQIGNvbnZlcmdlbmNlIHRvIGRldGVj dCB0aGF0IHJlbW90ZSBQRSBpcyBubyBsb25nZXIgcmVhY2hhYmxlIDogUElDIEVkZ2UgcmVzdWx0 IG1haW5seSBkZXBlbmRzIG9uIGhvdyBmYXN0IHlvdXIgSUdQIGlzIGNvbnZlcmdpbmcgKHN1YiBz ZWMgb3IgbW9yZSkuDQo+Pj4gDQo+Pj4gQWhtZWQgc29sdXRpb24gaXMgYW4gRlJSIHNvbHV0aW9u IHNvIGRvZXNuJ3QgcmVseSBvbiBjb252ZXJnZW5jZS4gQXMgc29vbiBhcyBhIFAgcm91dGVyIGRl dGVjdHMgdGhhdCB0aGUgbGluayB0byB0aGUgcHJvdGVjdGVkIFBFIGZhaWxzLCBpdCB3aWxsIHN3 aXRjaCAodXNpbmcgcHJlLXByb2dyYW1tZWQgYmFja3VwIE5ITEZFKSwgc28gdGhlcmUgeW91IGFy ZSBpbiBGUlIgbnVtYmVycyAuLi4gNTBtc2VjIC0gMTAwbXNlYyBkZXBlbmRpbmcgb2YgaW1wbGVt ZW50YXRpb24gLi4uDQo+Pj4gDQo+Pj4gQ2xlYXJseSB0aGUgc29sdXRpb24gaXMgdG9kYXkgY29t cGxleCwgYW5kIEkgaG9wZSBpdCBjb3VsZCBiZSBhIGJpdA0KPj4+IHNpbXBsaWZpZWQgOikNCj4+ PiANCj4+PiBSZWdhcmRzLA0KPj4+IA0KPj4+IFN0ZXBoYW5lDQo+Pj4gDQo+Pj4gDQo+Pj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4gRGUgOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQNCj4+PiBkZSBJbHlhIFZh cmxhc2hraW4gRW52b3nDqSA6IG1hcmRpIDI3IG1hcnMgMjAxMiAxMDowOCDDgCA6IElFVEYgTVBM Uw0KPj4+IE9iamV0IDogW21wbHNdIGRyYWZ0LWJhc2hhbmR5LW1wbHMtbGRwLWJncC1mcnItMDAg bW90aXZhdGlvbg0KPj4+IA0KPj4+IEFobWVkLCBLYW1yYW4sDQo+Pj4gDQo+Pj4gYXMgZmlyc3Qg ZXhwcmVzc2VkIGF0IHRoZSBtaWMgZHVyaW5nIE1QTFMgc2Vzc2lvbiwgSSdkIGxpa2UgdG8gYXNr IHlvdSBmb3IgYSBjbGFyaWZpY2F0aW9uIG9mIHRoZSBtb3RpdmF0aW9uIGJlaGluZCB0aGUgZHJh ZnQuIFlvdSBzYXkgdGhhdCB0aGlzIGRyYWZ0IHdpbGwgcHJvdmlkZSBmYXN0ZXIgc3dpdGNoLW92 ZXIvZmFpbC1vdmVyIHRpbWUgY29tcGFyZSB0byBhbnl0aGluZyBhbHJlYWR5IGV4aXN0aW5nIHRv ZGF5LiBEbyB5b3UgaGF2ZSBzb21lIG51bWJlcnMgZm9yIGNvbXBhcmlzb24/DQo+Pj4gDQo+Pj4g L2lMeWENCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4gbXBsc0BpZXRmLm9yZw0KPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4+IA0KPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+IF8gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4gDQo+Pj4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+Pj4gY29uZmlkZW50aWVsbGVzIG91IHBy aXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsDQo+Pj4gZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZQ0KPj4+IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIEZyYW5j ZSBUZWxlY29tIC0gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz c2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPj4+IA0KPj4+ IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvcg0KPj4+IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo b3V0IGF1dGhvcmlzYXRpb24uDQo+Pj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuDQo+Pj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFu Y2UgVGVsZWNvbSAtIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+Pj4gVGhhbmsgeW91Lg0KPj4+ IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+PiBtcGxzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IA0KPj4g Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5m b3JtYXRpb25zDQo+PiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywNCj4+IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UNCj4+IHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNp IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50 IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPj4gDQo+PiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCj4+IHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+PiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4+IEFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLg0KPj4gVGhhbmsgeW91Lg0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+IG1wbHNAaWV0 Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiAN Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gDQo+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBGcmFuY2UgVGVsZWNvbSAtIE9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4gDQo+IFRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4g QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBpcyBub3Qg bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuDQo+IFRoYW5rIHlvdS4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IElkciBtYWlsaW5nIGxpc3QNCj4gSWRyQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IA0KPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl bmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu ZSBkb2l2ZW50IGRvbmMNCj4gcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1 ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCj4gYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj4gRnJhbmNlIFRlbGVjb20gLSBPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+IA0KPiBUaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KPiB0aGV5IHNob3VsZCBub3Qg YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLg0KPiBUaGFuayB5b3UuDQo+IA0K From jakob.heitz@ericsson.com Thu Mar 29 00:37:41 2012 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 30FD521F8664; Thu, 29 Mar 2012 00:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 0ep5X-NKT2kd; Thu, 29 Mar 2012 00:37:40 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id DDBE221F865E; Thu, 29 Mar 2012 00:37:38 -0700 (PDT) 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 q2T7batg020881; Thu, 29 Mar 2012 02:37:38 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 29 Mar 2012 03:37:31 -0400 From: Jakob Heitz To: Jeffrey Haas , sidr wg list Date: Thu, 29 Mar 2012 03:38:00 -0400 Thread-Topic: [Idr] AS_SET depreciation (RFC6472) and BGP multipath Thread-Index: Ac0NfswdCrXhNNkERAWjzsbUAFPwEQ== Message-ID: <3C0C3A96-8AFD-4AD6-A571-5896DD370806@ericsson.com> References: <4F72166F.6080503@raszuk.net> <20120328210335.GB16814@slice> <4F737DF4.7030202@raszuk.net> <24F722F3-4D36-40D4-83FE-27B14CB5B9ED@tony.li> <5FE465B7-5005-4FE4-B97C-0608C9F9A45C@ericsson.com> <20120329071053.GA6831@slice> In-Reply-To: <20120329071053.GA6831@slice> 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 List" , Tony Li , "robert@raszuk.net" Subject: Re: [Idr] AS_SET depreciation (RFC6472) and BGP multipath 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 Mar 2012 07:37:41 -0000 of course, we would need to reinvent the AS_SET to go along with it, but th= is time, enumerating each exact path. Definitely unwieldy. -- Jakob Heitz. On Mar 29, 2012, at 9:10 AM, "Jeffrey Haas" wrote: > On Wed, Mar 28, 2012 at 05:57:32PM -0400, Jakob Heitz wrote: >> This can be done. >> Like I said before: aggregate the signatures of the paths being aggregat= ed. >> String all the signed paths together (after wrapping them with a header)= , add your SKI and destination AS (as normal) and sign over the lot. >>=20 >> Question is: does anyone want to? >=20 > At minimum, this would further decouple the signature from the actual pat= h. >=20 > And given multipath covers *many* routes, the result would likely be > unwieldy. >=20 > -- Jeff From stephane.litkowski@orange.com Thu Mar 29 00:54:04 2012 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 2765421F8913 for ; Thu, 29 Mar 2012 00:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=0.476, 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 hLqYBPO6jTOM for ; Thu, 29 Mar 2012 00:54:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id A419121F88D9 for ; Thu, 29 Mar 2012 00:53:59 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id E594732437D; Thu, 29 Mar 2012 09:53:57 +0200 (CEST) Received: from PUEXCC51.nanterre.francetelecom.fr (unknown [10.168.74.61]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C90FE27C046; Thu, 29 Mar 2012 09:53:57 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC51.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 09:53:57 +0200 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 Mar 2012 09:53:56 +0200 Message-ID: <5850_1333007637_4F741515_5850_6668_1_4FC3556A36EE3646A09DAA60429F5335080A30F7@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <0B142F23-9504-4497-BBAD-415D9B208976@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] [mpls] RE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation vs BGP anycast Thread-Index: Ac0NfYbRZBhM1iKKTtGfW7KUUnDI4QAAfl7w References: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com> <11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr> <17281_1332838526_4F71807E_17281_577_1_4FC3556A36EE3646A09DAA60429F53350804C77B@PUEXCBL0.nanterre.francetelecom.fr> <4F72E529.4030800@cisco.com> <27841_1332936595_4F72FF93_27841_563_1_4FC3556A36EE3646A09DAA60429F5335080A2D5B@PUEXCBL0.nanterre.francetelecom.fr> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFDA43@EUSAACMS0701.eamcs.ericsson.se> <19431_1332999998_4F73F73E_19431_9159_1_4FC3556A36EE3646A09DAA60429F5335080A2FBE@PUEXCBL0.nanterre.francetelecom.fr> <0B142F23-9504-4497-BBAD-415D9B208976@ericsson.com> From: To: "Jakob Heitz" X-OriginalArrivalTime: 29 Mar 2012 07:53:57.0910 (UTC) FILETIME=[18A63360:01CD0D81] X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.29.73316 Cc: idr@ietf.org Subject: Re: [Idr] [mpls] RE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation vs BGP anycast 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 Mar 2012 07:54:04 -0000 Inline comments ...=20 -----Message d'origine----- De : Jakob Heitz [mailto:jakob.heitz@ericsson.com]=20 Envoy=E9 : jeudi 29 mars 2012 09:29 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Ahmed Bashandy; idr@ietf.org Objet : Re: [Idr] [mpls] RE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation = vs BGP anycast On Mar 29, 2012, at 7:46 AM, "stephane.litkowski@orange.com" wrote: > Jakob, >=20 > BGP Anycast and Ahmed's solution sound very similar. >=20 > BGP Anycast : > - Protector PE definition seems manual as far as I know Not if the protecting PE is the protector. [SLI] Here it is more implementation dependent ... But based on the only im= plementation I know, you always still to configure the protector. > - LFA used as protection mechanism on P thanks to Anycast feature=20 > (same virtual loopback used on primary and repair PE) =3D> 100% coverage= =20 > not guaranteed If no LFA, then it's IGP convergence. Same with Ahmed's draft. [SLI] Ahmed draft doesn't require any LFA. And doesn't care about loop free= path (labels are changed on another LSP using another target FEC is used).= The only case where there is no protection is when the protector is reacha= ble through the primary egress PE (cascaded PE case ...) > - Still need to advertise virtual loopbacks in ISIS and LDP > - Requires also usage of repair label draft to prevent loops What loops? [SLI] Sorry my mistake, no loop here as Primary egress is down (I was confu= sed compared to PE-CE link protection case) > - Possibly requires a small change in the way to advertise LDP FEC for vi= rtual loopbacks (depending on current vendor implementation) =3D> no PHP re= quired but most vendors are doing PHP by default. > - One core state per VPN protected The only core state is the alternate path to the anycast. [SLI] Yes but there is one anycast per VPN ... I'm not pushing one or other solution today, both have pros and cons ... > - Possibly suboptimal routing when using centralized protector PEs. >=20 > BGP-edge-node-frr : > - Protector PE definition is automatic (no configuration), and chosen by = primary PE and his per CE. > - New extension used to signal protection decision to P router > - New loopbacks advertised in ISIS and LDP. > - Basically more optimal routing (BGP anycast can achieve the same but=20 > it requires a lot of configuration of many different PEs) > - One core state per CE protected (per VPN possible but may cause=20 > loop) >=20 >=20 > Correct me if I missed something. >=20 > Regards, >=20 > Stephane >=20 > -----Message d'origine----- > De : Jakob Heitz [mailto:jakob.heitz@ericsson.com] Envoy=E9 : mercredi=20 > 28 mars 2012 18:35 =C0 : Ahmed Bashandy Cc : idr@ietf.org; LITKOWSKI=20 > Stephane DTF/DERX Objet : RE: [Idr] [mpls] ahRE:=20 > draft-bashandy-mpls-ldp-bgp-frr-00 motivation >=20 > Ahmed, >=20 > BGP PIC Edge is not the only existing solution. > Look at "5.1.8.4.1. Anycast BGP applied to ABR node failure" > in http://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-01 >=20 > That looks much simpler. How is yours better than this? >=20 > -- > Jakob Heitz. >=20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of=20 > stephane.litkowski@orange.com > Sent: Wednesday, March 28, 2012 5:10 AM > To: Ahmed Bashandy > Cc: idr@ietf.org > Subject: Re: [Idr] [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00=20 > motivation >=20 > [Moving to IDR list ...] >=20 > Yes, when we are aware about FRR technics, it's clear but there is some l= ines in the doc, that could lead to understand that every P may install a r= epair ... >=20 > If you are using LDP or ISIS (and especially ISIS which use flooding of L= SP) to advertise the (NHi,rNHi) or (Nhi,rNHi,Li,Push), every P router will = receive the info (could not be the case with LDP ..., but it's not welle de= tailled that your LDP TLV must not be propagated upstream). I don't see som= ething in the drafts (ISIS or BGP drafts) preventing remote P to install a = backup entry ... >=20 > Based on Step 4 at =A72.4 of the BGP draft, any P has a route to the BGP = nexthop, and so is able to compute alternate path ... >=20 > How do you prevent it to happen ? >=20 >=20 >=20 > -----Message d'origine----- > De : Ahmed Bashandy [mailto:bashandy@cisco.com] Envoy=E9 : mercredi 28=20 > mars 2012 12:17 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Jeff Tantsura;=20 > IETF MPLS Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00=20 > motivation >=20 > The basic idea behind any (IP)FRR mechanism is to have the repairing=20 > node per-calculate the repair path and be directly connected to the=20 > failure point. This allows the repairing node can make quick and small=20 > local modification to the FIB so that traffic gets re-routed over the=20 > per-calculated repair path within a guaranteed recovery period >=20 > This draft, just like all (IP)FRR drafts (including those that protect=20 > multicast traffic), addresses the case of the repairing node being=20 > adjacent to failing network element. Detecting a remote failure is=20 > really beyond the scope >=20 > Thanks >=20 > Ahmed >=20 >=20 > On 3/27/2012 10:55 AM, stephane.litkowski@orange.com wrote: >> I totally agree with your point as if the P router is not directly conne= cted to the protected PE, the solution doesn't bring any improvement compar= ed to PIC Edge. >> The solution as a value for a repairing P connnected to the PE and so de= tecting the failure immediately. >> If the repairing P is remote to the failure, we are no more in a FRR cas= e ... And I think this should be prevented ... >>=20 >> -----Message d'origine----- >> De : Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] >> Envoy=E9 : mardi 27 mars 2012 10:44 >> =C0 : LITKOWSKI Stephane DTF/DERX >> Cc : Ilya Varlashkin; IETF MPLS >> Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00=20 >> motivation >>=20 >> Hi, >>=20 >> The switchover AFTER the failure has been detected in both cases is: >> Prefix independent - ie no RIB->FIB interactions Sub 100ms for=20 >> reasonable number of primary/backup pairs >>=20 >> So the real issue here is reliable and fast failure notification! >>=20 >> As for this draft - if the repairing P router is not directly connected = to the primary PE it is subject to the same limitations and would initiate = switchover on either multihop BFD down or IGP convergence. >> Even though it is presumably closer to the failure than ingress PE and c= ould react faster IMHO the complexity introduced is rather significant comp= ared to the gain. >>=20 >> Regards, >> Jeff >>=20 >> On Mar 27, 2012, at 10:21 AM, "stephane.litkowski@orange.com" wrote: >>=20 >>> Ilya, >>>=20 >>> The best current available mechanism is BGP PIC Edge that relay on IGP = convergence to detect that remote PE is no longer reachable : PIC Edge resu= lt mainly depends on how fast your IGP is converging (sub sec or more). >>>=20 >>> Ahmed solution is an FRR solution so doesn't rely on convergence. As so= on as a P router detects that the link to the protected PE fails, it will s= witch (using pre-programmed backup NHLFE), so there you are in FRR numbers = ... 50msec - 100msec depending of implementation ... >>>=20 >>> Clearly the solution is today complex, and I hope it could be a bit=20 >>> simplified :) >>>=20 >>> Regards, >>>=20 >>> Stephane >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] De la part=20 >>> de Ilya Varlashkin Envoy=E9 : mardi 27 mars 2012 10:08 =C0 : IETF MPLS= =20 >>> Objet : [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation >>>=20 >>> Ahmed, Kamran, >>>=20 >>> as first expressed at the mic during MPLS session, I'd like to ask you = for a clarification of the motivation behind the draft. You say that this d= raft will provide faster switch-over/fail-over time compare to anything alr= eady existing today. Do you have some numbers for comparison? >>>=20 >>> /iLya >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>> ____________________________________________________________________ >>> _ _ ___________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, France Telecom - Orange decline toute responsabilite si c= e message a ete altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or=20 >>> privileged information that may be protected by law; they should not be= distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, France Telecom - Orange is not liable for mes= sages that have been modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> _____________________________________________________________________ >> _ ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, 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=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> 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 is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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 o= u 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, us= ed or copied without authorisation. > 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 is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > 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 is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 ___________________________________________________________________________= ______________________________________________ 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 authorisation. 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 is not liable for message= s that have been modified, changed or falsified. Thank you. From jhaas@slice.pfrc.org Thu Mar 29 01:21:04 2012 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 76B2921F8A03; Thu, 29 Mar 2012 01:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.169 X-Spam-Level: X-Spam-Status: No, score=-102.169 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 UzmKC4-dPbEW; Thu, 29 Mar 2012 01:21:04 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E06ED21F8A07; Thu, 29 Mar 2012 01:21:03 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id AC599170429; Thu, 29 Mar 2012 04:21:03 -0400 (EDT) Date: Thu, 29 Mar 2012 04:21:03 -0400 From: Jeffrey Haas To: "Murphy, Sandra" Message-ID: <20120329082103.GC9609@slice> References: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB73F@Hermes.columbia.ads.sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB73F@Hermes.columbia.ads.sparta.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" , Paul Jakma , "robert@raszuk.net" , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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 Mar 2012 08:21:04 -0000 Sandy, On Wed, Mar 28, 2012 at 05:00:43PM +0000, Murphy, Sandra wrote: > Replacing ASs in the AS_PATH sounds like a behavior you would want the security protections to prohibit. It would enable attacks. > > Can you explain how you would distinguish legitimate uses of this feature? The feature is typically used on private AS numbers. One could point out that any procedures dealing with them are probably out of scope of SIDR. :-) -- Jeff From shares@ndzh.com Thu Mar 29 02:29:34 2012 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 9150221F886E; Thu, 29 Mar 2012 02:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.465 X-Spam-Level: X-Spam-Status: No, score=0.465 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 5OJuqv-Djm7x; Thu, 29 Mar 2012 02:29:34 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [63.208.161.199]) by ietfa.amsl.com (Postfix) with ESMTP id A919C21F8970; Thu, 29 Mar 2012 02:29:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=130.129.18.145; Received: from SKH2012HPLT (unverified [130.129.18.145]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3214306-1945496 for multiple; Thu, 29 Mar 2012 04:29:28 -0500 From: "Susan Hares" To: "'Jeffrey Haas'" , "'Jakob Heitz'" References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <20120328211728.GD16814@slice> In-Reply-To: <20120328211728.GD16814@slice> Date: Thu, 29 Mar 2012 05:29:26 -0400 Message-ID: <00d001cd0d8e$70649710$512dc530$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHUVGlAkFUTNdWUzptD3/gnNKFqTQDFVHs7Af0Ug1QCqr2q1AI0RKHPAlc5mOoCBoopmAGbNBMlAbvhU4qV97x08A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: idr@ietf.org, 'Tony Li' , 'Paul Jakma' , 'Robert Raszuk' , 'sidr wg list' Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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 Mar 2012 09:29:34 -0000 Jeff and Jakob: Several people shared the qualm that "AS-SETS" would be necessary. However, Sandy has always posited that aggregation creates a point of change/risk. So, are we just trying to reduce this risk by providing lists of certificates for paths? Or is would an AS-Sets originated at a point in the network - have the security information to consider the existing certificates and generate a valid certificate. Sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Wednesday, March 28, 2012 5:17 PM To: Jakob Heitz Cc: idr@ietf.org List; Tony Li; Paul Jakma; Robert Raszuk; sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath On Wed, Mar 28, 2012 at 10:56:52AM -0400, Jakob Heitz wrote: > The issue is SIDR can not aggregate multiple paths. > > Solutions I can think of: > 1. Aggregate the signatures of the paths being aggregated. What are the semantics you're trying to preserve SIDR-wise? We're hitting the realm where Russ White would point out that BGP path validation can't prove how forwarding works. Presume we managed to pass along two distinct paths for the same multi-path route in BGP. What do you do if one doesn't validate? What do you do if they do, but you think this is a form of a "route leak" for one path? As a receiver of the route that is making use of multipath, you can't selectively choose which sub-paths to take. (It's not like we're gettng something like MPLS entropy labels.) > 2. Don't aggregate, but send both paths. That doesn't cover the actual forwarding semantics. > Should SIDR work on path aggregation? > Are there other possibilities? The biggest problem here is "SIDR secures BGP". The issue hasn't been clear in BGP for years, although I'm perhaps of the cynical opinion that it's been a well understood problem space for a while now. The protocol doesn't reflect what is done operationally. The safe thing operationally when aggregating unsafe paths is to generate sets, but some people have never liked sets. And as I mentioned elsewhere, it doesn't matter as long as you take care in where you redistribute such unsafe multipath. There was a reason I wasn't terribly supportive of the deprecating AS_SETs I-D. However, I also knew it was a losing battle. :-) -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From bashandy@cisco.com Thu Mar 29 05:54:05 2012 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 556C421F8AB9 for ; Thu, 29 Mar 2012 05:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 YZ7h+kQc+G0t for ; Thu, 29 Mar 2012 05:54:03 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5834921F8A7B for ; Thu, 29 Mar 2012 05:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=9246; q=dns/txt; s=iport; t=1333025643; x=1334235243; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ByVOb61ATyw4m8dr5CO8bFhpyz1JEq7iWfL9vUYVplU=; b=gul7PiYIMyu7crDbcmuHpo5G/a0p+oQFonEcWxB3Gm6LZ8VPEW9xzs3Z zT9njHzIlSBA6/48aQeMhbgAFPewQyUGcgoTZXOPf8BEQEe+99J+VnXj/ lytqajkTW9WB6p/mqZve5u6a9EZ/gHM9sRkuRoaMwDuNMfjUbhE0qGRak M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMBadE+rRDoH/2dsb2JhbABEuQ2BB4IJAQEBBAEBAQ8BFAk8AggDBQcEAgEIEQQBAQEKBhcBBgEmHwkIAQEEEwgTB4dnDJtpnyCQPGMEiCUzjhqNNYFogweBPA X-IronPort-AV: E=Sophos;i="4.73,668,1325462400"; d="scan'208";a="38198788" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 29 Mar 2012 12:54:03 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2TCs2Ia003106; Thu, 29 Mar 2012 12:54:02 GMT Received: from xmb-sjc-217.amer.cisco.com ([171.70.151.175]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 05:54:02 -0700 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 Mar 2012 05:53:57 -0700 Message-ID: In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFDA43@EUSAACMS0701.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation Thread-Index: Ac0My/4LNoRXji8nRyuw6EmO8k6gfQAC1BOwAAovX8AAADTREA== References: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com><11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr><17281_1332838526_4F71807E_17281_577_1_4FC3556A36EE3646A09DAA60429F53350804C77B@PUEXCBL0.nanterre.francetelecom.fr><4F72E529.4030800@cisco.com> <27841_1332936595_4F72FF93_27841_563_1_4FC3556A36EE3646A09DAA60429F5335080A2D5B@PUEXCBL0.nanterre.francetelecom.fr> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFDA43@EUSAACMS0701.eamcs.ericsson.se> From: "Ahmed Bashandy (bashandy)" To: "Jakob Heitz" X-OriginalArrivalTime: 29 Mar 2012 12:54:02.0791 (UTC) FILETIME=[04650370:01CD0DAB] Cc: idr@ietf.org Subject: Re: [Idr] [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation 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 Mar 2012 12:54:05 -0000 Thanks for pointing that out to me. I'll read the draft and get back to = you soon Thanks Ahmed -----Original Message----- From: Jakob Heitz [mailto:jakob.heitz@ericsson.com]=20 Sent: Wednesday, March 28, 2012 6:35 PM To: Ahmed Bashandy (bashandy) Cc: idr@ietf.org; stephane.litkowski@orange.com Subject: RE: [Idr] [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 = motivation Ahmed, BGP PIC Edge is not the only existing solution. Look at "5.1.8.4.1. Anycast BGP applied to ABR node failure" in http://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-01 That looks much simpler. How is yours better than this? -- Jakob Heitz. -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = stephane.litkowski@orange.com Sent: Wednesday, March 28, 2012 5:10 AM To: Ahmed Bashandy Cc: idr@ietf.org Subject: Re: [Idr] [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 = motivation [Moving to IDR list ...] Yes, when we are aware about FRR technics, it's clear but there is some = lines in the doc, that could lead to understand that every P may install = a repair ... If you are using LDP or ISIS (and especially ISIS which use flooding of = LSP) to advertise the (NHi,rNHi) or (Nhi,rNHi,Li,Push), every P router = will receive the info (could not be the case with LDP ..., but it's not = welle detailled that your LDP TLV must not be propagated upstream). I = don't see something in the drafts (ISIS or BGP drafts) preventing remote = P to install a backup entry ... Based on Step 4 at =A72.4 of the BGP draft, any P has a route to the BGP = nexthop, and so is able to compute alternate path ... How do you prevent it to happen ? -----Message d'origine----- De : Ahmed Bashandy [mailto:bashandy@cisco.com]=20 Envoy=E9 : mercredi 28 mars 2012 12:17 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Jeff Tantsura; IETF MPLS Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation The basic idea behind any (IP)FRR mechanism is to have the repairing = node per-calculate the repair path and be directly connected to the = failure point. This allows the repairing node can make quick and small = local modification to the FIB so that traffic gets re-routed over the = per-calculated repair path within a guaranteed recovery period This draft, just like all (IP)FRR drafts (including those that protect = multicast traffic), addresses the case of the repairing node being = adjacent to failing network element. Detecting a remote failure is = really beyond the scope Thanks Ahmed On 3/27/2012 10:55 AM, stephane.litkowski@orange.com wrote: > I totally agree with your point as if the P router is not directly = connected to the protected PE, the solution doesn't bring any = improvement compared to PIC Edge. > The solution as a value for a repairing P connnected to the PE and so = detecting the failure immediately. > If the repairing P is remote to the failure, we are no more in a FRR = case ... And I think this should be prevented ... > > -----Message d'origine----- > De : Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > Envoy=E9 : mardi 27 mars 2012 10:44 > =C0 : LITKOWSKI Stephane DTF/DERX > Cc : Ilya Varlashkin; IETF MPLS > Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation > > Hi, > > The switchover AFTER the failure has been detected in both cases is: > Prefix independent - ie no RIB->FIB interactions Sub 100ms for=20 > reasonable number of primary/backup pairs > > So the real issue here is reliable and fast failure notification! > > As for this draft - if the repairing P router is not directly = connected to the primary PE it is subject to the same limitations and = would initiate switchover on either multihop BFD down or IGP = convergence. > Even though it is presumably closer to the failure than ingress PE and = could react faster IMHO the complexity introduced is rather significant = compared to the gain. > > Regards, > Jeff > > On Mar 27, 2012, at 10:21 AM, "stephane.litkowski@orange.com" = wrote: > >> Ilya, >> >> The best current available mechanism is BGP PIC Edge that relay on = IGP convergence to detect that remote PE is no longer reachable : PIC = Edge result mainly depends on how fast your IGP is converging (sub sec = or more). >> >> Ahmed solution is an FRR solution so doesn't rely on convergence. As = soon as a P router detects that the link to the protected PE fails, it = will switch (using pre-programmed backup NHLFE), so there you are in FRR = numbers ... 50msec - 100msec depending of implementation ... >> >> Clearly the solution is today complex, and I hope it could be a bit=20 >> simplified :) >> >> Regards, >> >> Stephane >> >> >> -----Message d'origine----- >> De : mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] De la part=20 >> de Ilya Varlashkin Envoy=E9 : mardi 27 mars 2012 10:08 =C0 : IETF = MPLS=20 >> Objet : [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation >> >> Ahmed, Kamran, >> >> as first expressed at the mic during MPLS session, I'd like to ask = you for a clarification of the motivation behind the draft. You say that = this draft will provide faster switch-over/fail-over time compare to = anything already existing today. Do you have some numbers for = comparison? >> >> /iLya >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, = >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> 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=20 >> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > 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=20 > privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _________________________________________________________________________= ________________________________________________ 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 = recu 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 authorisation. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From Sandra.Murphy@sparta.com Wed Mar 28 10:00:59 2012 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 A35CF21E82A8; Wed, 28 Mar 2012 10:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 5sApDSMrkhgw; Wed, 28 Mar 2012 10:00:59 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id F258621E8254; Wed, 28 Mar 2012 10:00:58 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2SH0tC1028116; Wed, 28 Mar 2012 12:00:55 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2SH0jrM018452; Wed, 28 Mar 2012 12:00:45 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Wed, 28 Mar 2012 13:00:44 -0400 From: "Murphy, Sandra" To: "robert@raszuk.net" , Christopher Morrow Thread-Topic: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath Thread-Index: AQHNDP4G0vO63JE6pUGZF6souGb62JaAKQqAgAACWYCAAAGNAP//vzar Date: Wed, 28 Mar 2012 17:00:43 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB73F@Hermes.columbia.ads.sparta.com> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> , <4F733FBE.1020902@raszuk.net> In-Reply-To: <4F733FBE.1020902@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 29 Mar 2012 08:07:41 -0700 Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath 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, 28 Mar 2012 17:00:59 -0000 Replacing ASs in the AS_PATH sounds like a behavior you would want the secu= rity protections to prohibit. It would enable attacks.=0A= =0A= Can you explain how you would distinguish legitimate uses of this feature?= =0A= =0A= --Sandy=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Robert Ras= zuk [robert@raszuk.net]=0A= Sent: Wednesday, March 28, 2012 12:43 PM=0A= To: Christopher Morrow=0A= Cc: idr@ietf.org List; Paul Jakma; sidr wg list=0A= Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath= =0A= =0A= >> Are we going to freeze any AS_PATH modifications by operator's policy to= o ?=0A= >> I mentioned replace-as which all major vendors support. There can be mor= e=0A= >> knobs like this coming in the future.=0A= >=0A= > replace as i think is dealt with .... sign again and pcount=3D0 and move = along.=0A= =0A= replace-as allows to replace any arbitrary match of list of ASes in the=0A= AS_PATH by your own AS. Does not need to be the last one.=0A= =0A= I don't think SIDR has a solution to deal with such policy.=0A= =0A= Best regards,=0A= R.=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From paul@jakma.org Fri Mar 30 02:39:54 2012 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 9AE2921F8941 for ; Fri, 30 Mar 2012 02:39:54 -0700 (PDT) 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 W4mzzlkk6d5m for ; Fri, 30 Mar 2012 02:39:52 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 57E2C21F868A for ; Fri, 30 Mar 2012 02:39:52 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so263803wgb.13 for ; Fri, 30 Mar 2012 02:39:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:x-gm-message-state:content-type; bh=4TzvcKdfRrH370Zm7WXj0R2F+dXZ+B3mGLS7bKhq0LE=; b=Ph8y/G3AJmbpGD5d0FvpOR1dKn8s+yYtrtF2mHMwGmSyM3HwsY+eAeM34RH6MC5lBO 1HOWsaZ5BvPCG4i+ptNsCxJd7RPs0IppsGFm6/AXFLR5eOSWDxz9+s/RkDMR54Ba05Y+ WzK59mRQPG4h9nQVyfpTfmRMG4Y87A67dcRoQcl0x/BBUgcst29p8Rf+WoGQZfRFoEEe xzYcF7DVEayGvwbuWDVTi/rZwbksUbreeTkFaO8qd2RERYp22vNX3gcoiJSFkNWFwbcP KmzaUSUq7O/w/rHvOpc/xT2xuup674dgIEpzcxTVXODaEVxf9QFuzOpqi1w0Wyv6ZBVB jWtw== Received: by 10.180.79.135 with SMTP id j7mr4589741wix.19.1333100391365; Fri, 30 Mar 2012 02:39:51 -0700 (PDT) Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk. [130.209.244.4]) by mx.google.com with ESMTPS id 17sm13787566wis.0.2012.03.30.02.39.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Mar 2012 02:39:50 -0700 (PDT) Date: Fri, 30 Mar 2012 10:39:48 +0100 (BST) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: Tony Li In-Reply-To: <24F722F3-4D36-40D4-83FE-27B14CB5B9ED@tony.li> Message-ID: References: <4F72166F.6080503@raszuk.net> <20120328210335.GB16814@slice> <4F737DF4.7030202@raszuk.net> <24F722F3-4D36-40D4-83FE-27B14CB5B9ED@tony.li> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 X-Gm-Message-State: ALoCoQnXwePDd7GGREoikp3z6gEQVxkbISQ2aIkZA76yQWtYiUHpoOzIb9LMuBybxE+ku9jZtD3h Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "idr@ietf.org List" , robert@raszuk.net Subject: Re: [Idr] AS_SET depreciation (RFC6472) and BGP multipath 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, 30 Mar 2012 09:39:54 -0000 On Wed, 28 Mar 2012, Tony Li wrote: > Understood, but how do you ever secure this? Set SIDR aside for a > second, what would ANY path verification mechanism have to do to secure > the full path? > It would seem that the ONLY thing one could reasonably do is to describe > the full topology, and that would seem to require the ability to > describe an arbitrary tree, not just a set of vectors of paths. Compact routing schemes in the future might also want to be able to collect together and summarise parts of the network in some way. Figuring out how to achieve *both* scalable and secure routing would be a nice research topic. regards, -- Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: The more you sweat in peace, the less you bleed in war.