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

Alexander Okonnikov <alexander.okonnikov@gmail.com> Fri, 17 March 2017 18:41 UTC

Return-Path: <alexander.okonnikov@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 5D59D128AB0; Fri, 17 Mar 2017 11:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 XtBKpkfpNxyq; Fri, 17 Mar 2017 11:41:22 -0700 (PDT)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 F0E361273E2; Fri, 17 Mar 2017 11:41:21 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id z15so36695949lfd.1; Fri, 17 Mar 2017 11:41:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=PWCrVL177mWZ2ehkw1cU6bjv100DgLbLdczuvR7SOD4=; b=tAGN64I8tZQapc0D6SUFKzYjH819HeQYf78FN3RF+x0itXdgI1szV/KQQn29wcU96R kBy76lGWmLeKcO5ulDjx7rL25Xey7YDa/qLn6snYkEpqn0afaUXK8WtussA3V2V8oAEc UX2F9NSnDs1MPKInjDEoJLAvwUpRuOD6Q4Iu7ZW4gy5GEXMdxf86G4JgRzzacqhbc4Qe rDRsK6H6wjCE+ZFDM4t2zSU4Ae5KYI8gj3gg/+w5VH+IzSfBQZD+PpYLeNyf2jUoIP8G 7SMHd4nGV1sMo6/C7ktvXvkPTiEA4mVrLgkDhQrtYK/Gv6zvqZ/5a189zFZlyyGtxzMd YJOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=PWCrVL177mWZ2ehkw1cU6bjv100DgLbLdczuvR7SOD4=; b=Ic7+oBhdF74YxgskOMR+NXbQ6AUHTynmFKN9OVIzC7tfw2+ERVCuPACmcEr0iUuCpr Q1RZ+MJXQxdaPM/hPuH6cZvUFwqR+s1YFpPBui9ROtaJM6ottPd3Io3FF6sNVmFhRAGi dswiF1Ib7Yvu2eftnkgVoqGCZ06005uH0m9NJeGCpwVnAtSXq4TYdLU0visy7b645TIe UJHXtODQ8YBkMH7I9zt7shBl19HU/bKJvVPRMgUgmiPCboc9EYPHJ6r3I/1dT0R/Tvwf inAqCrPb7gAAzxUVRK64q18oRL9icuGpgKiFZoU5miItUbNKznh+635h63jQ8j3t50wL 3XNg==
X-Gm-Message-State: AFeK/H1SXX4J/XHNix6+FUy1O/7wrIGeOQsCK+ZEff3eXTsaVMP06QGLPtQFmGxo2AoGzg==
X-Received: by 10.25.56.1 with SMTP id f1mr5035520lfa.83.1489776080220; Fri, 17 Mar 2017 11:41:20 -0700 (PDT)
Received: from [10.0.1.2] ([109.248.36.241]) by smtp.gmail.com with ESMTPSA id e13sm1630483lfb.14.2017.03.17.11.41.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 11:41:19 -0700 (PDT)
Date: Fri, 17 Mar 2017 21:40:25 +0300
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
To: Alia Atlas <akatlas@gmail.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "draft-ietf-isis-mi-bis@ietf.org" <draft-ietf-isis-mi-bis@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Message-ID: <36d3cf47-1d22-4118-96fd-e5e141f73e3f@Spark>
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>
X-Readdle-Message-ID: 36d3cf47-1d22-4118-96fd-e5e141f73e3f@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="58cc2dcc_6b8b4567_f063"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/xRkOvoSotZGHt2LptVBFLoyOjxU>
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:41:25 -0000

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.

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

Thank you.

Alexander

On 17 марта 2017 г., 21:39 +0300, 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.
> ??
>
> > 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