Early Review of draft-ietf-idr-bgp-ls-segment-routing-ext-06
review-ietf-idr-bgp-ls-segment-routing-ext-06-rtgdir-early-pritchard-2018-06-08-00

Request Review of draft-ietf-idr-bgp-ls-segment-routing-ext
Requested rev. no specific revision (document currently at 16)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2018-05-18
Requested 2018-05-04
Requested by Susan Hares
Authors Stefano Previdi, Ketan Talaulikar, Clarence Filsfils, Hannes Gredler, Mach Chen
Draft last updated 2018-06-08
Completed reviews Opsdir Early review of -06 by Joel Jaeggli (diff)
Rtgdir Early review of -06 by Victoria Pritchard (diff)
Genart Last Call review of -14 by Roni Even (diff)
Secdir Last Call review of -14 by Paul Wouters (diff)
Assignment Reviewer Victoria Pritchard
State Completed
Review review-ietf-idr-bgp-ls-segment-routing-ext-06-rtgdir-early-pritchard-2018-06-08
Reviewed rev. 06 (document currently at 16)
Review result Has Issues
Review completed: 2018-06-08

Review
review-ietf-idr-bgp-ls-segment-routing-ext-06-rtgdir-early-pritchard-2018-06-08

Hello

I have been selected to do a routing directorate “early” review of this
draft.
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-06

The routing directorate will, on request from the working group chair,
perform an “early” review of a draft before it is submitted for publication
to the IESG. The early review can be performed at any time during the
draft’s lifetime as a working group document. The purpose of the early
review depends on the stage that the document has reached.

For more information about the Routing Directorate, please see ​
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-idr-bgp-ls-segment-routing-ext-06.txt
Reviewer: Victoria Pritchard
Review Date: 17/05/2018
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be
considered, just a few things that weren't clear to me, but these may be
obvious to the intended audience.

Comments:

(1)
I found the document difficult to read with so many references to
definitions in other drafts. I noticed that the other drafts sometimes
duplicate text from each other, so wonder if that should be done here too
to aid readability, along with a comment that these parts have the same
definition in the IS-IS and OSPF extensions too. e.g. 2.2.1 but applies
throughout.

(2)
I found Table 5 6 and 7 really useful, since it became clear that the TLVs
defined here for BGP map to OSPF and IS-IS extensions. I'd like to see
these tables earlier in the draft.

(3)
Sections 2.1, 2.2, 2.3.1, 2.3.4 all mention "SR TLV" or "corresponding TLV"
but it wasn't clear what these were.

(4)
Section 2.1.1
If length is 3 and the rightmost 20 bits are a label, what are the other
bits for?

(5)
2.1.2. The capabilities TLV "advertise the node's SR capabilities and its
Segment Routing Global Base (SRGB) range(s)", but the format diagram only
contains Segment ID information. What are the capabilities? Or does the
presence of this TLV indicate the capability?

(6)
2.1.2, 2.1.4
The range size is followed by a single SID? Is this the same for the Range
TLV in 2.3.4?

(7)
2.1.5 The SRMS Preference TLV only contains the Preference value, so it was
unclear how this is linked to a mapping server? Is the mapping server some
other field in the message?

(8)
2.3.1
If the flags field is to be used according to the flags from the
corresponding source protocol, does the receiver know the source protocol
and therefore how to interpret this field? 2.3.2 says to look in NLRI for
Protocol-ID so may be worth stating the same here.

(9)
2.3.4.1 repeats that the flags of the "Range TLV" are set according to the
definition in the OSPF drafts. Is that the Range TLV defined here (in which
case this is already stated in 2.3.4), or the OSPF Extended Prefix Range
TLV (in which case, why would you need to clarify how those flags are used)?
Does this paragraph mean you copy the TLV used in OSPF and also add a
Prefix-SID? So for each mapping there are 2 TLVs? 2.3.4.2 is much clearer
in the way it presents this.
Again a note about Protocol-ID may help here since the sub-TLVs included
are different depending on the protocol.

(10)
Table 5,6,7. Is the fact the length is variable is interesting in this
table? I would like to see this table earlier in the draft to visualise the
OSPF and IS-IS information you are aiming to share using this BGP extension.