Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt

Hi Shraddha

please see inline:

On 11/05/17 08:49 , Shraddha Hegde wrote:
> Peter,
>
> It is clearly specified that ABR originating prefixes from other areas should have NP
> Bit set.
>
> "The NP-Flag (No-PHP) MUST be set for Prefix-SIDs allocated to inter-
>     area prefixes that are originated by the ABR based on intra-area or
>     inter-area reachability between areas.  When the inter-area prefix is
>     generated based on a prefix which is directly attached to the ABR,
>     the NP-Flag SHOULD NOT be set."
>
>
> The same behavior should apply to mapping server advertised advertisements as well.

when SRMS advertises the SID, it can not set the NP-Flag, so we can not 
apply the exact same behavior there.

>
> " As the Mapping Server does not specify the originator of a prefix
>>      advertisement, it is not possible to determine PHP behavior solely
>>      based on the Mapping Server advertisement.  However, PHP behavior
>>      SHOULD be done in following cases:
>>
>>         The Prefix is intra-area type and the downstream neighbor is the
>>         originator of the prefix.
>>
>>         The Prefix is inter-area type and downstream neighbor is an ABR,
>>         which is advertising prefix reachability and is also generating
>>         the Extended Prefix TLV with the A-flag set for this prefix as
>>         described in section 2.1 of [RFC7684]."
>
>
> While the text above captures the case of directly attached prefixes it does not cover the
> Case of re-distributed prefixes for mapping server advertisements.

there is a text in the draft right after the above mention text that 
talks about the redistribution case:

       "The Prefix is external type and downstream neighbor is an ASBR,
       which is advertising prefix reachability and is also generating
       the Extended Prefix TLV with the A-flag set for this prefix as
       described in section 2.1 of [RFC7684]."

>
> Suggest to add below text.
>
>          "The Prefix is inter-area type and downstream neighbor is an ABR,
>          which is advertising prefix reachability and is also generating
>          the Extended Prefix TLV with the A-flag re-set for this prefix as
>          described in section 2.1 of [RFC7684] then PHP MUST not be done"

the draft says when PHP should be done when the SID is coming from the 
SRMS. It assumes that in all other cases PHP is not done.

If we are going to say when the PHP must not be done for SID coming from 
SRMS, we need to list all cases, not only one of them.

So I would say we either not say anything, or we say:

"For all other cases, when SID is coming from SRMS, PHM MUST not be done"

thanks,
Peter

> Rgds
> Shraddha
>
> -----Original Message-----
> From: Peter Psenak [mailto:ppsenak@cisco.com]
> Sent: Wednesday, May 10, 2017 12:33 PM
> To: Shraddha Hegde <shraddha@juniper.net>; internet-drafts@ietf.org; i-d-announce@ietf.org
> Cc: ospf@ietf.org
> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt
>
> Hi Shraddha,
>
> please see inline:
>
> On 10/05/17 07:34 , Shraddha Hegde wrote:
>> Authors,
>>
>> Apologies for being late with this comment in the process of standardization.
>>
>> The below section 5 describes the PHP for mapping server
>>
>>
>> " As the Mapping Server does not specify the originator of a prefix
>>      advertisement, it is not possible to determine PHP behavior solely
>>      based on the Mapping Server advertisement.  However, PHP behavior
>>      SHOULD be done in following cases:
>>
>>         The Prefix is intra-area type and the downstream neighbor is the
>>         originator of the prefix.
>>
>>         The Prefix is inter-area type and downstream neighbor is an ABR,
>>         which is advertising prefix reachability and is also generating
>>         the Extended Prefix TLV with the A-flag set for this prefix as
>>         described in section 2.1 of [RFC7684]."
>>
>>
>> The text says "PHP behavior" should be done in following cases.
>> In the second case here it's an ABR re-advertising a prefix and SID
>> being advertised for this Prefix from a mapping server. If we interpret "PHP behavior should be done"
>> As the penultimate router removing the label and forwarding the packet
>> to ABR, It does not work since the inner labels gets exposed at the ABR.
>
> above texts clearly specifies that PHP is done only for case where ABR is originating a prefix, not propagating it from other area. You can distinguish between the two based on the A-flag in the Extended Prefix TLV as specified in RFC7684, which the above text mentions.
>
> thanks,
> Peter
>>
>> Request authors to add clarification text around "PHP behavior".
>>
>> Rgds
>> Shraddha
>>
>> -----Original Message-----
>> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of
>> internet-drafts@ietf.org
>> Sent: Thursday, May 4, 2017 3:28 PM
>> To: i-d-announce@ietf.org
>> Cc: ospf@ietf.org
>> Subject: [OSPF] I-D Action:
>> draft-ietf-ospf-segment-routing-extensions-13.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Open Shortest Path First IGP of the IETF.
>>
>>           Title           : OSPF Extensions for Segment Routing
>>           Authors         : Peter Psenak
>>                             Stefano Previdi
>>                             Clarence Filsfils
>>                             Hannes Gredler
>>                             Rob Shakir
>>                             Wim Henderickx
>>                             Jeff Tantsura
>> 	Filename        : draft-ietf-ospf-segment-routing-extensions-13.txt
>> 	Pages           : 35
>> 	Date            : 2017-05-04
>>
>> Abstract:
>>      Segment Routing (SR) allows a flexible definition of end-to-end paths
>>      within IGP topologies by encoding paths as sequences of topological
>>      sub-paths, called "segments".  These segments are advertised by the
>>      link-state routing protocols (IS-IS and OSPF).
>>
>>      This draft describes the OSPF extensions required for Segment
>>      Routing.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-exten
>> sions/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions
>> -13
>> https://datatracker.ietf.org/doc/html/draft-ietf-ospf-segment-routing-
>> extensions-13
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-segment-routing-exte
>> nsions-13
>>
>>
>> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>>
>> _______________________________________________
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>> .
>>
>
> .
>