Subject: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 28 Jun 2017 06:37:47 +0000

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  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir .

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 comments that you receive, and strive to resolve them through discussion or by updating the draft. 

Document: draft-ietf-idr-bgp-ls-node-admin-tag-extension-01
Reviewer: Les Ginsberg
Review Date: June 27, 2017
Intended Status: Standards

Summary:  The document is of modest scope - covering definition of BGP-LS
codepoints for a relatively new IGP attribute (Node Admin Tags). 
While I found nothing which I would consider a major issue, there are a number
of places where the text lacks clarity. I think addressing these areas would
greatly improve the quality of the draft.

Major Issues: None

Minor Issues: 

Section 1 Introduction

The acronym LSDB is not defined.

Figure 1

I have a personal dislike for duplicating text/pictures from another
spec when that spec could simply be referenced. There are only two
possible outcomes:

1)The duplicated text is redundant (best case)
2)The text differs somewhat from the original leading to possible 
unintentional misinterpretations.

Suit yourself on this comment - but I would prefer the duplication be omitted.

Section 2 First paragraph

You refer to "sub-TLV" but that reference is unclear and ambiguous.
IS-IS uses a sub-TLV of Router Capability to advertise tags, but OSPF
uses a TLV of Router Info LSA.
What seems most relevant here is that you are defining a new Attribute
TLV for Node NLRI.

Section 3 Second paragraph

I do not know what the paragraph is trying to say, nor do
I know what the "TBD" in columns 4 and 5 in the following Table 1 is
meant to reference. If you are simply trying to describe the source
of the info advertised by the new BGP-LS Node attribute then you should
rewrite the above paragraph and in the figure below show:

IS-IS 242/21
OSPF RI-LSA/10

Section 3.1

A description of where in the Node NLRI the area/level information can be found
(from RFC 7752) would be helpful.

Section 3.1 Penultimate Paragraph

As TAGs with "global" scope will be advertised by the IGP multiple
times (once per area/level) I assume you are asking BGP-LS advertisements
to reduce these multiple occurrences to a single occurrence? More
explicit language on that point would be helpful.

Section 3.1 Last paragraph

I recognize this statement regarding policy being used to filter what is
advertised is consistent with RFC 7752. But it would also be good to include
a statement like:

"Definition of such a policy is outside the scope of this document."

Nits: Please see attached diff file with some editorial corrections.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 28 Jun 2017 22:26:36 -0700

Hi Les,

Thanks a lot for the review comments. I will reply back addressing your
comments soon.

Thanks and regards
-Pushpasis

On Tue, Jun 27, 2017 at 11:37 PM, Les Ginsberg (ginsberg) <
[email-masked]> 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  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir .
>
> 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
> comments that you receive, and strive to resolve them through discussion or
> by updating the draft.
>
>