[Idr] AD Review: draft-ietf-idr-ls-distribution

Alia Atlas <akatlas@gmail.com> Wed, 18 March 2015 16:43 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B139A1A6FF1 for <idr@ietfa.amsl.com>; Wed, 18 Mar 2015 09:43:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.69
X-Spam-Level:
X-Spam-Status: No, score=-98.69 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, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no
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 73vTd5J5KnDr for <idr@ietfa.amsl.com>; Wed, 18 Mar 2015 09:43:18 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 07F8A1A1BF5 for <idr@ietf.org>; Wed, 18 Mar 2015 09:43:18 -0700 (PDT)
Received: by oifl3 with SMTP id l3so11296354oif.0 for <idr@ietf.org>; Wed, 18 Mar 2015 09:43:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=9Kv4SQGOdn5QKIqZWz4obQdEthvBOcvkUxCsXAvbpdo=; b=JZjAgISVvrScdHPEzY9MUpUGlQMQZjKIKluNT3prcOZQzq+4wLMR9hqfS3Guuo8bC6 w2bD36VSjFFwqjFH0RtSS9CAgmk4EZL6R8If3hBvbedvg4nRuVLhkt0vh6zPl+mJjeXj ANdeIBuoVLqIOFZrx67KdzuZd8So0ALqxHX3PezIVUqET+l4LJFfM1LvincvrOluTwy9 UlQ3EMsWnYcChTS/A5gulsL6OGmDs5WhnoSIB8UAHBmUm1Gtamja1+AD2PN8Ua3BkRNL P8saPlWJEZRJw3dGFFOM+k2qnQJmXfmvPGeZcTIMi+iOjbmB+Db/mMpE7vS0tMduwF6s mbBw==
MIME-Version: 1.0
X-Received: by 10.182.126.40 with SMTP id mv8mr12854478obb.54.1426696997573; Wed, 18 Mar 2015 09:43:17 -0700 (PDT)
Received: by 10.60.44.198 with HTTP; Wed, 18 Mar 2015 09:43:17 -0700 (PDT)
Date: Wed, 18 Mar 2015 12:43:17 -0400
Message-ID: <CAG4d1rdb=EDRpKrtGNkLKgkLwNTx-v5VGe7MGpF1ig-8Tkri9g@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: "draft-ietf-idr-ls-distribution@tools.ietf.org" <draft-ietf-idr-ls-distribution@tools.ietf.org>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary=e89a8fb1f764be1971051192c71f
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/P7aOPC400abSSVP0TUKraaek_1A>
Subject: [Idr] AD Review: draft-ietf-idr-ls-distribution
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Mar 2015 16:43:20 -0000

As is customary upon receiving a publication request, I have done my AD
review of draft-ietf-idr-ls-distribution.  First, thanks for the hard work
on this very useful and non-trivial specification.  Second, I have found a
number of clarifications and issues that I would like to see resolved in
the draft.

I will start an IETF Last Call so that you can get additional comments in
parallel.  Because of the upcoming IETF, I expect this to run longer -
ending April 8.


1) In Sec 3.2, 3rd paragraph last sentence, it says:
"This is done as specified in [RFC4760], by using capability code 1
(multi-protocol BGP), with an AFI 16388 / SAFI 71 and AFI 16388 / SAFI TBD
for the VPN flavor."   Could you please turn this into non-colloquial
language with clear requirements language?  Can one support "the VPN
flavor" but not the regular?

2) On p. 9, the Route Distinguisher is introduced and its length is
included - but no reference is given nor length specified.  Could you
please provide both?

3) In Sec 3.2.1, second paragraph, it says "We use Autonomous System (AS)
Number and BGP-LS Identifier (Paragraph 2) in order to disambiguate the
Router-IDs, as described in Section 3.2.1.1."
I suspect that "Paragraph 2" is intended to refer to the last paragraph on
p. 11 - but that isn't a clear way to reference it; also the Identifier is
not referred to as a "BGP-LS Identifier" but merely an Identifier.  Also,
instead of "we" perhaps "BGP-LS".

4) In Sec 3.2.2, I see that link descriptors are actually only a
unidirectional representation.  Could you please mention this when the link
NLRI is introduced?

5) In the NLRI format, I see a 64 bit identifier. From the discussion (last
paragraph in p. 11), it looks like this 64-bit identifier is intended to be
the 5-bit "Routing Universe Identifier" which is supposed to indicate the
protocol plus routing instance???

5) In Sec 3.2.1.4: I see the OSPF Area-ID listed.  How are IS-IS levels
handled?  I see the Node Attribute TLV (1027) but this seems to require
that a link would have to have its remote and local nodes looked up to find
the associated IS-IS Area Identifier.  What would be actually really useful
is to describe, in the introduction, the different handling for IS-IS and
OSPF in the encapsulations and why they differ.

6) In Sec 3.2.2  3rd from last paragraph:  Can both IPv4 AND IPv6 addresses
both be included in the link descriptor?  Presumably the same logic that
prevents the link local/remote identifiers from being included would
apply?  Also, why are the neighbor addresses included for the Link
Descriptor when the remote node's descriptor should already be in the
Remote Node Descriptor?

7) In Sec 3.2.3.1:  It says "The OSPF Route Type field values are defined
in the OSPF protocol, and can be one of the following".  Could you please
add a reference to which version of OSPF and what field you are
describing?  I suspect it is the LSA types and they are different values
between OSPFv2 and OSPFv3.  This section could benefit from some clarity.

8) In Sec 3.3.1.2:  Please add a reference and describe what an "Area
Identifier (variable)" is.

9) Sec 3.3.1.5:  I like the idea of this - but an example or two in terms
of encoding/parsing would be useful.  You have a couple pointers - but it
could use another level of explanation.

10) Sec 3.3.2.2:  I am not clear what the rationale for deciding what
protocols to include here is.  For instance, is mLDP considered a different
protocol or a subset of LDP?  I would like to see a short paragraph
discussing how this information might be used or what criteria would be
applied to decide if another protocol should be added.  8 bits is a pretty
small space...

11) Sec 3.3.2.3:  " If a source protocol (e.g. IS-IS) does not support a
Metric width of 32 bits then the high order octet MUST be set to zero."
Surely you mean that if the source protocol supports a metric width shorter
than 32 bits, then the metric is placed in the bottom of the word and the
high order bits from the supported metric width to 32 MUST be set to 0.  As
written, it assumes that any source protocol that doesn't support 32 bits
of metric must support exactly 24 bits.

12) Sec 3.3.2.5:  Please correct the sentence that claims "Note that there
is no SRLG TLV in OSPF-TE".  A simple browsing in the IANA registry  (
http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xhtml#subtlv2
) clearly shows it defined:
16Shared Risk Link Group (variable)[RFC4203 <http://www.iana.org/go/rfc4203>
]
13) Sec 3.3.3.1:  How large are the bit fields that are mashed together
from IS-IS and OSPF to form the IGP Flags TLV?  Can you please add some
guidance on when new flags should be allocated?

14) Sec 3.3.3.2 and Sec 3.3.3.3:  Please add a reference for OSPF
TAGs.  draft-acee-ospf-admin-tags-01
seems to be the corresponding one.  I think that the reference can be
Informational.

15) Sec 3.3.3.4:  The reference to RFC5305 is, I presume to Section 4.
That would be useful to clarify since it isn't easy to find.  Similarly,
where does the information come from in OSPF?  Could you please add a
reference?

16) Sec 3.5:  Can you please provide more guidance here around what
Protocol-ID to use for inter-AS links - particularly if they are not in the
IGP?  Are there any issues around the Protocol-ID implying the format for
data that an inter-AS link might have?

17) Sec 5 IANA Considerations:  There are several fields (i.e. MPLS
protocols, IGP Flags, etc) that are not included in the IANA
Considerations.  The authors and document shepherd should go through and
describe how each field that is not managed by IANA would have additional
values added - or whether that isn't expected and why.

18) Sec 6.2.1:  I assume that by "does not mandate", the authors mean
"we're not doing it now"?  It's clearly absurd and ludicrous to think that
BGP-LS wouldn't need some type of extensions - whether that is
topology-related YANG models or something else.  Please figure out what you
want to say other than "someone else's problem" and put it in here.

Thanks again for the hard work so far,
Alia