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

From: [email-masked]
Date: Thu, 04 May 2017 02:58:18 -0700

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

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

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 10 May 2017 05:34:51 +0000

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.

Request authors to add clarification text around "PHP behavior".

Rgds
Shraddha

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, May 4, 2017 3:28 PM
To: [email-masked]
Cc: [email-masked]
Subject: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt

Abstract:

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.

_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: "Ketan Talaulikar Talaulikar (ketant)" <[email-masked]>
Date: Wed, 10 May 2017 06:39:54 +0000

Hi Shraddha,

When the ABR originates the Extended Prefix TLV with A (attached) bit set, it indicates that the prefix belongs to it (i.e. connected in perhaps another area on the same node). So PHP must be done on previous router.

I don't see the issue or need for clarification here. Or am I not following your point well?

Thanks,
Ketan

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Shraddha Hegde
Sent: 10 May 2017 11:05
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt

Authors,

Rgds
Shraddha

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, May 4, 2017 3:28 PM
To: [email-masked]
Cc: [email-masked]
Subject: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt

Abstract:

---

From: Peter Psenak <[email-masked]>
Date: Wed, 10 May 2017 09:02:38 +0200

Hi Shraddha,

please see inline:

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

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 11 May 2017 06:49:57 +0000

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.

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

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"
Rgds 
Shraddha

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Wednesday, May 10, 2017 12:33 PM
To: Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
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:
> 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
> Subject: [OSPF] I-D Action: 
> draft-ietf-ospf-segment-routing-extensions-13.txt
>
>

---

From: Erik Auerswald <[email-masked]>
Date: Thu, 11 May 2017 08:59:42 +0200

Hi Shradda,

really small nit below:

On Thu, May 11, 2017 at 06:49:57AM +0000, Shraddha Hegde wrote:
> [...]
           ^^^
           If the

>         described in section 2.1 of [RFC7684] then PHP MUST not be done"

Thanks,
Erik
-- 
Dipl.-Inform. Erik Auerswald         http://www.fg-networking.de/
[email-masked] T:+49-631-4149988-0 M:+49-176-64228513

Gesellschaft für Fundamental Generic Networking mbH
Geschäftsführung: Volker Bauer, Jörg Mayer
Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630

---

From: Peter Psenak <[email-masked]>
Date: Thu, 11 May 2017 11:16:18 +0200

Hi Shraddha

please see inline:

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

> 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]."

>          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

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 11 May 2017 09:30:55 +0000

Peter,

Inter-area/external prefixes with A-flag re-set is the only scenario
I can think of where SRMS SIDs should not do PHP.
Is there any other case?

> "For all other cases, when SID is coming from SRMS, PHM MUST not be done"
I suggest the text to be more specific to the cases since we do 
not have many scenarios to list. 

Rgds
Shraddha
-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Thursday, May 11, 2017 2:46 PM
To: Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: 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.
>

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

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

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

thanks,
Peter

> Subject: Re: [OSPF] I-D Action: 
>> 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.
>
>> https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-exte
>> n
>> sions/
>>
>> https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extension
>> s
>> -13
>> https://datatracker.ietf.org/doc/html/draft-ietf-ospf-segment-routing
>> -
>> extensions-13
>>
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-segment-routing-ext
>> e
>> nsions-13
>>
>>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 11 May 2017 11:38:10 +0200

Hi Shraddha,

> I can think of where SRMS SIDs should not do PHP.

- Intra-area route, where the downstream neighbor is not the originator 
or the prefix

- Inter-area prefixes, for which the downstream neighbor is not the 
originator or the prefix

- External prefix for which the downstream neighbor is not the 
originator or the prefix

- Inter-area prefixes, where originator is not advertising Extended 
Prefix TLV

- External prefix , where originator is not advertising Extended Prefix TLV

thanks,
Peter