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

Alia Atlas <akatlas@gmail.com> Fri, 17 March 2017 18:13 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC26129502; Fri, 17 Mar 2017 11:13:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJZ9KdUcPQ1c; Fri, 17 Mar 2017 11:13:22 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA701273E2; Fri, 17 Mar 2017 11:13:21 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id n11so21737165wma.1; Fri, 17 Mar 2017 11:13:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZgKTKkRnBBTVsUFqXnOoLeiYMoau+FJT6s3siAeB+zQ=; b=AzXe/h3+z7lus4qj/kd12yHQSbxAAaiVQe6sl2uI6+5CLdWSG2SulE00kH32bzUteq 4m5X/4yk1i+XOTjXgeKYJZi29Ryah/59gtGzoP+o98MNQ/1oE2ZsaM+7lT9OSD/ft+J0 AbvGCQtuaom69jFckPOhd5OAPTRQ3QsUAxFflp4Llh6vYYGSbaosnBLtOijI3x91yC0Z YVBugL9Hw0xvMjiGW/VJXooF5meoCzq8kMMJof1/SEicLx/FFiGqfzM1d++gxbZHykXB 8WitjhqGZZehptBQrhhELN6dQYqrmmdK9bEhsxbhr47ITttcfqBj3CMQFih83rGtzolW tN+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZgKTKkRnBBTVsUFqXnOoLeiYMoau+FJT6s3siAeB+zQ=; b=gO5weq9uKdClbO7xUG/Z+jVn7cU+OOm0LhStEyvF/U/FyZxD3Ug/lg4CbKf8trUn0D 95uW0Jq9q75i3k9nzM9s+tPZJ/TVim1RJjX+jMrWZsC4Dc6r5e3dGhhrSuKXN7eAawq5 oRlmhk4q/gn9CdLcCqfFJENClqJAWCiXXX1XSTbiLbShHBwuj3MDennow6If/XNHTKjq X88dv7apeJvpBk2f96awDCMdrjYhTMcghZJe2W4K6zBvNmi5R5aqsP9ZIqAMJUOUl5/V xfpQqzbD/QkJw7OsRebrXfi4OegIBh+TVJ2zK1MWogn/pILjIWViDuwmVDs0SO2V8HiP wrLA==
X-Gm-Message-State: AFeK/H2Lx2WJTpdLpHHOUbvthtrgRTrtJdmIWMP/ub6vA4k7ggr6j18lwvKJR3dp+p5ZB2O2kDh8nX4I9T6E1A==
X-Received: by 10.28.30.79 with SMTP id e76mr3971337wme.96.1489774399925; Fri, 17 Mar 2017 11:13:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.145.69 with HTTP; Fri, 17 Mar 2017 11:13:19 -0700 (PDT)
In-Reply-To: <43be9b6ac3fa41708303a2a352360ab4@XCH-ALN-001.cisco.com>
References: <CAG4d1reSNUyDZwUN1tB4zJAJcfs40618_x5DpFofr99cQc3B0g@mail.gmail.com> <43be9b6ac3fa41708303a2a352360ab4@XCH-ALN-001.cisco.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Fri, 17 Mar 2017 14:13:19 -0400
Message-ID: <CAG4d1reoNrr3hz7cw3CiXy2x9-mzERKxQ0rAXeqmQpgmQDMZ2w@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "isis-wg@ietf.org" <isis-wg@ietf.org>, "draft-ietf-isis-mi-bis@ietf.org" <draft-ietf-isis-mi-bis@ietf.org>
Content-Type: multipart/alternative; boundary=001a114b2de4e73832054af121d9
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/y_cmAK3uiQ-xMVisWkV14Y3thDI>
Subject: Re: [Isis-wg] AD review of draft-ietf-isis-mi-bis-01
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Mar 2017 18:13:24 -0000

Hi Les,

On Fri, Mar 17, 2017 at 1:57 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com
> wrote:

> Alia –
>
>
>
> Thanx for meticulous review.
>
> Inline.
>
>
>
> *From:* Alia Atlas [mailto:akatlas@gmail.com]
> *Sent:* Friday, March 17, 2017 8:47 AM
> *To:* isis-wg@ietf.org; draft-ietf-isis-mi-bis@ietf.org
> *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*
>
> *   [RFC5309]…”*
>

Thanks - you are completely correct.


 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?*
>

Yes, I didn't go and look up Errata ID #4519 to catch the context of
pt-to-pt on broadcast only.   That would make it more of a nit than a minor
issue, of course.

This all does imply that:
   a) IIH with IID=0 is a capability advertisement for pt-to-pt links but
not pt-to-pt on broadcast.
   b) It is never ok (discarded by receiver) to send an IIH with IID=0 on a
pt-to-pt on broadcast.
   c) The capability indicator for being an MI-RTR on a pt-to-pt on
broadcast link is whether or not the ALLL1MI-IS or ALLL2MI-IS is listened
to or sent on.

I know there is real code and deployments behind this - but that's a bit
confusing for trouble-shooting & it would be nice to have it more clearly
articulated.


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

Yes - we need to do that.


Incidentally, on another reread (checking the above issues) is there a
reason that
"The destination multicast address is one of the two new addresses
 and the PDU contains an IID-TLV with a zero value for the IID or
 has no IID-TLV."

doesn't simply name the addresses (ALLL1MI-IS or ALLL2MI-IS)?  I think
that'd be clearer - but this is definitely nit.



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

Sounds good.

Thanks,
Alia



> *   Les*
>
>
>
> Regards,
>
> Alia
>