[OSPF] PHP route determination in draft-ietf-ospf-segment-routing-extensions-03

Santanu Kar <santanu.kar@ipinfusion.com> Fri, 27 March 2015 14:17 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 C22381ACE8D for <ospf@ietfa.amsl.com>; Fri, 27 Mar 2015 07:17:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 P-3NZceTpKEC for <ospf@ietfa.amsl.com>; Fri, 27 Mar 2015 07:17:15 -0700 (PDT)
Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (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 1A2631AC43C for <ospf@ietf.org>; Fri, 27 Mar 2015 07:17:09 -0700 (PDT)
Received: by wgra20 with SMTP id a20so100519793wgr.3 for <ospf@ietf.org>; Fri, 27 Mar 2015 07:17:07 -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:mime-version:thread-index:date:message-id :subject:to:content-type; bh=EOI8diWxoMmvY3QHYhiES8yJzF9NWpnc3e5kHgyrRq4=; b=XfFUTLV8pJvet9OL5tvWJxh+s10ybZ++AkyJA4teejarMBqz9o6jkuxpuosmbioI0t 1I4+EvbWYabLmLhbG66D6KM7A03M+k08IUti1RzR5WImtL1Vl/M0ShWwGOQqF81Ar7xV 5Mfn3iMj7kYDTffWCgNDnyLGcLwCa86z+GAVckVQ7Ke2aA0Qkyd3NW1Z1z5vLx2KQRwj 2T4XfLQelOoe8lZjM6qwVrAk1POKSG074NbYdfqUdOBuV5qKrtt578GHxDtHW6gZh+Uk 6OYph0PKJj5nSxxK1iZ0eOX5reH3MHINNDkB6kbYeFzLm/qcrzYUJ2ojUzfNUTyLjoif iNEA==
X-Gm-Message-State: ALoCoQl7cKh+KSAhWYbtGoJ5IcaOYF26Af1ZKT0W8DadcLguluSymjRd0zRTycQ/1Le3YG8iCMbBrGhAT4HO5SWHw/fxOhWZlj+tKZG7VALD+j8bXQa6vR/Pk1D5mNOe63VhHkmzVSW3qSie8armQ54FGBj3rLdxAH5ldVJ8tsc69gXbJfQceVTCO6ae9590aJpar7CVQ5QT
X-Received: by 10.180.74.135 with SMTP id t7mr57314559wiv.72.1427465827831; Fri, 27 Mar 2015 07:17:07 -0700 (PDT)
From: Santanu Kar <santanu.kar@ipinfusion.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdBol7CoMWZ69oY2QXWAefarTdFnhQ==
Date: Fri, 27 Mar 2015 19:47:02 +0530
Message-ID: <4fc9cc059b29bc852addd12c4dcb9399@mail.gmail.com>
To: ospf@ietf.org, ppsenak@cisco.com, sprevidi@cisco.com, cfilsfil@cisco.com, hannes@juniper.net, rob.shakir@bt.com, wim.henderickx@alcatel-lucent.com
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/_mLJm28iJf_74mE6SLpRh7uwsRA>
Subject: [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: Fri, 27 Mar 2015 14:24:12 -0000

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
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 prefix. In the context of Router-A,
the route 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. 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.

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
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 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 in
https://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

-- 
.