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

Alia Atlas <akatlas@gmail.com> Fri, 17 March 2017 19:04 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 60420129401; Fri, 17 Mar 2017 12:04:44 -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 MJSqQxWJkaFd; Fri, 17 Mar 2017 12:04:41 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 492CD12940A; Fri, 17 Mar 2017 12:04:40 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id u132so22698605wmg.0; Fri, 17 Mar 2017 12:04:39 -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=7NCiO3Ty947ZNmN0FQs3FK+WNy6zFsuAFiRhfJwptjg=; b=pLeQtrXRhZtxFH39RnTyYBqCaWB34I1l7N7t6YPBJnmrIMRB9w0hx22hvcZZEueByJ sxZRSEPpudiwQU5OgHTpe05DHhwpTWdNmQa2U3cQ71Yo+hTO+/N1gWvRaynyY2W+WQhg WEy25dpPooDgw3ozHSsd65cUJ40i1bNPh6hQGxym1yiNMH0vp27314Okl32Khp9sBhwx eqqfrNoWEUmwaHUyAi5ffaycwxNicgcoMmyo/bgN7GUjwdv+ObXCjlZv+LwAGq6XynLS UXWBqGO+PZr5R73b3S0TZi52NtaF6Q1s+NbBzPjA3hJOFcJ6Nl4xUWUG0p6ZcTK2AASY P+sw==
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=7NCiO3Ty947ZNmN0FQs3FK+WNy6zFsuAFiRhfJwptjg=; b=C65zv9bBOguGBJIxJ9PFFvWCj1vSRHeftlo9Kbk8rryIMHz/ncLYG86qvtiUV1c4by rOrJhzipkQBwP2ww/6Bp/sr4hjiKo7RqtCDSDU033xHrn5E9Okml6wceskzOzaS1eDzK RNfNk0gaSaMgDM9NvbyE7EBU9gddWHYBABiHimEXwQLEJovXdmq8tdzHksIHKaHuDiVK uiDfhCao4b1xt7j0oEECVEUxwV13/eUqDKqe7TZ6kQpPoAE2AcX2ll6OEYRl8IxqPvRZ qVJJEZIzI2V5jFuQTW8JSOFZ60x6aoms3Nq0cYXEzeznrKKDfhETTV1KcMushKKa4zIQ vtoQ==
X-Gm-Message-State: AFeK/H0uNjgtZLeMbeP+f/cb6f6gJBOKO0pZJN8QxGRNvfEo9M/eN/kHN2HOeveJAzk7e4PFlyIQ4SKLs3stNQ==
X-Received: by 10.28.30.79 with SMTP id e76mr4142974wme.96.1489777478237; Fri, 17 Mar 2017 12:04:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.145.69 with HTTP; Fri, 17 Mar 2017 12:04:37 -0700 (PDT)
In-Reply-To: <36d3cf47-1d22-4118-96fd-e5e141f73e3f@Spark>
References: <CAG4d1reSNUyDZwUN1tB4zJAJcfs40618_x5DpFofr99cQc3B0g@mail.gmail.com> <43be9b6ac3fa41708303a2a352360ab4@XCH-ALN-001.cisco.com> <CAG4d1reoNrr3hz7cw3CiXy2x9-mzERKxQ0rAXeqmQpgmQDMZ2w@mail.gmail.com> <ab82a1390bb84212a2c0ba7a6488b8ce@XCH-ALN-001.cisco.com> <36d3cf47-1d22-4118-96fd-e5e141f73e3f@Spark>
From: Alia Atlas <akatlas@gmail.com>
Date: Fri, 17 Mar 2017 15:04:37 -0400
Message-ID: <CAG4d1rd0R=kQn07VgZBaaUhWBULP6YBjr4DdVOfdD9dcnm4JxQ@mail.gmail.com>
To: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "draft-ietf-isis-mi-bis@ietf.org" <draft-ietf-isis-mi-bis@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Content-Type: multipart/alternative; boundary=001a114b2de46288c0054af1d95e
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/URUWcMwOkFYJBgTd6ygQ4UI6BVY>
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 19:04:44 -0000

Hi Alexander,

On Fri, Mar 17, 2017 at 2:40 PM, Alexander Okonnikov <
alexander.okonnikov@gmail.com> wrote:

> Hi Alia and authors,
>
> Regarding point 2): This was root of my confusion and reason for
> submitting Errata ID #4521. Per my understanding a IS-IS circuit is a
> representaion of layer 2 link for IS-IS, and not a physical circuit itself.
> For mentioning type of physical media ISO 10589:2002 has another term
> subnetwork. Early versions of draft-ietf-isis-mi used term "network" (up to
> -04), which was replaced by "circuit" later. In my mind, term "circuit"
> creates ambiguity. From IS-IS point of view regular P2P circuit and
> P2PoverLAN circuit are both P2P circuits. May be it is better to create
> dedicated section for P2PoverLAN "circuits" to avoid confusion.
>

A subsection in 2.6.1 that clarifies it is for point-to-point over
broadcast would help clarify that sec 2.6.1 is intended to apply rather
than sec 2.6.2.



> Errata ID #4520 was not incorporated fully. Info regarding AllIS MAC was
> added, but -bis still clarifies usage of standard MACs (for standard
> instance) and new ones (for non-zero instances) only for IIHs in P2PoverLAN
> mode. I.e. the draft doesn't specify which MACs should be used for SNPs and
> LSPs in that mode. From current text we can conclude that for standard
> instance addresses AllL1IS and AllL2IS could be used on P2PoverLAN. But
> AllIS could be used as well, and not only for IIH. That is why the errata
> mentions "PDU", rather than "IIH".
>

In Sec 2.6.1, I see the following:

" When sending SNPs, LSPs, and LAN IIHs for the standard instance (IID

   #0) an MI-RTR will use the AllL1IS and AllL2IS ISIS MAC layer
   addresses (as defined in [ISO10589]) as the destination address.
   When sending SNPs, LSPs, and LAN IIHs for any non-zero IID an MI-RTR
   will use one of two new dedicated layer 2 multicast addresses
   (AllL1MI-ISs or AllL2MI- IS) as the destination address.  These
   addresses are specified in Section 6.

   When operating in point-to-point mode on a broadcast circuit
   [RFC5309], an MI-RTR will use AllL1IS, AllL2IS, or AllIS MAC-layer
   address when sending point-to-point IIHs associated with the standard
   instance.  When sending point-to-point IIHs for a non-zero IID an MI-
   RTR MUST use one of the two new multicast addresses (AllL1MI-ISs or
   AllL2MI- IS) as the destination address (either address will do).
"

This could be cleaned up a bit.

Alia


> Thank you.
>
> Alexander
>
> On 17 марта 2017 г., 21:39 +0300, Les Ginsberg (ginsberg) <
> ginsberg@cisco.com>gt;, 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.*
>
> ??
>
>
>
> 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
>
>
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
>
>