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

"Ketan Talaulikar Talaulikar (ketant)" <> Wed, 10 May 2017 06:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0909D129AD1; Tue, 9 May 2017 23:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fPG2rhn7CeUq; Tue, 9 May 2017 23:40:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C192129AC1; Tue, 9 May 2017 23:40:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4184; q=dns/txt; s=iport; t=1494398400; x=1495608000; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ElX63y1VhEoR/rss/PVzF3fAnWL0aS4smbmT/V1vhZU=; b=VZC0Uw0DzuKgx2VB2rcydnfs1+Hp2sz5dtBzXIpVOtGy0gDoxieThLOg /peQHWrojhqY9asluNZFif6rESTFsJr+TyZ6FQMftsG+DU/aQXX9mz6Af AfoJ7BKW3jqnIAcdq5gLxd3krVWCijwPE+go+Mej55Rlf+WlL4TKiS6Ca M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.38,318,1491264000"; d="scan'208";a="247033513"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2017 06:39:55 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v4A6dtJb001441 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 May 2017 06:39:55 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 10 May 2017 01:39:54 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Wed, 10 May 2017 01:39:54 -0500
From: "Ketan Talaulikar Talaulikar (ketant)" <>
To: Shraddha Hegde <>, "" <>, "" <>
CC: "" <>
Thread-Topic: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt
Thread-Index: AQHSxL0JNj0xRNC6UEmervDAmE2X4KHtaKGA//+08sA=
Date: Wed, 10 May 2017 06:39:54 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 May 2017 06:40:05 -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?


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


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


-----Original Message-----
From: OSPF [] On Behalf Of
Sent: Thursday, May 4, 2017 3:28 PM
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

   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

The IETF datatracker status page for this draft is:

There are also htmlized versions available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:

OSPF mailing list

OSPF mailing list