Re: [Isis-wg] AD review of draft-ietf-isis-mi-bis-01

"Les Ginsberg (ginsberg)" <> Fri, 17 March 2017 17:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E2A11293E3; Fri, 17 Mar 2017 10:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yMVg3V1T-XPe; Fri, 17 Mar 2017 10:57:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 082E81273E2; Fri, 17 Mar 2017 10:57:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=20884; q=dns/txt; s=iport; t=1489773427; x=1490983027; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=f+YHPS86rpMxMo48toqsbn3981jYrj1ITNWThzXd9jY=; b=LMcxRepdimOrl+77ghQ/qyLBHUX65OmrxMxAkJQjQ37VSDXM7mir1db9 C3jGJwDOo7Z0r0RnGDOGaJh+wb8Y/rgqzkvtMQ89Ucu9sxN+yOHB44Fb1 ShSsep+iFUeXFOmRy8ZUkVwhLakPOgZxmexEcTREF0af3pECAXSpi4zfo c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.36,177,1486425600"; d="scan'208,217";a="398478363"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Mar 2017 17:57:06 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v2HHv5BB025558 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Mar 2017 17:57:05 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 17 Mar 2017 12:57:05 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Fri, 17 Mar 2017 12:57:05 -0500
From: "Les Ginsberg (ginsberg)" <>
To: Alia Atlas <>, "" <>, "" <>
Thread-Topic: AD review of draft-ietf-isis-mi-bis-01
Thread-Index: AQHSnzW2SbE6C4ZbzUa6gBdVacKo6KGZTDKw
Date: Fri, 17 Mar 2017 17:57:05 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_43be9b6ac3fa41708303a2a352360ab4XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Isis-wg] AD review of draft-ietf-isis-mi-bis-01
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Mar 2017 17:57:09 -0000

Alia –

Thanx for meticulous review.

From: Alia Atlas []
Sent: Friday, March 17, 2017 8:47 AM
Subject: AD review of draft-ietf-isis-mi-bis-01

As is customary, I have done my AD review of draft-ietf-isis-mi-bis-01.  First, I would like to thank the authors - Les, Stefano, and Wim - for their work on this document.

I do have a few minor issues that need to be fixed ASAP.   I will, however, go ahead and issue a 3 week IETF Last Call for it so that, if the authors act promptly, it can be on the April 13 telechat.

1) This draft pretty clearly should obsolete RFC 6822, but the header claims to merely
update it.

[Les:] OK

 2) Sec 2.6.2: " Point-to-point adjacency setup MUST be done through the use of the
         three-way handshaking procedure as defined in [RFC5303] in order to
         prevent a non-MI capable neighbor from bringing up an adjacency
         prematurely based on reception of an IIH with an IID-TLV for a non-
         zero instance."
     While obviously the 3-way handshake in RFC5303 is fine, given that different MAC addresses are used, I don't see how a non-MI capable neighbor would receive and process an IIH with an IID-TLV where IID != 0.

[Les:] Section 2.6.2 is only talking about true pt-pt media – hence MAC multicast addresses are not relevant. In Section 2.6.1 we discuss the case of operating in Pt-Pt mode on a broadcast circuit:

“When operating in point-to-point mode on a broadcast circuit

3) In Appendix A:" Clarification that the IID-TLV is only included in Pt-Pt IIHs
   associated with non-zero instances has been added.  This addresses
   Errata ID #4519."
   In Sec 2.6.2, it says "The presence or absence of the IID-TLV in an IIH indicates that the
   neighbor does or does not support this extension, respectively.
   Therefore, all IIHs sent on a point-to-point circuit by an MI-RTR
   MUST include an IID-TLV.  This includes IIHs associated with IID #0." which is a direct
   contradiction and needed since the IID-TLV is used as a capability indication.  The
   simplest solution is to remove the claim from the Appendix.
[Les:] Again, you are confusing Pt-Pt media with Pt-Pt operation on a Broadcast media. Errata 4519 is concerned with Pt-Pt operation on a LAN – and some modest clarifications in Section 2.6.1 were made to more completely cover the latter case.
In the Pt-Pt operation on a LAN case it IS illegal to send IID-TLV in hellos for the zero instance – which Section 2.6.1 explicitly states.

Perhaps the Appendix should say:

“Clarification that when operating in point-to-point mode on a broadcast circuit the IID-TLV is only included in Pt-Pt IIHs
   associated with non-zero instances has been added. ..”

Will this address your concern?

4) In the IANA considerations, the references should be updated to point to this document, and most particularly if it obsoletes RFC 6822.

[Les:] Agreed. I did not think I had to state that – I assumed IANA would just do that – but I am happy to add a line in IANA section stating that all references to RFC 6822 should be updated to point to this document.

Let me know if the above changes will suffice and I will spin a new version.