[Idr] Shepherd review of draft-ietf-idr-bgp-ls-node-admin-tag-extension-03.txt

["Susan Hares" <[e-mail]>]

This is a shepherd review of your draft after WG LC.   

 Please treat these as a WG LC call comment. 

 

Cheerily Sue Hares 

 

=============

 

Overview:  The draft is an addition to the BGP-LS feature 

set that is a natural outgrowth of existing work

in the LSR working (OSPF and ISIS).  

 

Status: Major issue - no error handling section

Minor issues: manageability and security section. 

 

A)     Error handling comments 

 

RFC 7606 indicates different types of error procedures for

NRLIs and attributes.  Page 9-10 indicates that typed NLRIs

need to provide the details on what constitutes valid NLRIs. 

 

Normally, an error handling section within a NLRI 

indicates what is considered a malformed NLRI  (syntax error) 

or an invalid NLRI (content error). 

 

RFC7752 provides a list of questions to determine if the message is 

Malformed in section 6.6.2 (Fault management). 

Your draft as an augment to RFC7752 should provide 

error handling information regarding malformed TLVs (faults) 

and invalid content.   

----

For Malformed TLVs,  you have two open issues: 

 

1.       Reserved fields of the Flag field 

Please specify what value the flag field's reserve values can take.  

If you wish to have it transmitted as zero, and

Receiver should ignore.  Please specify this point. 

 

2.       Define what makes a malformed TLV

You can do this within the text of figure 6 or 

In the paragraphs at the top of page 7. 

Do you consider inclusion of the Node Admin Tag TLV

to be malformed if it is associated with something 

beside a Node Attribute? 

 

IHMO - it seems like an invalid content, but 

It could be viewed either way. 

-------

For invalid content, you have specify invalid content 

in the 3 paragraphs at the top of page 7 in section 3.1.

The text in section 4 indicates how the text should be 

how the tag should be properly processed. 

 

The text in section 3.1 seems to indicate what content 

(origination and reception) is invalid.  However, you do not 

Indicate what you do with invalid Node Admin Tags. 

 

The choices could be: 

1)      the entire Link State NLRI to be considered is invalid, 

2)      the Node NLRI within the Link State NLRI is invalid 

3)      the local node or remote node descriptors, the TLV is contained are
all invalid

4)      just the Administrative Tag Sub-TLV is valid 

 

It is unclear from your document how this error is handled. 

-----------

 

Section 4, indicates the processing of the 

content of a well-formed Sub-TLV with 

correct syntax.  If you feel error handling needs to 

report any handling of the SHOULD, MAY or MUST NOT clauses, 

you should add this to the error process. 

 

Section 5, indicates deployment processing. 

Again, if you feel error handling needs to 

Report any handling of the SHOULD or MAY clauses,

Add this to the error reporting. 

 

IMHO - I do not feel section 4 or 5 warrants specific 

protocol on the wire specification error reporting. 

I am fine with the text as it is .

--------------

 

Lesser issues: 

 

Section 6 Manageability 

 

Comment: Operational procedures are changing because you 

are re-originating "global" scope node tags in another "node admin

tag" TLV.   You break > 16383 node administrative groups down

into multiple tags.  

 

This added process does not simply copy information from 

ISIS or OSPF as it exists.  Manageability would indicate some 

logging of these additional changes will or will not occur. 

---

 

Section 7 - Security considerations

 

Since the tagging of nodes may cause avoidance of a set of 

Nodes ( per section 5), the security section needs to include

Information on why this cannot be done to harm 

 

Editorial NITs: 

Acknowledgements - need to be changed from TBA.