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

[Peter Psenak <[e-mail]>]

Santanu,

On 4/2/15 13:32 , Santanu Kar wrote:
> Hi Peter
>
> -----Original Message-----
> From: Peter Psenak [mailto:[e-mail]]
> Sent: Thursday, April 02, 2015 3:48 PM
> To: Santanu Kar; [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]
> 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.
>
> I do not see why would you do PHP, if B is not advertising the SID.
>
>> 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.

then it's a problem of B.

Peter

>
> regards,
> Peter
>
>>
>> Regards
>> Santanu
>>
>> -----Original Message-----
>> From: Peter Psenak [mailto:[e-mail]]
>> Sent: Thursday, April 02, 2015 1:08 PM
>> To: Santanu Kar; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> Subject: Re: PHP route determination in
>> draft-ietf-ospf-segment-routing-extensions-03
>>
>> 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.
>>> SANTANU> Consider
>>> the3routers below,in same area.
>>>
>>>     A -----10.1.1.0/24----- B ------20.1.1.0/24 -----C
>>>
>>> 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.
>>>
>>
>