[Idr] AD Review of draft-ietf-idr-bgp-ls-segment-routing-ext-11

[Alvaro Retana <[e-mail]>]

Dear authors:

I just finished my review of this document -- please see inline
comments/questions.

In general, I think that there is more work needed in at least two fronts:

(1) Consistency in the specification of the new TLVs.  Most of the
descriptions point at other documents, but they don't do so in a consistent
manner: some at the start of the section, others when pointing at the
values, etc.  Please be consistent!  Given that §2.4/2.5 already have a
summary, I personally find the information in the individual sections
redundant.  Instead of a statement at the start of a section, I prefer you
to be specific about the values -- see §2.1.2 for an example.

Please note that most of my comments related to the specification of the
TLVs apply to multiple sections, not just the one where I made them.  I
pointed this out in most cases, but may have missed some.


(2) Error Handling.  As has been discussed on the list (for example in [1],
[2] and [3]), rfc7752 could use enhancements as it relates to considering
error handling with applications such as SR, and in general.  Those issues
don't need to be fixed in this document, but I would like to see in this
document some text about the potential effect: maybe in terms of the effect
than an error might have from an operations or management point of view...
See my comments below for specifics.  Again, not looking for this document
to "fix" BGP-LS, but to consider the effect on the expected function a
controller might have, as described in the Introduction.

[1] https://mailarchive.ietf.org/arch/msg/idr/Tm0vlu-ECSnIAyO1byj68AJm2XU
[2] https://mailarchive.ietf.org/arch/msg/idr/0qsjuVaEhroKInHZMohP6HnsWd8
[3] https://mailarchive.ietf.org/arch/msg/idr/-CZGAiC8D3KogLnUs6ClW_KlU24


Thanks!

Alvaro.


[Line numbers come from idnits.]

...
27 Requirements Language

29   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
30   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
31   document are to be interpreted as described in RFC 2119 [RFC2119].

[major] Please use the rfc8174 template.


...
99 1.  Introduction
...
110   Two types of IGP segments are defined, Prefix segments and Adjacency
111   segments.  Prefix segments, by default, represent an ECMP-aware
112   shortest-path to a prefix, as per the state of the IGP topology.
113   Adjacency segments represent a hop over a specific adjacency between
114   two nodes in the IGP.  A prefix segment is typically a multi-hop path
115   while an adjacency segment, in most of the cases, is a one-hop path.
116   [RFC8402].

[nit] rfc8402 defines more than 2 IGP segments.

[nit] s/one-hop path. [RFC8402]./one-hop path [RFC8402].

118   When Segment Routing is enabled in a IGP domain, segments are
119   advertised in the form of Segment Identifiers (SIDs).  The IGP link-
120   state routing protocols have been extended to advertise SIDs and
121   other SR-related information.  IGP extensions are described in: IS-IS
122   [I-D.ietf-isis-segment-routing-extensions], OSPFv2
123   [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3
124   [I-D.ietf-ospf-ospfv3-segment-routing-extensions].  Using these
125   extensions, Segment Routing can be enabled within an IGP domain.

[nit] s/a IGP domain/an IGP domain

127                           +------------+
128                           |  Consumer  |
129                           +------------+
130                                 ^
131                                 |
132                                 v
133                       +-------------------+
134                       |    BGP Speaker    |         +-----------+
135                       | (Route-Reflector) |         | Consumer  |
136                       +-------------------+         +-----------+
137                             ^   ^   ^                       ^
138                             |   |   |                       |
139             +---------------+   |   +-------------------+   |
140             |                   |                       |   |
141             v                   v                       v   v
142       +-----------+       +-----------+             +-----------+
143       |    BGP    |       |    BGP    |             |    BGP    |
144       |  Speaker  |       |  Speaker  |    . . .    |  Speaker  |
145       +-----------+       +-----------+             +-----------+
146             ^                   ^                         ^
147             |                   |                         |
148            IGP                 IGP                       IGP

150                   Figure 1: Link State info collection

[nit] Maybe move this Figure so it is closer to where it is referenced.

...
159   In order to address the need for applications that require
160   topological visibility across IGP areas, or even across Autonomous
161   Systems (AS), the BGP-LS address-family/sub-address-family have been
162   defined to allow BGP to carry Link-State information.  The BGP
163   Network Layer Reachability Information (NLRI) encoding format for
164   BGP-LS and a new BGP Path Attribute called the BGP-LS attribute are
165   defined in [RFC7752].  The identifying key of each Link-State object,
166   namely a node, link, or prefix, is encoded in the NLRI and the
167   properties of the object are encoded in the BGP-LS attribute.
168   Figure 1 describes a typical deployment scenario.  In each IGP area,
169   one or more nodes are configured with BGP-LS.  These BGP speakers
170   form an IBGP mesh by connecting to one or more route-reflectors.
171   This way, all BGP speakers (specifically the route-reflectors) obtain
172   Link-State information from all IGP areas (and from other ASes from
173   EBGP peers).  An external component connects to the route-reflector
174   to obtain this information (perhaps moderated by a policy regarding
175   what information is or isn't advertised to the external component).

[minor] The way that the propagation of information can be controlled by
policy is important.  Please make sure that the text is clear in the fact
that the discussion above is referencing rfc7752 (and that the reference to
it is not just about the encodings).

177   This document describes extensions to BGP-LS to advertise the SR
178   information.  An external component (e.g., a controller) then can
179   collect SR information from across an SR domain and construct the
180   end-to-end path (with its associated SIDs) that need to be applied to
181   an incoming packet to achieve the desired end-to-end forwarding.
182   Here the SR domain is defined as a single administrative domain that
183   may be comprised of a single AS or multiple ASes under consolidated
184   global SID administration.

[nit] s/under consolidated/under a consolidated

[major] Please don't redefine "SR domain".  The definition above is not the
same as what rfc8402 says (in §2).  Easy fix: simply put a reference to
rfc8402 next to the first mention of "SR domain", and delete that last
sentence.

186 2.  BGP-LS Extensions for Segment Routing

188   This document defines SR extensions to BGP-LS and specifies the TLVs
189   and sub-TLVs for advertising SR information within the BGP-LS
190   Attribute.  Section 2.4 and Section 2.5 illustrates the equivalent
191   TLVs and sub-TLVs in IS-IS, OSPFv2 and OSPFv3 protocols.

[nit] "illustrates" sounds like giving examples of equivalent TLVs.  But I
think that the tables don't show examples, they show/point to the
corresponding TLVs.  Perhaps use a different word...


...
200   Some of the TLVs defined in this document contain fields (e.g. flags)
201   whose semantics need to be interpreted accordingly to the respective
202   underlying IS-IS, OSPFv2 or OSPFv3 protocol.  The receiver of the
203   BGP-LS update for any of the NLRIs MUST check the Protocol-ID of the
204   NLRI and refer to the underlying protocol specification in order to
205   parse such fields.  The individual field descriptions in the sub-
206   sections below point to the relevant underlying protocol
207   specifications for such fields.

[major] "The receiver of the BGP-LS update for any of the NLRIs MUST check
the Protocol-ID of the NLRI and refer to the underlying protocol
specification in order to parse such fields."  This text is a general
statement ("for any of the NLRIs") that seems to want to Update rfc7752,
where Protocol-ID is defined...but I don't think that is the intent,
right?  Note that rfc7752 doesn't explicitly mandate that the
"receiver...refer to the underlying protocol specification" -- it just
implies it when talking about the Opaque TLVs.

IOW, this seems like a significant change as related to other BGP-LS specs.

Note also that §5 (Manageability Considerations) has the following text,
which I think is in contradiction of the one above:

...
                       ...                The semantic or content
   checking for the TLVs specified in this document and their
   association with the BGP-LS NLRI types or their BGP-LS Attribute is
   left to the consumer of the BGP-LS information (e.g. an application
   or a controller) and not the BGP protocol.

   ...               The handling of semantic or content errors by the
   consumer would be dictated by the nature of its application usage and
   hence is beyond the scope of this document.

209 2.1.  Node Attributes TLVs

211   The following Node Attribute TLVs are defined:

213              +-----------------+----------+---------------+
214              | Description     | Length   |       Section |
215              +-----------------+----------+---------------+
216              | SID/Label       | variable | Section 2.1.1 |
217              | SR Capabilities | variable | Section 2.1.2 |
218              | SR Algorithm    | variable | Section 2.1.3 |
219              | SR Local Block  | variable | Section 2.1.4 |
220              | SRMS Preference | variable | Section 2.1.5 |
221              +-----------------+----------+---------------+

223                       Table 1: Node Attribute TLVs

[minor] It would be nice if the table also contained the TLV Type.  This
comment applies to other similar tables.

[minor] §2.1.2/2.1.3 use a "-" in the name of the TLV.  Please be
consistent as both versions are used throughout the document.

[nit] Yes, the length is variable, but in some cases the possible values
are known.  For example, the length of the SID/Label sub-TLV can only be 3
or 4.  Consider indicating that.  OTOH, I don't see why indicating the
Length is significant at this point -- IOW, I would even suggest removing
that column.

225   These TLVs can ONLY be added to the BGP-LS Attribute associated with
226   the Node NLRI that originates the corresponding underlying IGP TLV/
227   sub-TLV described below.

[minor] "the Node NLRI that originates the corresponding underlying IGP..."
 The Node NLRI doesn't originate anything...it describes the IGP node that
originates something...  Please be specific.

[major] The text above sounds as if you want to mandate something...
Writing "ONLY" in caps doesn't have a Normative effect.  Should there be a
"MUST" somewhere?  Or perhaps soften a little: s/can ONLY/should only

The next question is: what if they are added somewhere else?  There doesn't
seem to be a way for the receiver to know if the TLVs are associated with
the correct Node NLRI...  I'm guessing that all the receiver can do is
assume that the TLV is referring to the right node...

>From the text, I'm assuming that the use is intended to be limited to the
Node NLRI.  Unfortunately, rfc7752 doesn't specify actions to be taken if
that is not the case.

This comment applies to other places where the "ONLY be added" phrase
exists.


229 2.1.1.  SID/Label Sub-TLV

231   The SID/Label TLV is used as sub-TLV by the SR-Capabilities
232   (Section 2.1.2) and SRLB (Section 2.1.4) TLVs and has the following
233   format:

[nit] s/used as sub-TLV/used as a sub-TLV

[minor] This is the first time that SRLB is used in this document, please
use the extended version here:  s/SRLB/SR Local Block (SRLB)

...
245      Type: TBD, see Section 4.

[minor] The code points have already been assigned (early allocation).
Please change "TBD" for the actual values.

247      Length: Variable, 3 or 4.

[nit] The Length is really not variable...it's 3 or 4.

...
254      The receiving router MUST ignore the SID/Label sub-TLV if the
255      length is other then 3 or 4.

[major] If the sub-TLV is ignored, the information in the SR-Capabilities
or SR Local Block TLVs will be incomplete (at best).  What is the potential
impact of that?  Is the received information still useful?  Should other
actions be taken?

257 2.1.2.  SR-Capabilities TLV

259   The SR-Capabilities TLV is used in order to advertise the node's SR
260   Capabilities including its Segment Routing Global Base (SRGB)
261   range(s).  In the case of IS-IS, the capabilities also include the
262   IPv4 and IPv6 support for SR-MPLS forwarding plane.  This information
263   is derived from the protocol specific advertisements.

[nit] s/support for SR-MPLS forwarding plane/support for the SR-MPLS
forwarding plane

265   o  IS-IS, as defined by the SR-Capabilities sub-TLV in
266      [I-D.ietf-isis-segment-routing-extensions].

268   o  OSPFv2/OSPFv3, as defined by the SID/Label Range TLV in
269      [I-D.ietf-ospf-segment-routing-extensions] and
270      [I-D.ietf-ospf-ospfv3-segment-routing-extensions].

[minor] The text above, pointing at the individual IGP specs is present in
many of the descriptions for the TLVs, but not all.  Sections 2.4/2.5 have
tables that also point at the equivalent TLVs.  I'm looking for
consistency: either indicate in each section where the information is
derived from, or not.  Given that §2.4/2.5 already have a summary, I
personally find the information (like the one above) in the individual
sections redundant.  Instead of the statement above, I prefer you to be
specific about the values described below -- for example, when describing
the Range Size field below, you could say something like this:

OLD>
   Range Size: 3 octet value indicating the number of labels in
   the range.

NEW>
   Range Size: 3 octet value indicating the number of labels in
   the range.  The value and characteristics of this field are derived from
the Range field in the SR-Capabilities sub-TLV in
[I-D.ietf-isis-segment-routing-extensions], or from the Range Size field in
the SID/Label Range TLV in [I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions].

Note that doing it this way saves you the need to define the
characteristics of each field (because even if the values are derived, the
TLVs here are new).

This comment obviously applies to all similar instances in the document.

272   The SR Capabilities TLV has following format:

[nit] s/has following format/has the following format


...
290      Length: Variable.

[major] Yes, it's variable, but it has to be at least 12.  What should a
router do if the length is < 12?  After that, there are only specific valid
lengths: 12, 13, 19, 21, etc.  What if the length is not one of those
values?

I couldn't find guidance in rfc7752.  The closest statement is from §6.2.2
(Fault Management), where one of the "checks for determining if a message
is malformed...Does any fixed-length TLV correspond to the TLV Length field
in this document?"  This TLV is not fixed-length, but the possibilities are
finite.

Note that rfc7752 says that if the length is not the expected one, then the
whole BGP-LS attribute is discarded.  For this specific case, it means that
the controller wouldn't have complete knowledge of the network, even if the
information derived from the IGP is correct...

This comment applies to other similar instances.

292      Flags: 1 octet of flags as defined in
293      [I-D.ietf-isis-segment-routing-extensions].

[major] When the BGP-LS information comes from OSPF, how should the flags
be interpreted?  There is no indication in the corresponding OSPF drafts of
"IPv4 and IPv6 support for SR-MPLS" -- should the bits always be unset?


...
300         Range Size: 3 octet value indicating the number of labels in
301         the range.

[nit] s/labels/labels or SIDs

[major] What numbers are valid in the Range Size field?  Can it be 0?  Take
a look above at my comments about derived values.

303         SID/Label sub-TLV (as defined in Section 2.1.1) which encodes
304         the first label in the range.

[nit] s/first label/first label or SID


...
339 2.1.4.  SR Local Block TLV
...
380      Flags: 1 octet of flags.  None are defined at this stage.

[major] Only the corresponding ISIS sub-TLV has Flags defined -- and I
realize that the text above is the same as in
draft-ietf-isis-segment-routing-extensions.  I think you really don't want
this field to evolve independently.  IOW, please use a description like the
you used for the Flags in the SR-Capabilities TLV.


...
393 2.1.5.  SRMS Preference TLV
...
427   The use of the SRMS Preference TLV is defined in
428   [I-D.ietf-isis-segment-routing-extensions],
429   [I-D.ietf-ospf-segment-routing-extensions] and
430   [I-D.ietf-ospf-ospfv3-segment-routing-extensions].

[major] This document only defines how to carry information in BGP-LS, not
what to do with it.  IOW, I think that the last paragraph is not needed, it
is out of scope of this document...

432 2.2.  Link Attribute TLVs

434   The following Link Attribute TLVs are are defined:

436   +----------------------------------------+----------+---------------+
437   | Description                            |   Length |       Section |
438   +----------------------------------------+----------+---------------+
439   | Adjacency Segment Identifier (Adj-SID) | variable | Section 2.2.1 |
440   | TLV                                    |          |               |
441   | LAN Adjacency Segment Identifier (Adj- | variable | Section 2.2.2 |
442   | SID) TLV                               |          |               |
443   | L2 Bundle Member TLV                   | variable | Section 2.2.3 |
444   +----------------------------------------+----------+---------------+

446                       Table 2: Link Attribute TLVs

[minor] The names used above don't match the names used in the sections
below.

...
452   For a LAN, normally a node only announces its adjacency to the IS-IS
453   pseudo-node (or the equivalent OSPF Designated and Backup Designated
454   Routers)[I-D.ietf-isis-segment-routing-extensions].  The LAN
455   Adjacency Segment TLV allows a node to announce adjacencies to all
456   other nodes attached to the LAN in a single instance of the BGP-LS
457   Link NLRI.  Without this TLV, the corresponding BGP-LS link NLRI
458   would need to be originated for each additional adjacency in order to
459   advertise the SR TLVs for these neighbor adjacencies.

[minor] This paragraph maybe fits better in §2.2.2.


461 2.2.1.  Adjacency SID TLV
...
482      Flags. 1 octet field of following flags as defined in
483      [I-D.ietf-isis-segment-routing-extensions],
484      [I-D.ietf-ospf-segment-routing-extensions] and
485      [I-D.ietf-ospf-ospfv3-segment-routing-extensions].

NEW>
   Flags: 1 octet field.  The value corresponds to the Flags specified for
the
   Adj-SID Sub-TLV in [I-D.ietf-isis-segment-routing-extensions],
   [I-D.ietf-ospf-segment-routing-extensions] or
   [I-D.ietf-ospf-ospfv3-segment-routing-extensions].

487      Weight: Weight used for load-balancing purposes.

[minor] Similar to the above text...

489      Reserved: 2 octets that SHOULD be set to 0 and MUST be ignored on
490      receipt.

492      SID/Index/Label: Label or index value depending on the flags
493      setting as defined in [I-D.ietf-isis-segment-routing-extensions],
494      [I-D.ietf-ospf-segment-routing-extensions] and
495      [I-D.ietf-ospf-ospfv3-segment-routing-extensions].

[minor] Similar text here too...


497 2.2.2.  LAN Adjacency SID TLV
...
[major] The OSPF Neighbor ID / IS-IS System-ID field is not defined.


542 2.2.3.  L2 Bundle Member

[nit] s/L2 Bundle Member/L2 Bundle Member Attribute TLV

544   The L2 Bundle Member Attribute TLV identifies an L2 Bundle Member
545   link which in turn is associated with a parent L3 link.  The L3 link
546   is described by the Link NLRI defined in [RFC7752] and the L2 Bundle
547   Member Attribute TLV is associated with the Link NLRI.  The TLV MAY
548   include sub-TLVs which describe attributes associated with the bundle
549   member.  The identified bundle member represents a unidirectional
550   path from the originating router to the neighbor specified in the
551   parent L3 Link.  Multiple L2 Bundle Member Attribute TLVs MAY be
552   associated with a Link NLRI.

[minor] "identifies an L2 Bundle Member link...The identified bundle
member".  Are we talking about a link or just the members?

...
574      L2 Bundle Member Descriptor: A Link Local Identifier as defined in
575      [RFC4202].

[major] From the text, it looks like this information is not something that
is learned from the IGP, which is then just transported by BGP-LS (just
like the rest of the TLVs in this document), but table 5 points at
draft-ietf-isis-l2bundles.  Why is draft-ietf-isis-l2bundles not used to
describe this TLV?

[major] rfc4202 is not IS-IS-specific.  What about OSPF?  I note that
rfc4203 defines OSPF extensions that include the Link Local Identifier, so
this concept is not foreign to it.

577   Link attributes for L2 Bundle Member Links are advertised as sub-TLVs
578   of the L2Bundle Member Attribute TLV.  The sub-TLVs are identical to
579   existing BGP-LS TLVs as identified in the table below.

[nit] s/L2Bundle/L2 Bundle


...
633 2.3.1.  Prefix-SID TLV
...
[major] draft-ietf-ospf-segment-routing-extensions also includes the MT-ID
in the Prefix SID Sub-TLV.  Is that not needed by a controller?

691 2.3.2.  Prefix Attribute Flags TLV
...
711      Length: variable.

[minor] The length of the flags fields in rfc7794/rfc7684 are both one
octet long.  Can this length be made fixed?

[major] I could not find a Flags field for OSPFv3 in rfc5340.

[minor] From Table 7, it seems that the reference to rfc8362 points to the
"Prefix Options Field", is that correct?

713      Flags: a variable length flag field (according to the length
714      field).  Flags are routing protocol specific and are to be parsed
715      as below:

717      *  IS-IS flags are defined in [RFC7794]

719      *  OSPFv2 flags are defined in [RFC7684]

721      *  OSPFv3 flags map to the Prefix Options field defined in
722         [RFC7794] and extended via [RFC8362]

[nit] The text at the top of this section refers to rfc5340...

[major] rfc7794 only talks about IS-IS, not OSPFv3.


724 2.3.3.  Source Router Identifier (Source Router-ID) TLV

726   The Source Router-ID TLV contains the IPv4 or IPv6 Router-ID of the
727   originator of the Prefix.  For IS-IS protocol this is as defined in
728   [RFC7794].  The Source Router-ID TLV may be used to carry the OSPF
729   Router-ID of the prefix originator.

[major] Reference for OSPF?  Only "may"??

[major] rfc7752 defines the IGP Router-ID TLV to carry the same
information.  What is the relationship between these two TLVs?  Since the
IGP Router-ID TLV is mandatory, are there cases where this one may not be
needed?


...
745      Length: 4 or 16.

[major] OSPF always uses a 32-bit number.  IOW, the length is fixed for
OSPF.

...
749 2.3.4.  Range TLV

751   The range TLV is used in order to advertise a range of prefix-to-SID
752   mappings as part of the Segment Routing Mapping Server functionality
753   [I-D.ietf-spring-segment-routing-ldp-interop], as defined in the
754   respective underlying IGP SR extensions
755   [I-D.ietf-ospf-segment-routing-extensions],
756   [I-D.ietf-ospf-ospfv3-segment-routing-extensions] and
757   [I-D.ietf-isis-segment-routing-extensions].  The Prefix-NLRI to which
758   the Range TLV is attached MUST be advertised as a non-routing prefix
759   where no IGP metric TLV (TLV 1095) is attached.

[major] What do you mean in the final sentence?  It sounds as if the IGP
metric TLV and the Range TLV are mutually exclusive and should never be
advertised together.  Is that it?  If so, what should the receiver do if
they are?


761   The format of the Range TLV is as follows:

763    0                   1                   2                   3
764    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
765   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
766   |             Type              |             Length            |
767   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
768   |     Flags     | Reserved      |             Range Size        |
769   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
770   //                          sub-TLVs                           //
771   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

773   where:

[nit] That "where" should be after the Figure title.

775                        Figure 2: Range TLV format


...
[minor] As will all the other sections, please be consistent and fold the
sub-sections below into the description above.

804 2.3.4.1.  Advertisement Procedure for OSPF

806   The OSPFv2/OSPFv3 Extended Prefix Range TLV is encoded in the Range
807   TLV.  The flags of the Range TLV have the semantic mapped to the
808   definition in [I-D.ietf-ospf-segment-routing-extensions] section 4 or
809   [I-D.ietf-ospf-ospfv3-segment-routing-extensions] section 4.

811   Then the prefix-to-SID mapping from the OSPF Prefix SID sub-TLV is
812   encoded using the BGP-LS Prefix-SID TLV as defined in Section 2.3.1
813   with the flags set according to the definition in
814   [I-D.ietf-ospf-segment-routing-extensions] section 5 or
815   [I-D.ietf-ospf-ospfv3-segment-routing-extensions] section 5.

[major] The Extended Prefix Range TLV contains other fields not present
here: AF, for instance.  The last paragraph seems to indicate that the
prefix information will be in the BGP-LS Prefix-SID TLV, but that
information doesn't come from the Extended Prefix Range TLV (and it doesn't
include the AF).  What am I missing?

[major] The text above seems to imply that the Range TLV and the Prefix-SID
TLV should always be included together.  Is that true?  If so, please make
it more explicit.

817 2.3.4.2.  Advertisement Procedure for IS-IS

819   The IS-IS SID/Label Binding TLV, when used to signal mapping server
820   label bindings, is encoded in the Range TLV.  The flags of the Range
821   TLV have the sematic mapped to the definition in
822   [I-D.ietf-isis-segment-routing-extensions] section 2.4.1.

824   Then the prefix-to-SID mappings from the IS-IS Prefix SID sub-TLV is
825   encoded using the BGP-LS Prefix-SID TLV as defined in Section 2.3.1
826   with the flags set according to the definition in
827   [I-D.ietf-isis-segment-routing-extensions] section 2.4.4.1.

[major] Same questions (as above) related to the other fields in the
SID/Label Binding TLV, and the relationship between the Range TLV and the
Prefix-SID TLV.


829 2.4.  Equivalent IS-IS Segment Routing TLVs/Sub-TLVs
...
837   +---------------------------------------+----------+----------------+
838   | Description                           | Length   | IS-IS TLV/sub- |
839   |                                       |          | TLV            |
840   +---------------------------------------+----------+----------------+
841   | SR Capabilities                       | variable | 2 [1]          |
842   | SR Algorithm                          | variable | 19 [2]         |
843   | SR Local Block                        | variable | 22 [3]         |
844   | SRMS Preference                       | 1        | 19 [4]         |
845   | Adjacency Segment Identifier (Adj-    | variable | 31 [5]         |
846   | SID)                                  |          |                |
847   | LAN Adjacency Segment Identifier      | variable | 32 [6]         |
848   | (LAN-Adj-SID)                         |          |                |
849   | Prefix SID                            | variable | 3 [7]          |
850   | Range                                 | variable | 149 [8]        |
851   | SID/Label TLV                         | variable | 1 [9]          |
852   | Prefix Attribute Flags                | variable | 4 [10]         |
853   | Source Router ID                      | variable | 11/12 [11]     |
854   | L2 Bundle Member TLV                  | variable | 25 [12]        |
855   +---------------------------------------+----------+----------------+

[major] Instead of using URIs, please put an explicit pointer to the RFC/ID
(and if desired, the section)...and make sure that there are corresponding
References.  If a document is referenced only in this table, then the
Reference can be Informative.

[nit] For Tables 5-7: No need to use "TLV" in the description.

857          Table 5: IS-IS Segment Routing Extensions TLVs/Sub-TLVs

859 2.5.  Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs
...
886          Table 6: OSPF Segment Routing Extensions TLVs/Sub-TLVs

[nit] s/OSPF/OSPFv2

[minor] The OSPF tables don't include the Source Router ID or the L2 Bundle
Member TLVs.  Is there a reason for that, or just an oversight?

...
908 3.  Implementation Status

[nit] This section says nothing. :-(   At least a pointer to
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-ext-implementations
might be nice.  OR, you can just remove it.


...
943 4.  IANA Considerations

945   This document requests assigning code-points from the registry "BGP-
946   LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
947   TLVs" based on table Table 8.  The column "IS-IS TLV/Sub-TLV" defined
948   in the registry does not require any value and should be left empty.

[major] The early allocation has already been done...so this document
doesn't request assignment from IANA.  Please update.


...
977 5.  Manageability Considerations

979   This section is structured as recommended in [RFC5706].

981   The new protocol extensions introduced in this document augment the
982   existing IGP topology information that was distributed via [RFC7752].
983   Procedures and protocol extensions defined in this document do not
984   affect the BGP protocol operations and management other than as
985   discussed in the Manageability Considerations section of [RFC7752].
986   Specifically, the malformed attribute tests for syntactic checks in
987   the Fault Management section of [RFC7752] now encompass the new BGP-
988   LS Attribute TLVs defined in this document.  The semantic or content
989   checking for the TLVs specified in this document and their
990   association with the BGP-LS NLRI types or their BGP-LS Attribute is
991   left to the consumer of the BGP-LS information (e.g. an application
992   or a controller) and not the BGP protocol.

[nit] s/that was distributed/that is distributed

994   A consumer of the BGP-LS information is retrieving this information
995   from a BGP protocol component that is doing the signaling over a BGP-
996   LS session, via some APIs or a data model (refer Section 1 and 2 of
997   [RFC7752]).  The handling of semantic or content errors by the
998   consumer would be dictated by the nature of its application usage and
999   hence is beyond the scope of this document.  This document only
1000   introduces new Attribute TLVs and an error in them would result in
1001   only that specific attribute being discarded with an error log.

[nit] s/is retrieving this/retrieves this

[minor] "...retrieving this information...over a BGP-LS session, via some
APIs or a data model (refer Section 1 and 2 of [RFC7752])."  I think that
even mentioning that an API or data model can be used instead of BGP-LS is
a stretch -- that is not how I interpret the initial sections in rfc7752
(which are just background sections), and there are no formal API/data
model definition.

[major] "...new Attribute TLVs and an error in them would result in only
that specific attribute being discarded with an error log."  According to
rfc7752, this statement is true only for syntactic errors, not semantic
ones.

Semantic errors ("left to the consumer", as mentioned above) means that the
BGP-LS session can be used to transport trash (trash-in-trash-out).  Jeff
Haas brought this up during the WGLC [4].  I agree (with the Chairs'
conclusion) that this issue is bigger than this document -- but (because we
don't have a current solution) I would like to see it mentioned somewhere
as a potential issue (maybe in the Management or Security Considerations
sections, your choice).

[4] https://mailarchive.ietf.org/arch/msg/idr/Yfp6WyqnRtMAOeZvSvK7rYCUkHg

[major] rfc7752 does mandate the use of "attribute discard" (rfc7606). I
would really like to see a discussion (or at least a mention) around the
fact that discarding an attribute may result in the receiver not having
complete information.  In the case of SR, this implies that the controller
may not have complete information to calculate the paths.

I think this is an issue bigger than this document, so I am not asking you
to solve it...I'm just asking for the document to acknowledge that it
exists and to mention what the potential impact may be.


1003   The extensions, specified in this document, do not introduce any new
1004   configuration or monitoring aspects in BGP or BGP-LS other than as
1005   discussed in [RFC7752].  The manageability aspects of the underlying
1006   SR features are covered by [I-D.ietf-spring-sr-yang],
1007   [I-D.ietf-isis-sr-yang] and [I-D.ietf-ospf-sr-yang].

[minor] While the Yang models have to do with management, there are no
"manageability aspects of the underlying SR features" included there.

[major] Following the recommendations from rfc5706, a Fault Management
section would be appropriate to include considerations related to the use
of BGP-LS as a transport for SR information (given this is the first draft
to propose it), and the possible errors mentioned here...  Again, not
looking for solutions, just acknowledgement.


1009 6.  Security Considerations

1011   The new protocol extensions introduced in this document augment the
1012   existing IGP topology information that was distributed via [RFC7752].
1013   The Security Considerations section of [RFC7752] also applies to
1014   these extensions.  The procedures and new TLVs defined in this
1015   document, by themselves, do not affect the BGP-LS security model
1016   discussed in [RFC7752].

[nit] s/that was distributed/that is distributed

1018   BGP-LS SR extensions enable traffic engineering use-cases within the
1019   Segment Routing domain.  SR operates within a trusted domain (refer
1020   Security Considerations section in [RFC8402] for more detail) and its
1021   security considerations also apply to BGP-LS sessions when carrying
1022   SR information.The SR traffic engineering policies using the SIDs
1023   advertised via BGP-LS are expected to be used entirely within this
1024   trusted SR domain (e.g. between multiple AS/domains within a single
1025   provider network).  Therefore, precaution is necessary to ensure that
1026   the SR information collected via BGP-LS is limited to specific
1027   controllers or applications in a secure manner within this SR domain.

[nit] s/trusted domain (refer Security Considerations section in [RFC8402]
for more detail)/trusted domain [RFC8402]

[nit] s/SR information.The SR traffic/SR information. The SR traffic

[major] "SR operates within a trusted domain...[RFC8402]...and its security
considerations also apply to BGP-LS sessions when carrying SR information."
 The Security Considerations in rfc8404 really only talk about the data
plane -- I don't see how they apply to the BGP-LS sessions.

[major] "...precaution is necessary to ensure that the SR information
collected via BGP-LS is limited to specific controllers or applications..."
 This sounds as if you're referring to information that (once collected)
can be shared between controllers -- I think that case is out of scope.  If
you are trying to talk about the BGP sessions, then I think the language
needs a little more work.  BTW, the paragraph below also talks about BGP
sessions; suggestion: keep the common topics together.

[major] The end of the last sentence says "...in a secure manner within
this SR domain".  Assuming that we're talking about BGP sessions, what does
that mean?  Does it mean anything beyond what BGP is normally specified to
do?  If not, then I would recommend taking that piece of text out to not
invite more questions than needed.

[minor] You talk about "controllers or applications", but in the rest of
the document you have mostly used "consumer" (which is a good thing because
it shows consistency with rfc8402).  Suggestion: use "consumers" here as
well.

1029   The isolation of BGP-LS peering sessions is also required to ensure
1030   that BGP-LS topology information (including the newly added SR
1031   information) is not advertised to an external BGP peering session
1032   outside an administrative domain.

[major] What does "isolation of BGP-LS peering sessions" mean?  Why is it
not Normatively REQUIRED?

[major] From prior experience (see draft-ietf-idr-te-pm-bgp), the
SecDir/Sec ADs asked for text related to why it is ok to transport the new
information in BGP.  This is the text that resulted from that discussion:

   The TLVs introduced in this document are used to propagate IGP
   defined information ([I-D.ietf-lsr-isis-rfc7810bis] and [RFC7471].)
   These TLVs represent the state and resource availability of the IGP
   link.  The IGP instances originating these TLVs are assumed to
   support all the required security and authentication mechanisms (as
   described in [I-D.ietf-lsr-isis-rfc7810bis] and [RFC7471]) in order
   to prevent any security issue when propagating the TLVs into BGP-LS.
   The advertisement of the link attribute information defined in this
   document presents no additional risk beyond that associated with the
   existing set of link attribute information already supported in
   [RFC7752].

Note that this text is complementary to what is already stated in the first
paragraph -- but goes into a more explicit explanation and brings in the
security considerations from the documents where the IGP extensions are
defined.  Consider adding something similar here.


...
1126 9.2.  Informative References
...
1159   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
1160              Decraene, B., Litkowski, S., and R. Shakir, "Segment
1161              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
1162              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[major] I think this should be a Normative reference.


1164 9.3.  URIs

[major] As mentioned before, please use References (above) instead of URIs.


...
1197   [12] http://tools.ietf.org/html/draft-ietf-isis-l2bundles-07

[major] The reference should become Normative (see §2.2.3).