Re: [Isis-wg] Requesting WG adoption of draft-baker-ipv6-isis-dst-src-routing-06

Tony Przygienda <tonysietf@gmail.com> Fri, 28 October 2016 02:03 UTC

Return-Path: <tonysietf@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 C05FA1294FE for <isis-wg@ietfa.amsl.com>; Thu, 27 Oct 2016 19:03:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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] 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 kb1I4f1-YP3e for <isis-wg@ietfa.amsl.com>; Thu, 27 Oct 2016 19:03:24 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 7032E129440 for <isis-wg@ietf.org>; Thu, 27 Oct 2016 19:03:24 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id y2so91734646oie.0 for <isis-wg@ietf.org>; Thu, 27 Oct 2016 19:03:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fm01rJEbCilD020pD5G/VJMvkRdfVKcTET0FdQLC5dQ=; b=hgRfOt/yqHBykEyVgQdgtlwdC8ppz874FGJYuUndmqZ/7naOJV7njGGC/tyvo46UX6 zlpqWWKbI5brFZNXrJ21wePdK/IsnCrRQlS8B5PFJ6J/HJfBRJV6SlUDvg5D7JuCa8I6 9B2tFJAAHBi5VgPht4/r1M/HXz4g0Kh+niPZGTWcuTIrviX/Op+T7hR+lmBKSLuJCWvq yDm6IpO7Jh/9xf46226nzoyfMukyynTlo0GsKKof6WXo9s7htGU5vfuz6b7GiJOuqNtj +RvXajVwhkEuFqajqzwZf7d+8kjf1awCaJjvYwd7XIJu/KMNlBFrHT+tWcp9jmdywCJe 1cfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fm01rJEbCilD020pD5G/VJMvkRdfVKcTET0FdQLC5dQ=; b=PTUxwf7oxG0PR+UczSCLphuK+b6J7gq2JVLX0e1mZL14eR5XM4Oz5DsMvT5/LKV9I1 EuTj6pi7naT7emHR1prC+P0vBykCaDURkvVPJBXvQADSpuiyfhh36EV7AXnM7ImI6gsI dCnVLrOS++/P2GyCMLh78aGdsj9vutahPrwLtI8lJC+6ZRBh+lKnuyebMzBPUxdoyX3O WOiBzRH+D/MZew9Y/igJbHTYzmaWna8pxui4GRAncN4+ZI4BzJceRavZORWZj79DSaEK i70HPye7lOL5j5OFzEhwygx0n2avmqtNqy/gxS0vLjTG5U6vfNz3r+f3gHnwQ/S+/i6L FIsw==
X-Gm-Message-State: ABUngvfhT1M67/sTRpP3HAB+78MIj88di1otfTl2rNgF+EiI+ZqV8STK5/vDRMst7u+1Mom1gH1amtz/7mMmBw==
X-Received: by 10.107.36.144 with SMTP id k138mr8674155iok.201.1477620203783; Thu, 27 Oct 2016 19:03:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.6.214 with HTTP; Thu, 27 Oct 2016 19:02:43 -0700 (PDT)
In-Reply-To: <20161027141223.GG639535@eidolon>
References: <20161018213247.GQ639535@eidolon> <MWHPR05MB28295C2BB382A538C34C7106A9AA0@MWHPR05MB2829.namprd05.prod.outlook.com> <20161027141223.GG639535@eidolon>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Thu, 27 Oct 2016 19:02:43 -0700
Message-ID: <CA+wi2hO_UmBLS=7Ka5i_fiDCTNPb+rnWUCTud5=sqO1rSxp8sQ@mail.gmail.com>
To: David Lamparter <equinox@diac24.net>
Content-Type: multipart/alternative; boundary=001a11402d105c0c9d053fe343d6
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/V66KUJaHu7Vtla-tr9SFAL59PUI>
Cc: "isis-chairs@tools.ietf.org" <isis-chairs@tools.ietf.org>, "isis-wg@ietf.org list \(isis-wg@ietf.org\)" <isis-wg@ietf.org>, "FredBaker.IETF@gmail.com" <FredBaker.IETF@gmail.com>
Subject: Re: [Isis-wg] Requesting WG adoption of draft-baker-ipv6-isis-dst-src-routing-06
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.17
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, 28 Oct 2016 02:03:27 -0000

On Thu, Oct 27, 2016 at 7:12 AM, David Lamparter <equinox@diac24.net> wrote:

> Hi Chris,
>
> On Thu, Oct 27, 2016 at 12:51:19PM +0000, Chris Bowers wrote:
> > I have two main comments/questions on this.
>
> Useful feedback, Thanks!
>
> > 1)  If I understand correctly, one reason to use existing multi-topology
> routing mechanisms for
> > this is the requirement to support deployments where only a partial
> subset of
> > routers support source address dependent routing.  Ideally, this would
> allow an enterprise site to
> > start by upgrading a subset of routers to support SADR, starting at the
> site egress routers.
>
> Yes, that's the intent.
>
> > However, this statement from section 2.3 seems to imply that all of the
> routers in the enterprise network
> > would need to support multi-topology even if they don't support SADR.
>
> No, non-MT routers would be ignorant of the MT information and would not
> see any of the SADR routes -- which is exactly the intended goal.  I'll
> update the draft to say this very clearly.
>
> >    As this compatibility mechanism is not considered optional, M-ISIS
> >    MUST therefore be implemented for supporting the protocol outlined in
> >    this document.  Even installations that previously used only MTID 0
> >    (i.e.  no M-ISIS) would need to start using MTID TBD-MT0.
>
> Ah, I see where I misworded that.  It needs to say "need to start using
> MTID TBD-MT0 *for transporting SADR routes*".
>
> Sidenote:  at some point, the draft allowed non-usage of MT for
> greenfield setups (all routers with SADR support and everything in zero
> MTID / no M-ISIS used at all), with homenet in mind for that.  I'm now
> thinking that was a stupid idea.  However, there might be leftover weird
> wording in the draft from that.
>


My first comment a good while ago on the mike when you were showing your
first
proposals was that you'll on a slippery slope to
redo MT in topology #0 ;-)  Stupid is too strong a word, it's simply one of
those
problems that looks like a "small addition" needed initially until it sucks
you
treacherously underwater.

I favor adoption as well as an elegant application of MT with the following
necessary fixes ;-)


a) you prescribe 2 different things in the draft ;-)

   a.1  you want to forklift all the routers in section 2.3. In fact,
MT-ISIS has
        been proposed to prevent such fork-lifting need. Forklifting is
sufficient
        but not necessary as you observe later in the "correctness
considerations".
   a.2  in "correctness considerations" you allow to mix the routers which
is correct
        but the logical chain doesn't hold completely.
        First "axiom" is clear (i.e. forwarding lookup). The second
        "pilar"  is confused by

      *"If, for case (b1), the system knows of the existence of a more*
* specific D/S route, but cannot calculate a valid path, it may*
* either apply non-D/S routing (i.e. not install any route) or*
* discard the packet (i.e. install a discard route). The next hop*
* will either be a non-D/S system, or a D/S system with the same*
* link-state information (and thus again unable to calculate a valid*
* path -- or, more specifically, won't calculate a path that*
* includes the previous router)."*

      That seems to contradict *"**Packets will transit into D/S
routing but not out of it"*


      In short, with your axiom (prefer routes with source match over 0/0
source entry)
      you have two choices for the 2nd axiom (both lead to correct routing
      but exclude each other). The reason is that you either "enter
semantically
      richer topology and never leave" _OR_ "exit semantically
richer semantics and
      never enter it again". Less formally that translates into

      Either

      a) a packet may enter from non D/S into D/S and any D/S MUST NOT
         forward it to a non D/S next-hop, i.e. you can't install default
topology
         entries into FIB as "union". This holds EVEN when you received the
         packet from a D/S neighbor since the packet MUST NOT jump out into
         the non-D/S topo again (it may have came from here upstream).
Otherwise
         you'll find looping scenarios

      or

      b) a packet may exit from D/S into non-D/S, i.e. no source-specific
FIB match
         is found and you match on 0/0 source (topology #0). Once it's out
in the
         non-DS world, it MUST stay there, i.e. you must not as D/S router
advertise
         topology #0 information since a non-DS router may use that to jump
into
         the D/S again not understanding it's doing it.

      Again, in short you either enter D/S once and only once and never
leave D/S or you
      exit D/S once and only once and never enter D/S again.


b) section 3.1: I would explain what is the multiplicity of this TLV and I
expect it
   to be 1 and only 1. Omitting it will collide with MTID#0 and having two
has no
   semantics (unless specified).


--- tony