Re: [RTG-DIR] Routing directorate QA review of draft-ietf-i2rs-yang-l3-topology

Tony Przygienda <tonysietf@gmail.com> Fri, 06 May 2016 22:09 UTC

Return-Path: <tonysietf@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241D712D133 for <rtg-dir@ietfa.amsl.com>; Fri, 6 May 2016 15:09:14 -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 rB-TUFtVU6Ck for <rtg-dir@ietfa.amsl.com>; Fri, 6 May 2016 15:09:11 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (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 B0ED112D12A for <rtg-dir@ietf.org>; Fri, 6 May 2016 15:09:11 -0700 (PDT)
Received: by mail-ig0-x22a.google.com with SMTP id u10so58408733igr.1 for <rtg-dir@ietf.org>; Fri, 06 May 2016 15:09:11 -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=ooFOo/AVlNSWRWCVA3R5jq5dgiEJu/EGHjQug4wsiQ8=; b=hSFL6+M2JS8UKhTqzpl7XDwBJru6VrB8/xx3D1quFzDn2tivrUrX2/D7iskMW2rTqs jt4tsc0AaqzXkKbPrxMUoL1/QMwnIybjZv79Oy1yXDa+kK6EmivqiDdvbCtw9ZaQcOCJ F3s70C0WeGHINgqWDKMtL0UeCU2KZN7rtKsBCKW8yQ0kAwhTn6yfCRHiqFXoCnmoIMlA oMKnpbUjAjhihuEq2oYPg+DykkDB6VyKvqHSVTRLQaW3OwoPXmW7jiX9AqxAlXhO33Hd D7G1GmTMrPeuuiYAgd6oXJ61XPm4myq7npUvzrnTKA7daa0nPYgNXjvsLajRK1yvLOF2 ZNPw==
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=ooFOo/AVlNSWRWCVA3R5jq5dgiEJu/EGHjQug4wsiQ8=; b=EtCqqsoMuEnKcWkkI0kHcGepFJDAu5cqHTPyn31e1AzkZoEL2rCwvxYNkIEl3psXR4 uZbN9voMHQ867uOkE/N9jCxlo51i96P48eZbTQPnutAklq5b9tFhMfpVObImDq3vdEWv SkkAdOWClxwGXP0X2Q6V9UyjkwYXOCrQFXyu00D+WUVplfK/cLfFFotIju9Q4xvAas2i 6rONxSGjt1iCZH0DRJfir/lEaPZcJIqfZs0u0CZ7SnKBOlM6m57cBdfrRL1d7u2BVcqx sWUJuqt95JfbTR17R7Wc/CUY9+CO1LC1rj5gAAydSK7JkfUhD1Put07uIShHNj3QhVJi sT5Q==
X-Gm-Message-State: AOPr4FX7ECRnDtmVmSf/cUfHYjfJcP4vdU3EQ1iRljhuQMolurgmqjOJLB1hyj30+cWU/ryBMUjku9vJ0SVa/g==
X-Received: by 10.50.29.45 with SMTP id g13mr13137215igh.93.1462572550957; Fri, 06 May 2016 15:09:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.15.93 with HTTP; Fri, 6 May 2016 15:08:31 -0700 (PDT)
In-Reply-To: <CA+wi2hNnGuqUNC67oiZ8gVSKHz29FPKOB38fosh5qn5oZi_UxQ@mail.gmail.com>
References: <eaca4731fbcca8c5635aea907595f5ff@zeta2.ch> <CA+wi2hNnGuqUNC67oiZ8gVSKHz29FPKOB38fosh5qn5oZi_UxQ@mail.gmail.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Fri, 6 May 2016 15:08:31 -0700
Message-ID: <CA+wi2hOOGkN0x46U4hbkLkq3g1f0uW9HjEGrrwWNcoafGbMK1g@mail.gmail.com>
To: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>, Jon Hudson <jon.hudson@gmail.com>, Susan Hares <shares@ndzh.com>, zhang.xian@huawei.com
Content-Type: multipart/alternative; boundary=047d7bd7528c5bb099053233b5d7
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/U1wzsfRkHXadYdR3sgxlVo3cwpk>
Cc: rtg-dir@ietf.org
Subject: Re: [RTG-DIR] Routing directorate QA review of draft-ietf-i2rs-yang-l3-topology
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 May 2016 22:09:14 -0000

I was requested as part of the routing directorate to provide a QA review
for  draft-ietf-i2rs-yang-l3-topology-01. I give my input assuming the
wider angle of the complete yang-topology work in i2rs first since this
specific draft is just an extension of it. I follow this up by examples of
detailed technical concerns/work items I found.


To start off with a wider angle:



Overall, the draft seems a bit hard to follow as far as the use-case
correlation goes in several aspects (I admit there are valid use-cases for
this draft but between the i2rs-usecase and l3-topology drafts they are not
easy to detect/understand). In more detail:

i)      draft-ietf-i2rs-usecase-reqs-summary-02 provides no clear, hard
rationale for having an l3-topology draft in i2rs in this form IMO. There
are some requirements about “IGP node failure for faster detection” but
l3-topology draft does not cover any clear use-cases in section 6 as
claimed, neither in e.g. Section 6.1 (VC) nor 6.3 (where e.g. Topo-REQ-01
seems to have been miswritten?). Further, the model does not include IGP
low level elements like LSAs, statistics or any of the things required for
the PCE/SFC use cases (such as protection types, prefixes, admin groups) or
ultimately things desired in section 4 of
draft-ietf-i2rs-usecase-reqs-summary-02. The draft  omits so much
information that it can be used to maybe ‘high-level share’ topology info
but not for computations relating to detailed IGP IGP forwarding
computation decisions (e.g. overload bits or capabilities are omitted). A
clear, detailed use example introduced in the draft could go a long way to
improve things.  In comparison, when looking @ the i2rs drafts related to
it, I cannot clearly delineate WHICH type of information is supposed to be
contained in the topology draft and which in auto drafts. To give a
specific example the draft teas-te-topology seems to be in an excellent
shape and have a clear purpose in life, draft-i2rs-yang-l3 and
draft-i2rs-yang-l2 leave the impression of being unclear in scope and
intended use-cases.

ii)     it would be beneficial to mention that BGP-LS is providing the
superset of the information contained in this draft (albeit not as a
“model”) in a standardized fashion already. RFC 7752 has been published on
standards track and is being deployed @ a quick rate. IMO the l3-topology
draft could do a better job delineating the use-cases it will serve from
the ones covered by BGP-LS already or describes the expected overlap.

iii)  For the suggested models to work well a strong support for Yang push
is needed. The network topology draft is mentioning Yang push and obviously
restconf exists but both were not seeing the necessary amount of
contributions in IETF or implementations IMO.


Smaller angle (examples of detailed technical concerns):


I see tons of information missing in the draft which IGPs carry and need to
be conveyed to understand WHAT IGPs actually do and I don’t see a clear
indications whether it’s intentional or will be remedied and to which
extent (again, without a clear use case correlation it’s hard to decide
WHAT needs to be in). To give couple random examples:

i)       Prefix metrics: where is I/E which is very important, otherwise
the metrics are not comparable?  I know that “flags” can be claimed to
cover everything in the future but the flags need to be described for the
implementations to interoperate.

ii)      I do not find things like overload bits, capabilities & so on that
determine how the information is being used and whether e.g. the node/link
even participates in control and/or data plane.

iii)      A node can be ABR (in multiple areas) and ASBR @ same time while
it can be only one of 1 or 2 or 1-2 in ISIS (historically expressed like
this while it could be considered as a logical combination of both as
well). The model does not capture that as far I saw. Both things look the
same while ISIS node type should be an enum probably.

iv)       Multi-topology ID in ISIS is 12 bits.

v)       Overload/colors/admin tags/ TE metrics and many other things are
missing while e.g. topology ID is included. Again, the delineation between
TE draft and topology drafts does not seem clear to me.



Overall, I do think that a l3 topology draft is necessary but its purpose
is not explained clearly enough. With that it is non-obvious which
topology/node/link information it needs to ultimately carry. I would
encourage the WG/authors to correlate the draft clearly with use cases and
even better, usage examples and explain why/when BGP-LS will not meet those
use-cases. It will be then necessary to subject the draft to the scrutiny
of OSPF/ISIS experts which will make sure that it contains a set of
information that allows the client of such a model the derivation of
conclusions to meet the  intended use cases. If these models are to
progress successfully and enjoy wide acceptance I recommend a stronger
focus at area director level given to the yang push model work.


thanks

-- tony