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

From: Santanu Kar <[email-masked]>
Date: Thu, 2 Apr 2015 12:09:49 +0530

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:[email-masked] <[email-masked]>]
Sent: Tuesday, March 31, 2015 8:43 PM
To: Santanu Kar; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
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:[email-masked]
<[email-masked]>]

> Sent: Friday, March 27, 2015 7:47 PM

> To: [email-masked] <mailto:[email-masked] <[email-masked]>>'; '
[email-masked]

> <mailto:[email-masked] <[email-masked]>>'; [email-masked]

> <mailto:[email-masked] <[email-masked]>>'; [email-masked]

> <mailto:[email-masked] <[email-masked]>>'; [email-masked]

> <mailto:[email-masked] <[email-masked]>>'; [email-masked]

> <mailto:[email-masked] <[email-masked]>>'; '
[email-masked]

> <mailto:[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 <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

> .

-- 
.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 02 Apr 2015 09:38:19 +0200

Santanu,

If B is not advertising a SID for 20.1.1.0/24, then A will not do PHP.

regards,
Peter

On 4/2/15 08:39 , Santanu Kar wrote:
> SANTANU> Iactually wanted to highlight the non-ABR cases here. Consider
> the3routers below,in same area.
>
> In thecontext of A, the route of 20.1.1.0/24 <http://20.1.1.0/24> is a
> PHP route. Now the Prefix Segment for prefix 20.1.1.0/24
> <http://20.1.1.0/24> can be advertised by bothB, 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 <http://20.1.1.0/24> to Afirst.Stillwhen A is
> calculating label for20.1.1.0/24 <http://20.1.1.0/24>,it should take it
> as PHP. Howeverthe 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.
>

---

From: Santanu Kar <[email-masked]>
Date: Thu, 2 Apr 2015 15:04:28 +0530

Hi Peter

I think, considering we are using Ext Prefix LSA in 'Area-Flooding' scope, A
should do PHP for 20.1.1.0/24  if C has advertised it.
If  A doesn’t pop for 20.1.1.0/24, and give the packet to B, it will drop
it, since PHP is enabled by default for all nodes.

Regards
Santanu

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]]
Sent: Thursday, April 02, 2015 1:08 PM
To: Santanu Kar; [email-masked]; [email-masked]; [email-masked];

Santanu,

regards,
Peter

On 4/2/15 08:39 , Santanu Kar wrote:
> SANTANU> Iactually wanted to highlight the non-ABR cases here.
> SANTANU> Consider
> <http://20.1.1.0/24> can be advertised by bothB, 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 <http://20.1.1.0/24> to Afirst.Stillwhen
> A is calculating label for20.1.1.0/24 <http://20.1.1.0/24>,it should
> take it as PHP. Howeverthe 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.
>

-- 
.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 02 Apr 2015 12:17:42 +0200

Santanu,

> should do PHP for 20.1.1.0/24  if C has advertised it.

I do not see why would you do PHP, if B is not advertising the SID.

> it, since PHP is enabled by default for all nodes.

why would it drop? B will get the packet with the label that corresponds 
to 20.1.1.0/24.

regards,
Peter

---

From: Santanu Kar <[email-masked]>
Date: Thu, 2 Apr 2015 17:02:36 +0530

Hi Peter

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]]
Sent: Thursday, April 02, 2015 3:48 PM
To: Santanu Kar; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: PHP route determination in
draft-ietf-ospf-segment-routing-extensions-03

Santanu,

On 4/2/15 11:34 , Santanu Kar wrote:
> Hi Peter
>
> I think, considering we are using Ext Prefix LSA in 'Area-Flooding'
> scope, A should do PHP for 20.1.1.0/24  if C has advertised it.

> If  A doesn’t pop for 20.1.1.0/24, and give the packet to B, it will
> drop it, since PHP is enabled by default for all nodes.

why would it drop? B will get the packet with the label that corresponds to
20.1.1.0/24.
[SANTANU] Since PHP is enabled globally, B may not expect a label packet for
20.1.1.0/24 as it expects it to be POPed in penultimate node. So B may
choose not to install any POP entry for 20.1.1.0/24. In that case packet
will be dropped.

regards,
Peter

> To: Santanu Kar; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
>> In thecontext of A, the route of 20.1.1.0/24 <http://20.1.1.0/24> is
>> a PHP route. Now the Prefix Segment for prefix 20.1.1.0/24
>> prefix segment of 20.1.1.0/24 <http://20.1.1.0/24> to
>> Afirst.Stillwhen A is calculating label for20.1.1.0/24
>> <http://20.1.1.0/24>,it should take it as PHP. Howeverthe 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.
>>
>

-- 
.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 02 Apr 2015 14:31:17 +0200

Santanu,

> why would it drop? B will get the packet with the label that corresponds to

then it's a problem of B.

Peter