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

Tomonori Takeda <takeda.tomonori@lab.ntt.co.jp> Wed, 14 November 2018 11:49 UTC

Return-Path: <takeda.tomonori@lab.ntt.co.jp>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 45293124408; Wed, 14 Nov 2018 03:49:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wkgTVfkCV6gG; Wed, 14 Nov 2018 03:49:50 -0800 (PST)
Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp []) by ietfa.amsl.com (Postfix) with ESMTP id 4793012958B; Wed, 14 Nov 2018 03:49:50 -0800 (PST)
Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp []) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id wAEBnhhN020185; Wed, 14 Nov 2018 20:49:43 +0900
Received: from vc2.ecl.ntt.co.jp (localhost []) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 90CD46391AB; Wed, 14 Nov 2018 20:49:43 +0900 (JST)
Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp []) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 82C3E639166; Wed, 14 Nov 2018 20:49:43 +0900 (JST)
Received: from [IPv6:::1] (unknown []) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id 7AC3940073C; Wed, 14 Nov 2018 20:49:43 +0900 (JST)
From: Tomonori Takeda <takeda.tomonori@lab.ntt.co.jp>
Message-ID: <42c3e097-9789-49d4-cf15-c3713f4a1c0b@lab.ntt.co.jp>
Date: Wed, 14 Nov 2018 20:49:19 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CC-Mail-RelayStamp: 1
To: rtg-ads@ietf.org
Cc: rtg-dir@ietf.org, draft-ietf-ospf-ospfv3-segment-routing-extensions.all@ietf.org, lsr@ietf.org, Tomonori Takeda <takeda.tomonori@lab.ntt.co.jp>
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/aV2b3Qw24vHHhEZAPE1JTa6l8FU>
Subject: [RTG-DIR] RtgDir review: draft-ietf-ospf-ospfv3-segment-routing-extensions-17.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Nov 2018 11:49:53 -0000


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 

o Major Issues:

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

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 b) a router MUST support different flooding scopes for receiving?

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?

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

          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.

o Nits

Tomonori Takeda