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

[Peter Psenak <[e-mail]>]

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

>
> 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:[e-mail]]
> Sent: Friday, March 27, 2015 7:47 PM
> To: '[e-mail] <mailto:[e-mail]>'; '[e-mail]
> <mailto:[e-mail]>'; '[e-mail]
> <mailto:[e-mail]>'; '[e-mail]
> <mailto:[e-mail]>'; '[e-mail]
> <mailto:[e-mail]>'; '[e-mail]
> <mailto:[e-mail]>'; '[e-mail]
> <mailto:[e-mail]>'
> 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
>
>
> .