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

Alia Atlas <akatlas@gmail.com> Fri, 17 March 2017 18:59 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 BCE4A1293FD; Fri, 17 Mar 2017 11:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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 yp6XI2lHzyqy; Fri, 17 Mar 2017 11:59:04 -0700 (PDT)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 B84E212709D; Fri, 17 Mar 2017 11:59:03 -0700 (PDT)
Received: by mail-wr0-x22b.google.com with SMTP id u48so57727140wrc.0; Fri, 17 Mar 2017 11:59:03 -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=bt/RF98rDHx0ChBFG9diDaaBsuYDT8ugAaX5ZUB1sHg=; b=jxBsFyN4DSsnmBpfzFaO2U2L/L6C5ra3OZRYI0yEvBMKj04he6stHFKTXjn7/u3tP0 S7TUo+e7KcLu8Oe6KKlICmxopv76DO5k4hxfzsCKLWTFO9X2WP57rG3OlaaRZ3t3nWDu bc4tFB/Rx9dkgCyM5kfYSd2t9Z1+M08OfAweSbB0VWXoYcOVDXRg5CAMWlywUl/LHUgG JeOsr34AtRhFL/Ks0herfK0jzEuwGqRZvyijMHDHeb1FnM9KJ1HNQTFRxC/lSYbzA/wG SEzjNKduactWALcUXncFDQu9ZsZ2JYqqrtLr1NxCqUyR7+VZOhiHMkPapPmrfAs/34BQ ASPw==
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=bt/RF98rDHx0ChBFG9diDaaBsuYDT8ugAaX5ZUB1sHg=; b=aziZDtZuGWhkgpzwzh8A6eLHRHOYHMiIh86IvkKI9QeYbaOiy2f/iqY3/4LM05W1kH rrpLNGGyb3Qrjv048HtiW9avoHNB7IohU3VzZNs3fL9sRiMeVWn3o/dbEJIm0oQAFC+G qAlQFpULM8cDIem4rrkaKYrNhnrQA/SeMokyaJwYay7XqU/KU5pg4c8Q3Toh4QL9C1tM 3G+WvHEDho5a8+EihtDerz0NjJFNC/vlGQEOGVjbhSIbxQhNvKpzdMSsfu3fXxYRqVXV /NeCoR8RVPZ5P6HijizPI3QvL4DzU/hCwOp8e20GNzYZcK2itK9pF4fRvWWi5Z13j7Fg 9ZtQ==
X-Gm-Message-State: AFeK/H2h42mlgaPw22O2fXRaB1Fa4vUSgv7H794CawSc9If0CF1pvCP5mT6EPYJTfbh928MOOoiUvca9D530fQ==
X-Received: by 10.223.150.110 with SMTP id c43mr14373656wra.85.1489777141985; Fri, 17 Mar 2017 11:59:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.145.69 with HTTP; Fri, 17 Mar 2017 11:59:01 -0700 (PDT)
In-Reply-To: <ab82a1390bb84212a2c0ba7a6488b8ce@XCH-ALN-001.cisco.com>
References: <CAG4d1reSNUyDZwUN1tB4zJAJcfs40618_x5DpFofr99cQc3B0g@mail.gmail.com> <43be9b6ac3fa41708303a2a352360ab4@XCH-ALN-001.cisco.com> <CAG4d1reoNrr3hz7cw3CiXy2x9-mzERKxQ0rAXeqmQpgmQDMZ2w@mail.gmail.com> <ab82a1390bb84212a2c0ba7a6488b8ce@XCH-ALN-001.cisco.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Fri, 17 Mar 2017 14:59:01 -0400
Message-ID: <CAG4d1rfJCDUHCAW2tf=0s0LagUMuMxhEgakWBZN+ryYVEhqKHg@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=001a11476a3057d82a054af1c56d
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/wH08TBv4sVTWSkxFs-1qKHaeKeU>
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:59:08 -0000

Hi Les,

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

> Alia  -
>
>
>
> *From:* Alia Atlas [mailto:akatlas@gmail.com]
> *Sent:* Friday, March 17, 2017 11:13 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* isis-wg@ietf.org; draft-ietf-isis-mi-bis@ietf.org
> *Subject:* Re: AD review of draft-ietf-isis-mi-bis-01
>
>
>
> 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.
>
> *[Les:] From Section 2.6.1:*
>
>
>
>   MI-RTRs MUST discard IS-IS PDUs received if either of the following
>
>    is true:
>
>
>
>    o  The destination multicast address is AllL1IS, AllL2IS, or AllIS
>
>       and the PDU contains an IID-TLV
>
>
>
>    o  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.
>
>
>
> From Section 2.6.2:
>
>
>
>    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.
>
>
>
> *[Les:] I think this language is very precise.*
>
> *It is true that operation in Point-to-point mode on a broadcast media is
> subtly different than operation on true P2P media – which is why we discuss
> the two in different sections.*
>
> ??
>

Yes, I agree that there isn't a technical gap.  What I was hoping for is a
bit of clarity
for an operator or someone troubleshooting.  Normally, I'd expect the same
information being sent across a pt-to-pt link, regardless of whether it was
over broadcast or not.

There's also the aspect of sending consistently the IIH with IID!=0 on a
pt-to-pt broadcast b/c there's no way other than a response of telling that
the neighbor has changed to be an MI-RTR.

I'm thinking of text like the following - and feel free to
modify/reject/improve, but sometimes text helps clarify.

"An MI-RTR detects the capability of its neighbor to also be an MI-RTR
differently based upon the type of link.  For a point-to-point broadcast
link, an MI-RTR that is configured to support instances beyond the IID=0
will periodically send out IIHs with an IID-TLV to either ALLL1MI-IS or
ALLL2MI-IS; if a corresponding IIH with a matching IID-TLV is received,
then a neighbor adjacency formation for that IIH can proceed.  If a router
is not configured to support additional instances between IID=0, it is not
possible to determine, based on protocol traffic, whether that router is an
MI-RTR.

Differences in configuration can be determined by examining the IIHs sent
on ALLL1MI-IS or ALLL2MI-IS.  For a point-to-point circuit, an MI-RTR that
is configured to support MI will include an IID-TLV with IID=0 in its IIH.
  If the receiving router doesn't recognize the IID-TLV or is not
configured to be an MI-RTR, then the IID-TLV will simply be discarded.  If
there is a difference in configuration to be an MI-RTR, that can be
determined by examining whether the IIH includes an IID-TLV where the
IID=0.  However, determining differences in configuration for additional
IIDs cannot be done based on protocol traffic until both routers recognize
that their neighbor is an MI-RTR."

Basically, for one type of link, it is possible to tell the capability but
not the instances and for the other it is possible to tell the instances,
but not the capability.

Frankly, the proposed text above feels too long to me - so please do
improve it!

Regards,
Alia

> 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.
>
>
>
>
>
> *[Les:] Happy to explicitly call out the specific addresses in the second
> bullet.*
>
>
>
> *   Les*
>
>
>
> *Let me know if the above changes will suffice and I will spin a new
> version.*
>
>
>
> Sounds good.
>
>
>
> Thanks,
>
> Alia
>
>
>
>
>
> *   Les*
>
>
>
> Regards,
>
> Alia
>
>
>