IETF Logo Mail Archive

Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt

"Keyur Patel (keyupate)" <keyupate@cisco.com> Thu, 06 February 2014 20:23 UTC

Return-Path: <keyupate@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622EF1A04C1 for <idr@ietfa.amsl.com>; Thu, 6 Feb 2014 12:23:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.036
X-Spam-Level:
X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-NqjAp5JfZv for <idr@ietfa.amsl.com>; Thu, 6 Feb 2014 12:23:52 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1841A1A04C4 for <idr@ietf.org>; Thu, 6 Feb 2014 12:23:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1379; q=dns/txt; s=iport; t=1391718231; x=1392927831; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vkreqrkUN14zNhQLFhD9868S3EYWa8LSaHH+2xH6c9w=; b=DIbgv7WrHlxKvpi9ZTRYjFRNeuIJO135qCin2pZxprumnEl74SOj9o6O ypArMsz7z4pGUxHSnBxPxaTP/CMLwxBIjSCkbmDohW1QdH5D49ellWXNv A+qcS/+745pOu+ntX+1uMqMcidoqwyRqr0K+MomvpYNR3Ca0ukRfMyPvs o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAGvu81KtJV2Z/2dsb2JhbABZgwyBD75zgQ0WdIIlAQEBBDo/EgEIDgoeQiUCBA4FiAXNKBeOegeEOAEDlEKDaZIhgy2CKg
X-IronPort-AV: E=Sophos;i="4.95,795,1384300800"; d="scan'208";a="302379047"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 06 Feb 2014 20:23:50 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s16KNokg005695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 20:23:51 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.117]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 14:23:50 -0600
From: "Keyur Patel (keyupate)" <keyupate@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt
Thread-Index: AQHPI3lYDal1f7T6ogADUl2weXy9pg==
Date: Thu, 06 Feb 2014 20:23:49 +0000
Message-ID: <CF192FC8.62EAE%keyupate@cisco.com>
In-Reply-To: <20140206201254.GG23551@pfrc>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [128.107.163.63]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B97EAC04D4F5B8418F11DA9FD0725F95@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org" <idr@ietf.org>, Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 20:23:55 -0000

On 2/6/14 12:12 PM, "Jeffrey Haas" <jhaas@pfrc.org> wrote:

>Keyur,
>
>On Thu, Feb 06, 2014 at 05:51:10PM +0000, Keyur Patel (keyupate) wrote:
>> As part of rev 6, we added the following to Section 4:
>
>It was this text that brought the case to mind.
>
>> <snip>
>> The following procedures are specified in order to simplify the
>>    interaction with the BGP Graceful Restart [RFC4724].  For a BGP
>>    speaker that supports the BGP Graceful Restart, it MUST NOT send a
>>    BoRR for an AFI/SAFI to a neighbor before it sends the EOR for the
>>    AFI/SAFI to the neighbor.  A BGP speaker that has received the
>>    Graceful Restart Capability from its neighbor, MUST ignore any BoRRs
>>    for an AFI/SAFI from the neighbor before the speaker receives the EoR
>>    for the given AFI/SAFI from the neighbor.  The BGP speaker SHOULD log
>>    an error of the condition for further analysis.
>> 
>> <snip>
>
>The distinction is that I think we shouldn't ask for enhanced RRs (or
>process them if restarting) until restart procedures are concluded.  The
>above text makes it ok to request one for a given afi/safi once that
>afi/safi has sent eor.

Right. I don't know if we can control the "ask". But the text above
ensures (like you said) that the refresh reply will be delayed till EOR is
serviced.

Regards,
Keyur
 
>
>-- Jeff

v2.23.0 | Report a Bug | By Email