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

[Pushpasis Sarkar <[e-mail]>]

Hi Sue,

Thanks a lot for the review comments and many apologies for the late reply.
My day-job has been drowning me with loads of deliverables. Hence could not
check my mailbox earlier. I will revert back with resolutions by end of the
coming week.

Thanks once again and best regards,
-Pushpasis


On Wed, May 9, 2018 at 3:21 AM, Susan Hares <[e-mail]> wrote:

> 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.
>
>
>
>
>
>
>
>
>