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

From: Santanu Kar <[email-masked]>
Date: Tue, 31 Mar 2015 18:50:45 +0530

RE: PHP route determination in
draft-ietf-ospf-segment-routing-extensions-03

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.

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.

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:[email-masked]
<[email-masked]>]
Sent: Friday, March 27, 2015 7:47 PM
To: [email-masked]'; [email-masked]'; [email-masked]'; '
[email-masked]'; [email-masked]'; [email-masked]'; '
[email-masked]'
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                            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

-- 
.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 31 Mar 2015 17:13:19 +0200

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.

>
> 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

> "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
>
> From: Santanu Kar [mailto:[email-masked]]
> To: [email-masked] <mailto:[email-masked]>'; [email-masked]
> <mailto:[email-masked]>'; [email-masked]
> <mailto:[email-masked]>'; [email-masked]
> <mailto:[email-masked]>'; [email-masked]
> <mailto:[email-masked]>'; [email-masked]
> <mailto:[email-masked]>'; [email-masked]
> <mailto:[email-masked]>'
> determination. Please consider the following scenario. SID refers to
> Prefix Segment Identifier.
>
>
> 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
> 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.
>
> determination prescribed in the document, "If the NP-Flag is not set
> then any upstream neighbor of the Prefix-
>
> 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.
>
> subnet 20.0.0.0/24 <http://20.0.0.0/24>.
>
>     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>
>
> 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)
>
> based on following the rules mentioned
> inhttps://tools.ietf.org/html/draft-ietf-ospf-prefix-link-attr-03#section-2.1
>
> Please point me out if in case I am misinterpreting the intent of any
> texts mentioned from the drafts.
>
> Regards
>
> Santanu
>
>
> .