Re: [RTG-DIR] RtgDir review: draft-ietf-ospf-ospfv3-segment-routing-extensions-17.txt

Peter Psenak <> Wed, 14 November 2018 13:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75617130E4C; Wed, 14 Nov 2018 05:13:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 xcCOwOpF3vY0; Wed, 14 Nov 2018 05:13:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D8CB130DDF; Wed, 14 Nov 2018 05:13:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3856; q=dns/txt; s=iport; t=1542201221; x=1543410821; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=NPePeieDElFYhGbvIhzgleBxr7ieXX8kIgvFVQ/DNA8=; b=FHFwzkwU8x/l4qdcW7+lgifmAl0kWis260UozjLzEvk4Mfjz9UaB111H iZx/zPDYvtX2wtQ35E2JHDABAOWZGFLnSxEZ0T65dwzVUytMr0enYjzL5 1XmZK70yJraMH19RnRZ8Plwpw1ZYty3PkTMDXQHzNj5UXntRnZZRgd9pP g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAABWHuxb/xbLJq1iGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGCaU8hEicEg3SId40pmTANI4RJAoNpNwoNAQM?= =?us-ascii?q?BAQIBAQJtHAyFOgEBAQMBIw8BBUABEAsUBAICBRYLAgIJAwIBAgFFBgEMAQc?= =?us-ascii?q?BAYMegXkID6dpgSEOhUGEbIELixGBQD+BEYMSgxALAoRlglcClSOKOwmGd4o?= =?us-ascii?q?rGIFYTIQ5gnyEMYJrjSyKVYFbIoFVMxoIGxWDKAiCHheIXoU/PgMxjWYBAQ?=
X-IronPort-AV: E=Sophos;i="5.56,232,1539648000"; d="scan'208";a="8043383"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2018 13:13:38 +0000
Received: from [] ([]) by (8.15.2/8.15.2) with ESMTP id wAEDDbBi027290; Wed, 14 Nov 2018 13:13:38 GMT
Message-ID: <>
Date: Wed, 14 Nov 2018 14:13:37 +0100
From: Peter Psenak <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Tomonori Takeda <>,
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client:, []
Archived-At: <>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ospf-ospfv3-segment-routing-extensions-17.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Nov 2018 13:13:44 -0000

Hi Tomonori,

please see inline:

On 14/11/18 12:49 , Tomonori Takeda wrote:
> Hello,
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review, and
> sometimes on special request. The purpose of the review is to provide
> assistance to the Routing ADs. For more information about the Routing
> Directorate, please see ‚Äč
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF
> Last Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
>   Document: draft-ietf-ospf-ospfv3-segment-routing-extensions-17.txt
>   Reviewer: Tomonori Takeda
>   Review Date: Nov 14th, 2018
>   IETF LC End Date: Nov 16th, 2018
>   Intended Status: Proposed Standard
> o Summary:
> This document is basically ready for publication, but has nits that
> should be considered prior to publication.
> o Comments:
> This document defines OSPFv3 extensions for Segment Routing with MPLS
> data plane.
> This document is mostly ready, but further clarification would be good
> for better understanding of the protocol definitions (see below).
> This document is well aligned with a related document
> draft-ietf-ospf-segment-routing-extensions.
> o Major Issues:
> None
> o Minor Issues:
> 1) Flooding Scope of SR-Algorithm TLV
> In Section 4.1, it says:
>    "If the SR-Algorithm TLV appears in
>     multiple OSPFv3 Router Information Opaque LSAs that have different
>     flooding scopes, the SR-Algorithm TLV in the OSPFv3 Router
>     Information Opaque LSA with the area-scoped flooding scope MUST be
>     used."
> At the same time, it say:
>    "For the purpose of SR-Algorithm TLV advertisement, area-
>     scoped flooding is REQUIRED."
> So, does it mean a) a router MUST use area-scoped flooding for sending,
> and

no. It says that that for the purpose of the SR-Algorithm TLV area scope 
is required. That means it cannot be link-scope, but it can be 
autonomous-system scope, because that is also covering the area-scope.

b) a router MUST support different flooding scopes for receiving?

SR-Algorithm TLV is sub-TLV of  Router Information Opaque LSA, which can 
be flooded in various flooding scopes - link, area, autonomous system. 
The flooding scope is not specific to SR-Algorithm TLV, it is generic 
one applicable to Router Information Opaque LSA.

> 2) LSA Type for OSPFv3 Extended Prefix Range TLV
> In Section 5, it defines IA-Flag. It is not clear how this relates to
> LSA type. Do we simply ignore LSA type being used to carry OSPFv3
> Extended Prefix Range TLV?

I think we can remove this bit, given that we know the route type from 
the LSA type itself. This was taken from the OSPFv2, where the Extended 
Prefix LSA does not carry the type.

Will remove.

> 3) Meaning of SID/Index/Label in Prefix SID Sub-TLV
> In Section 6, it says:
>       "SID/Index/Label: According to the V and L flags, it contains
>        either:
>           A 32-bit index defining the offset in the SID/Label space
>           advertised by this router.
>           A 24-bit label where the 20 rightmost bits are used for
>           encoding the label value."
> I understand how V Flag relates to this selection, but it is not clear
> how L flag relates to this selection.

L flag is not relevant, I will remove the reference to it.

Please let me know if you are fine with my responses.


> o Nits
> None
> Thanks,
> Tomonori Takeda
> .