Hi Bill,
Thanks for the review. Let me comment quickly. Will do the fixups
after Sheng has made determinations.
Inline...
On Tue, Oct 24, 2017 at 10:35:56PM -0400, William Atwood wrote:
> Hello,
>
> These are my technical comments on this draft, for the first 32 pages.
> Given the length of the document, I do not expect to be able to finish
> it by October 28, so I second Brian's request for additional time.
>
> Bill
>
> 1) The definition of "ANI" in Section 2 says that it includes ACP, BRSKI
> and GRASP. The statement of Requirements in Section 4 says:
>
> "ACP4: The ACP MUST be generic. ... It MUST NOT be tied to a particular
> application or transport protocol."
>
> These two statements are in conflict, because the ANI as defined in this
> document clearly depends on GRASP.
Actually, the ACP does depend on GRASP too (eg: to find neighbors,
and also because it defines ACP-GRasp to be core part of ACP services). So
no need to bring in ANI ;-)
I did respond to this point somewhere deep inside of one of the long reviews
from Brian or Sheng i think, so let me repeat:
AFAIK, the origin of ACP4 was in the early history of ANIMA: We first
brainstormed how we could build out ASA solely using one standardized
transport/session layer protocol and in result, we could make the
underlying infrastructure (ANI) very simple. In technical terms, think
how we could have NOT built the ACP as a virtualized IP inband network
but if we would have simply built out GRASP and then ANI was just GRASP,
In the extreme, there would be no IP hop-by-hop forwarding in ACP,
but every unicast communication between two ASA would be hop-by-hop
forwarded by GRASP. No need to build a whole VRF around ACP etc. pp.
In the end we concluded that this was too bold to gain short term
attaction, and i also was worried about performance even for GRASP
unicast if we didn't rely on existing forwarding plane mechanisms such
as end-to-end IP/TCP/TLS. Now if we do get a lot of adoption of ASA
with only GRASP then we can of course bring "ANI-lite" that would potentially
do this.. But first we got to kill a huge lot of legacy.
So thats how ACP4 requirement came along.
I changed in to "application or transport" through the last review,
but i agree that this still does not well explain.
How about "Clients of the ACP MUST NOT be tied..."
^^^^^^^^^^^^^^^
(instead of "It")
> 2) As a specification, Step 4 in Section 5 is terrible. Step 3
> explicitly includes the "for-loop". Step 4 then shifts to the
> perspective of an individual peer relationship, and uses the singular in
> the first sentence. It then shifts again to the plural for the second
> sentence. Suggested text:
>
> "4. For each node in the candidate peer list, it then establishes a
> secure tunnel of the negotiated type. The resulting tunnels are then
> placed into the previously set up VRF. This creates an overlay network
> with hop-by-hop tunnels."
Thanks. Unless there are counterproposals, i will put that into 13.
> 3) In Section 6.1.1, in the comment on "routing-subdomain", it says,
> <<"rsub" is optional and should only be used when its impacts are
> understood.>> Who must do the understanding? What is the test for
> "understanding"? Is this a statement that "rsub" should not be used
> until the WG has done more work, or until the reader has read this
> document 42 times, or ?? For a normative section of this document, this
> is remarkably ambiguous.
In my university in 1988?, every student had to sign the following
statement before he/she got an account: "i hereby declare that i
will not execute commands whose impact i do not understand". The more
i learned of unix then, the more hilarious that statement beame
over time. Every decade i now flip between "that was terrible" and
"we really need to reintroduce this".
Practically speaking:
Before introducing rsub, older versions of ACP had a lot of hand waiving about
subdomains, and open questions how they would tie in with mutual authentication,
addressing and so on. All sounding harmless by using the word
"intent" in many places. So i sat down and tried to figure out how i would
make it work. I think its now implementable. But the primary benefit
i see is only in being able to reduce routing tables, because rsub gives
you multiple ULA prefixes, and you could auto-aggregate those. Only tht
we have not sat down trying to specify a standard auto-aggregation. And
i don't know how difficult that would be. So with that uncertainty in
mind, using rsub now is a bit like starting to use IPv6 when you
have all the IPv4 address space in the world. You are investing
in an uncertain future (don't think 20/20 hindsight ;-)
So... given those more detailled insights, how do you think
we could better warn the user of this option ?
"Benefits of using rsub may depend on future work in enhancing routing
for the ACP" ?
But maybe i am overlooking other possible benefits.
> 4) In Section 6.2.3, para 1, line 3, "must" -> "MUST" (I believe that
> this requirement should be normative.)
There is no 6.2.3 in acp-12 ;-(
> 5) In Section 6.7.2, para 2, line 4, "and not permit" -> "and MUST NOT
> permit" (The implied dependence on the previous "MUST" should be made
> explicit.)
Ok.
>
> 6) In Section 6.8.2, para 2, I was puzzled by the statement that the ACP
> could exist in the absence of any active ACP neighbors, since the ACP is
> only created with the help of a neighbor that is already a member of the
> domain. I then realized that domain membership (and its accompanying
> domain certificate) could be established while a neighbor was active,
> and then the neighbor could vanish. I suggest adding some text to make
> this sequence of events clear. Suggestion: "It is created when the node
> has a domain certificate, and continues to exist even if all of its
> neighbors cease operation."
Ok.
Happy to get similar feedback for the remaining part of the doc ;-)
Cheers
Toerless
>
> On 15/10/2017 4:59 AM, Sheng Jiang wrote:
> > Hi all,
> >
> >
> >
> > This message starts the two-week ANIMA Working Group Last Call to
> > advance draft-ietf-anima-autonomic-control-plane-12, An Autonomic
> > Control Plane (ACP). This document's intended status is Standards Track.
> > At present, there is one IPR file against this document, see below link.
> >
> >
> >
> > https://datatracker.ietf.org/ipr/2407/
> >
> >
> >
> > Please send your comments by October 28th, 2017. If you do not feel
> > this document should advance, please state your reasons why.
> >
> >
> >
> > Sheng JIANG is the assigned document shepherd.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Sheng (co-chair, Toerless who as a co-author stayed neutral on the
> > content side)
> >
> >
> >
> >
> >
> > _______________________________________________
> > Anima mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/anima
> >
>
> --
>
> Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046
> Distinguished Professor Emeritus fax: +1 (514) 848-2830
> Department of Computer Science
> and Software Engineering
> Concordia University EV 3.185 email:[email protected]
> 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill
> Montreal, Quebec Canada H3G 1M8
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
