Subject: Opsdir telechat review of draft-ietf-bier-isis-extensions-07

From: Joe Clarke <[email-masked]>
Date: Wed, 21 Feb 2018 08:19:15 -0800

Reviewer: Joe Clarke
Review result: Has Nits

I am reviewing  draft-ietf-bier-isis-extensions-07 on behalf of the ops
directorate in an effort to ensure attention to operational considerations. 
This document defines a new sub-TLV for IS-IS for use with BIER.  It also
defines an IANA registry for additional sub-sub-TLVs for this new BIER sub-TLV.
 Overall, this document is ready with some nits.

The only substantive comment I have is in section 5.6 regarding reporting
misconfigurations.  What is not stated is _how_ this is to be done.  There is
no reference to a standard BIER or IS-IS mechanism with how this reporting
should be carried out.  For operational consistency, I feel some guidance
should be offered.

The one nit I noticed is in section 6.2:

OLD:

Label ranges in multiple sub-sub-TLV MUST NOT overlap.

NEW:

Label ranges in multiple sub-sub-TLVs MUST NOT overlap.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Feb 2018 18:24:06 +0000

Joe -

Thanx for the review.

> -----Original Message-----
> From: Joe Clarke (jclarke)
> Sent: Wednesday, February 21, 2018 8:19 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Opsdir telechat review of draft-ietf-bier-isis-extensions-07
> 
> Reviewer: Joe Clarke
> Review result: Has Nits
> 
[Les:] Implementations have many possible vehicles for logging errors/significant events. There are proprietary logging mechanisms, standardized network management events, etc. I don’t think it is within scope of this document to discuss (for example) the YANG model - nor is it in general within the scope of the IETF to specify how proprietary logging mechanisms should work. So I really have no clue as to what you expect here.

We are simply specifying that  implementations treat this as a loggable event. How they do it is out of scope.

> Label ranges in multiple sub-sub-TLVs MUST NOT overlap.

[Les:] ACK

   Les

---

From: Joe Clarke <[email-masked]>
Date: Wed, 21 Feb 2018 16:27:27 -0500

On 2/21/18 13:24, Les Ginsberg (ginsberg) wrote:
> [Les:] Implementations have many possible vehicles for logging
> errors/significant events. There are proprietary logging mechanisms,
> standardized network management events, etc. I don’t think it is within
> scope of this document to discuss (for example) the YANG model - nor is
> it in general within the scope of the IETF to specify how proprietary
> logging mechanisms should work. So I really have no clue as to what you
> expect here.
> 

In my read of this, it was the use of "report" vs. logging that threw
me.  Not being the BIER guy, I wasn't sure if you were referring to some
protocol-specific inband signaling to indicate the misconfiguration to
other routers.

I agree that the implementation of how operational notifications should
be done is outside this scope.  But given that you use "logging" in
here, it might be sufficient just to say "(e.g., through its logging
channels)".  That said, I might be alone in this interpretation.

Joe

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Feb 2018 21:36:16 +0000

Joe -

> Sent: Wednesday, February 21, 2018 1:27 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
> Subject: Re: Opsdir telechat review of draft-ietf-bier-isis-extensions-07
> 
> >> The only substantive comment I have is in section 5.6 regarding
> >> reporting misconfigurations.  What is not stated is _how_ this is to
> >> be done.  There is no reference to a standard BIER or IS-IS mechanism
> >> with how this reporting should be carried out.  For operational
> >> consistency, I feel some guidance should be offered.
> >>
> > standardized network management events, etc. I don’t think it is
> > within scope of this document to discuss (for example) the YANG model
> > - nor is it in general within the scope of the IETF to specify how
> > proprietary logging mechanisms should work. So I really have no clue
> > as to what you expect here.
> >
> > We are simply specifying that  implementations treat this as a
> > loggable event. How they do it is out of scope.
> 
> In my read of this, it was the use of "report" vs. logging that threw me.  Not
> being the BIER guy, I wasn't sure if you were referring to some protocol-
> specific inband signaling to indicate the misconfiguration to other routers.
> 
> I agree that the implementation of how operational notifications should be
> done is outside this scope.  But given that you use "logging" in here, it might
> be sufficient just to say "(e.g., through its logging channels)".  That said, I
> might be alone in this interpretation.
> 
[Les:] OK - how about:

<begin>
Section: Logging Misconfiguration
Whenever an advertisement is received which violates any of the constraints defined in this document the receiving router MUST support logging this occurrence. Logging SHOULD be dampened to avoid excessive output."
<end>

??

   Les

---

From: Joe Clarke <[email-masked]>
Date: Wed, 21 Feb 2018 16:39:04 -0500

On 2/21/18 16:36, Les Ginsberg (ginsberg) wrote:
> Whenever an advertisement is received which violates any of the
> constraints defined in this document the receiving router MUST support
> logging this occurrence. Logging SHOULD be dampened to avoid excessive
> output."
> <end>
> 
> ??

I would not have raised this point if that's how it had read.  That is
much clearer that this is logging (or reporting or notifying) for
out-of-band operational purposes.

Joe