RE: Gen-ART LC review of draft-ietf-lisp-lcaf-16

"Peter Yee" <peter@akayla.com> Wed, 12 October 2016 23:56 UTC

Return-Path: <peter@akayla.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D164E129654 for <ietf@ietfa.amsl.com>; Wed, 12 Oct 2016 16:56:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=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 t9afUTyAWf5h for <ietf@ietfa.amsl.com>; Wed, 12 Oct 2016 16:56:09 -0700 (PDT)
Received: from p3plsmtpa06-09.prod.phx3.secureserver.net (p3plsmtpa06-09.prod.phx3.secureserver.net [173.201.192.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F22C129632 for <ietf@ietf.org>; Wed, 12 Oct 2016 16:56:09 -0700 (PDT)
Received: from spectre ([173.8.184.78]) by :SMTPAUTH: with SMTP id uTN4b2PACYusVuTN4bJoVb; Wed, 12 Oct 2016 16:55:38 -0700
From: Peter Yee <peter@akayla.com>
To: 'Dino Farinacci' <farinacci@gmail.com>
References: <00a701d2234d$e20f6780$a62e3680$@akayla.com> <BC6735C8-EA9C-4006-B6DB-2A6AF245F2E0@gmail.com>
In-Reply-To: <BC6735C8-EA9C-4006-B6DB-2A6AF245F2E0@gmail.com>
Subject: RE: Gen-ART LC review of draft-ietf-lisp-lcaf-16
Date: Wed, 12 Oct 2016 16:55:41 -0700
Message-ID: <00fc01d224e4$23cd3480$6b679d80$@akayla.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIO1AvmG9YLEZO35RV09unuqnb+HgHws8MpoByUNvA=
Content-Language: en-us
X-CMAE-Envelope: MS4wfDNjAsPBHuOTbAh0LiCnpI0AkOAWjqZdoQpN7Dtgb66jenvPwutjv+zRN0RXpss7I24sCntoGYodmM8Hgsw/V3rO4gHkVPXY2iC2ckUXpcLkGxqXn1uV iL6KB3N4nhJ6WPom+KVpT1LoC9siiVbYADIG3NKvbFaBPoKjb206WM4gGZOQju0xUDAPLIkRSTsXz7WW3b9LFix0YYYAIsGoHrKQPhtxpquHbFQf/o2xeFr2 twcAN1CU0fyiAnSZf/bJEg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/BbZzXzULhsDoM-Za6gFEdgNSy3o>
Cc: gen-art@ietf.org, draft-ietf-lisp-lcaf@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Oct 2016 23:56:12 -0000

Dino,

	Thanks for considering my comments.

	On the basis that each RTR RLOC can be from a different address family, than I would say that the number of RTRs cannot be determined from the LCAF Length field.  The length alone would not tell you the breakdown of RTR RLOCs between the address families, so the only way to tell how many RTR RLOCs are present is to parse through them until the length of the AFI/address combinations seen equals the Length value.  For example, 3 IPv4 RTR RLOCs will have the same length (3 x (2 + 4)) as one IPv6 RTR RLOC (2 + 16).  I'd simply strike the relevant sentence in the RTR RLOC definition (2nd to last sentence).

		Kind regards,
		-Peter

-----Original Message-----
From: Dino Farinacci [mailto:farinacci@gmail.com] 
Sent: Wednesday, October 12, 2016 12:28 PM
To: Peter Yee; suresh.krishnan@ericsson.com
Cc: draft-ietf-lisp-lcaf@ietf.org; gen-art@ietf.org; ietf@ietf.org
Subject: Re: Gen-ART LC review of draft-ietf-lisp-lcaf-16

I am sending one reply to both commenters. Thanks Peter and Suresh for your comments. 

I made changes for all of Suresh’s comments. I made changes for all of Peter’s comments accept for the responses below. Note many of your comments were fixed in a later draft.

I have submitted a -17 version. See diff file enclosed.

> Page 13, RTR RLOC Address definition, 4th sentence: The ability to 
> determine

> the number of RTRs encoded by the value of LCAF length implies a 
> single value for AFI = x is required.  If so, why not only use one 
> AFI=x value rather than repeating it for each address?  And if there 
> can be different AFI = x value, then the number of RTRs that are 
> encoded cannot be determined without parsing through each AFI/address pair.

Because each RTR can be from a different address family.

Thanks again,
Dino