[Idr] draft-uttaro-idr-bgp-persistence-00

Robert Raszuk <robert@raszuk.net> Fri, 21 October 2011 22:23 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7C62421F8876 for <idr@ietfa.amsl.com>; Fri, 21 Oct 2011 15:23:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id qCNtxj-n5nYQ for <idr@ietfa.amsl.com>; Fri, 21 Oct 2011 15:23:54 -0700 (PDT)
Received: from mail37.opentransfer.com (mail37.opentransfer.com []) by ietfa.amsl.com (Postfix) with SMTP id BD91A21F8880 for <idr@ietf.org>; Fri, 21 Oct 2011 15:23:53 -0700 (PDT)
Received: (qmail 536 invoked by uid 399); 21 Oct 2011 22:23:52 -0000
Received: from unknown (HELO ? ( by mail37.opentransfer.com with SMTP; 21 Oct 2011 22:23:52 -0000
Message-ID: <4EA1F0FB.3090100@raszuk.net>
Date: Sat, 22 Oct 2011 00:23:55 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "idr@ietf.org List" <idr@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Idr] draft-uttaro-idr-bgp-persistence-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
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: Fri, 21 Oct 2011 22:23:54 -0000


I have read the draft and have one question and one observation.


What is the point of defining DO_NOT_PERSIST community ? In other words 
why not having PERSIST community set would not mean the same as having 
path marked with DO_NOT_PERSIST.


I found the below statement in section 4.2:

    o  Forwarding must ensure that the Next Hop to a "stale" route is

Of course I agree. But since we stating obvious in the forwarding 
section I think it would be good to explicitly also state this in the 
best path selection that next hop to STALE best path must be valid.

However sessions especially those between loopbacks do not go down for 
no reason. Most likely there is network problem which may have caused 
those sessions to go down. It is therefor likely that LDP session went 
also down between any of the LSRs in the data path and that in spite of 
having the paths in BGP and next hops in IGP the LSP required for both 
quoted L2/L3VPN applications is broken. That may particularly happen 
when network chooses to use independent control mode for label allocation.

I would suggest to at least add the recommendation statement to the 
document that during best path selection especially for stale paths a 
validity of required forwarding paradigm to next hop of stale paths 
should be verified.

For example using techniques as described in: 

Best regards,