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).
From: Dino Farinacci [mailto:farina...@gmail.com]
Sent: Wednesday, October 12, 2016 12:28 PM
To: Peter Yee; suresh.krish...@ericsson.com
Cc: draft-ietf-lisp-l...@ietf.org; email@example.com; i...@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
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
> 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.
Gen-art mailing list