Re: [OSPF] PHP route determination in draft-ietf-ospf-segment-routing-extensions-03
Santanu Kar <santanu.kar@ipinfusion.com> Thu, 02 April 2015 06:40 UTC
Return-Path: <santanu.kar@ipinfusion.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1E41A88E3 for <ospf@ietfa.amsl.com>; Wed, 1 Apr 2015 23:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.177
X-Spam-Level:
X-Spam-Status: No, score=-0.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_82=0.6, J_CHICKENPOX_84=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
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 nO-7Bmm4jBsv for <ospf@ietfa.amsl.com>; Wed, 1 Apr 2015 23:40:08 -0700 (PDT)
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 330AA1B2B28 for <ospf@ietf.org>; Wed, 1 Apr 2015 23:40:07 -0700 (PDT)
Received: by wibgn9 with SMTP id gn9so93369274wib.1 for <ospf@ietf.org>; Wed, 01 Apr 2015 23:40:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=rqNvZ61dCe9l3yofTioEOG3nRhXN/mXUjeva3qY83xE=; b=H5PUvkws1WmMipnJBjhOwDIFNNHXeprOa7o7VXEv+HSIRkHyaYQr8d7tgzHeUYGW7t ArD7MsCuKmvb8TytraQ0Lxd9GCXlBrBFC4DO5dDpfSjmXPN0g4Fm3G3FXMwXQXZdTvXP PQsLY8bgkHgBNsTcXDceBWS3bymFzJ7NqLKOL2DDDL//L10kdTdo5cvU0hg9EdliJF8I A8FTaJktrp8oU057DI0S0vVHWbgAPHV2FEcDT3nGCEySXS8HMfnnvFAeC9QIR+tcXiW2 Xa1ZHmToI8sCDTmfW4/u/LVjOWkvudctwd6Y/JQ+/miRjdTMMGzFZI460hGKb8TxeCZC wYLw==
X-Gm-Message-State: ALoCoQk1TcDlamgdvDpn0Gf0RY98vylS6gfQzMHjRd0cvwQ12BxU2nsqQNv9iN00Yxq/QWMWkeDSd2/FN+2BneWQqSR0xoli5KuTLsT/1qdZlTEC/QkTzbpevCKUvG+3bYmlzWzHE9L4jndxBgBWdA9bV/fKAyCj1CYfY2RoCKzr4eLsouui2aX64tDamcBavmemi1J0I1K8
X-Received: by 10.180.214.99 with SMTP id nz3mr21914222wic.82.1427956805886; Wed, 01 Apr 2015 23:40:05 -0700 (PDT)
From: Santanu Kar <santanu.kar@ipinfusion.com>
References: 4fc9cc059b29bc852addd12c4dcb9399@mail.gmail.com <05e49b8dbcff3bd69762a410d9945189@mail.gmail.com> <551AB98F.9050008@cisco.com>
In-Reply-To: <551AB98F.9050008@cisco.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKOYGI60YUwd117EWSBze/2xwaHtAL312R0m6Wa7QA=
Date: Thu, 02 Apr 2015 12:09:49 +0530
Message-ID: <d84cbca4461d10193152644a17045651@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>, ospf@ietf.org, sprevidi@cisco.com, cfilsfil@cisco.com, hannes@juniper.net, rob.shakir@bt.com, wim.henderickx@alcatel-lucent.com
Content-Type: multipart/alternative; boundary="001a1135e9a82b7b880512b81aed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/I8Shpr0PVuwD1_jrV54PjjjawLg>
Subject: Re: [OSPF] PHP route determination in draft-ietf-ospf-segment-routing-extensions-03
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2015 06:40:11 -0000
RE: PHP route determination in draft-ietf-ospf-segment-routing-extensions-03 Hi Peter Please find my responses inline. Regards Santanu -----Original Message----- From: Peter Psenak [mailto:ppsenak@cisco.com <ppsenak@cisco.com>] Sent: Tuesday, March 31, 2015 8:43 PM To: Santanu Kar; ospf@ietf.org; sprevidi@cisco.com; cfilsfil@cisco.com; hannes@juniper.net; rob.shakir@bt.com; wim.henderickx@alcatel-lucent.com Subject: Re: PHP route determination in draft-ietf-ospf-segment-routing-extensions-03 Santanu, On 3/31/15 15:20 , Santanu Kar wrote: > Hi Authors > > I think last mail was a bit long to have probably missed the actual > point which I was trying to make.Stating it concisely again. > > The PHP Prefix Segment can be advertised by the neighbor as well as by > routers downstream of the neighbor which are connected to it. correct, typical case is an area boundary, where ABR propagates the prefix SID between areas. SANTANU> I actually wanted to highlight the non-ABR cases here. Consider the 3 routers below, in same area. A -----10.1.1.0/24----- B ------20.1.1.0/24 -----C In the context of A, the route of 20.1.1.0/24 is a PHP route. Now the Prefix Segment for prefix 20.1.1.0/24 can be advertised by both B, as well as by C towards A. The case I am considering here is, C has advertised the prefix segment of 20.1.1.0/24 to A first. Still when A is calculating label for 20.1.1.0/24, it should take it as PHP. However the text in draft states " upstream neighbor of the Prefix-SID originator MUST pop the Prefix-SID". Here A is not the upstream neighbor of C. > > So to determine a PHP Prefix Segment, should the recipient router > only check for PHP when its advertised from its neighbor(with NP flag > unset), or even when its from other routers downstream of the neighbor. draft says two things: 1. If the NP-Flag is not set then any upstream neighbor of the Prefix- SID originator MUST pop the Prefix-SID. 2. When calculating the outgoing label for the prefix, the router MUST take into account E and P flags advertised by the next-hop router, if next-hop router advertised the SID for the prefix. This MUST be done regardless of whether the next-hop router contributes to the best path to the prefix. 'E and P flags' should be 'E and NP flags' in the above paragraph, will fix that in the next re-spin. In summary, you should only follow what NP-bit is telling you, if the neighbor advertised the SID. regards, Peter > > The reason for this doubt is this statement in the text > > "If the NP-Flag is not set then any*upstream neighbor*of the Prefix-SID > originator MUST pop the Prefix-SID. This is equivalent to > the penultimate hop popping mechanism used in the MPLS dataplane." > > Regards > > Santanu > > -----Original Message----- > From: Santanu Kar [mailto:santanu.kar@ipinfusion.com <santanu.kar@ipinfusion.com>] > Sent: Friday, March 27, 2015 7:47 PM > To: 'ospf@ietf.org <mailto:ospf@ietf.org <ospf@ietf.org>>'; ' ppsenak@cisco.com > <mailto:ppsenak@cisco.com <ppsenak@cisco.com>>'; 'sprevidi@cisco.com > <mailto:sprevidi@cisco.com <sprevidi@cisco.com>>'; 'cfilsfil@cisco.com > <mailto:cfilsfil@cisco.com <cfilsfil@cisco.com>>'; 'hannes@juniper.net > <mailto:hannes@juniper.net <hannes@juniper.net>>'; 'rob.shakir@bt.com > <mailto:rob.shakir@bt.com <rob.shakir@bt.com>>'; ' wim.henderickx@alcatel-lucent.com > <mailto:wim.henderickx@alcatel-lucent.com <wim.henderickx@alcatel-lucent.com>>' > Subject: PHP route determination in > draft-ietf-ospf-segment-routing-extensions-03 > > Hi > > Seeking some more clarification in the draft regarding PHP route > determination. Please consider the following scenario. SID refers to > Prefix Segment Identifier. > > > Router-A: --------------------- :Router-B: ---------------------( > SID-210) :Router-C > > 10.0.0.0/24 <http://10.0.0.0/24> 20.0.0.0/24 <http://20.0.0.0/24> > > Lets consider the above topology of 3 routers. Router-C has > configured Prefix SID 210 for prefix 20.0.0.0/24 <http://20.0.0.0/24> > prefix. In the context of Router-A, the route 20.0.0.0/24 > <http://20.0.0.0/24> is a PHP route, as it belongs to its neighbor > Router-B. Router-B is not configured. > > When Ext Prefix LSA with SID 210 originated by Router-C reaches Router-A > , it finds that it's not from its neighbor Router-B and hence it will > end up installing a non-PHP label say 210, instead of doing penultimate > hop pop for the route 20.0.0.0/24 <http://20.0.0.0/24>. But this won't > be correct. > > Am interpreting this because as per the following rules for PHP > determination prescribed in the document, "If the NP-Flag is not set > then any upstream neighbor of the Prefix- > > SID originator MUST pop the Prefix-SID. This is equivalent to the > > penultimate hop popping mechanism used in the MPLS dataplane." > > Since this is an intra-area case, NP is not set. However since Router-A > is not upstream neighbor of Router-C it will not apply PHP for this > route, even though its actually a PHP route. Few questions in this > > 1) Should we just rely on checking that its upstream neighbor and NP > flag and then apply PHP, or Router-A should do a special search its Link > State database to find whether the route actually belongs to its > neighbor, in this case Router-B. > > 2) Is the above a valid scenario or the administrator is mandated to > configure SID values (which are all same) on all routers connected to > subnet 20.0.0.0/24 <http://20.0.0.0/24>. > > 3) If we mandate (2) we will have the below scenario > > Router-A --------------------- :Router-B : > SID-210--------------------- SID-210:Router-C > > 10.0.0.0/24 <http://10.0.0.0/24> 20.0.0.0/24 <http://20.0.0.0/24> > > In this case, even if we configure SID in Router-C earlier, we will be > needed to configure the same in Router-B also. So Router-A will select > the Ext Prefix LSA coming from Router-B , as its the best path for route > 20.0.0.0/24 <http://20.0.0.0/24> than Router-C. So even though we have > non-PHP label installed first, it will be replaced with PHP label as > soon ROuter-B is also configured for same prefix. So we may not choose > to do special search in link state database to find PHP route as > mentioned in (1) > > The selection of SID, when both Router-B and Router-C is configured is > based on following the rules mentioned > inhttps:// tools.ietf.org/html/draft-ietf-ospf-prefix-link-attr-03#section-2.1 > > "If this TLV is advertised multiple times for the same prefix in > > different OSPFv2 Extended Prefix Opaque LSAs originated by the > > different OSPF routers, the application using the information is > > required to determine which OSPFv2 Extended Prefix Opaque LSA is > > used. For example, the application could prefer the LSA providing > > the best path to the prefix." > > So should we follow (2) and (3) for considering PHP, or (1). If we don't > follow any, we will end up having non-PHP label even for routes that are > PHP. > > Please point me out if in case I am misinterpreting the intent of any > texts mentioned from the drafts. > > Regards > > Santanu > > > . -- .
- [OSPF] PHP route determination in draft-ietf-ospf… Santanu Kar
- Re: [OSPF] PHP route determination in draft-ietf-… Santanu Kar
- Re: [OSPF] PHP route determination in draft-ietf-… Peter Psenak
- Re: [OSPF] PHP route determination in draft-ietf-… Santanu Kar
- Re: [OSPF] PHP route determination in draft-ietf-… Peter Psenak
- Re: [OSPF] PHP route determination in draft-ietf-… Santanu Kar
- Re: [OSPF] PHP route determination in draft-ietf-… Peter Psenak
- Re: [OSPF] PHP route determination in draft-ietf-… Santanu Kar
- Re: [OSPF] PHP route determination in draft-ietf-… Peter Psenak