Re: [Anima] I-D Action: draft-ietf-anima-grasp-06.txt

Hi, For practical reasons this is probably the last update of GRASP before Berlin, although some reviews are ongoing. There is no protocol change this time. Change log: Added text on discovery cache timeouts. Noted that ASAs that are only initiators do not need to respond to discovery

Re: [Anima] ASA management discussions [was snip of] Review of ANIMA GRASP

ain > concerns addressed in these snipped points. > A way to make clear that these points go beyond GRASP design, but concern > ANIMA WG as a whole. > > Thanks for your answers > > Pierre > >> -Message d'origine- >> De : Brian E Carpenter [mailto:brian.

Re: [Anima] FW: New Version Notification for draft-ietf-anima-autonomic-control-plane-03.txt

Hi, I have one big issue with this version, and a few other comments below. > 5.2. Neighbor discovery via mDNS/DNS-SD > > Autonomic devices use DNS-SD/mDNS to discover the IPv6 link-local > address of autonomic neighbors across L2 adjacencies. The result is > stored in the AN

Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt

Hi, Thanks for this. One point raises some questions in my mind: > 5. Intent splitting (on each node): Intent is split into sections, > one for the ANI itself, others for specific Autonomic Functions. > ASAs are notified if there is new Intent for them. Some intent > sections

Re: [Anima] FW: New Version Notification for draft-ietf-anima-autonomic-control-plane-03.txt

Hi Toerless, On 09/07/2016 09:38, Toerless Eckert wrote: > Inline > > On Sat, Jul 09, 2016 at 05:25:10AM +1200, Brian E Carpenter wrote: >> Hi, >> >> I have one big issue with this version, and a few other comments below. >> >>> 5.2. Neighbor disco

Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt

Just blending the two response sub-threads: On 12/07/2016 00:37, Laurent Ciavaglia wrote: > Hello, > >> Yes. There's been an assumption, I think, that one "autonomic function" == >> one ASA. >> We need to be clear if that is an axiom, and we need to think about how ASAs >> are >> named, and if

Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt

Is the attached drawing correct? It's supposed to be an Autonomic Function implemented across three Autonomic Nodes X, Y and Z containing a total of four ASAs managing two different technical objectives A and B. (If anyone wants to fire back a corrected version I have attached the PPT as well as

Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-03.txt

Hi, >b. MUST: Performs DNS-based Service Discovery [RFC6763] over >Multicast DNS [RFC6762] searching for the service >"_bootstrapks._tcp.local.". I missed the bit where we got consensus to only specify DNSSD for discovery. My understanding was that since all ANs will contain

Re: [Anima] Review of ANIMA GRASP

Pierre, Let me try to answer your points below. I have deleted a lot of text to make the message short enough to read. Also, please note that my main concern for now is to ensure that GRASP does everything we need; many aspects that are specific to ASA design do not affect this. On 02/07/2016

[Anima] New release of Python3 GRASP prototype

Hi, I've uploaded a new release of the Python3 GRASP prototype and demonstration ASAs to https://www.cs.auckland.ac.nz/~brian/graspy/. These use an updated version of the GRASP API (with numeric error codes instead of English-language strings) so they are *incompatible* with all earlier

Re: [Anima] [Anima-bootstrap] converging on some common terminology

So, we should adopt this terminology for the GRASP objectives, I guess. We also need to make them correspond to the latest thinking in other ways too. Any more comments on draft-carpenter-anima-ani-objectives before we update it? Regards Brian On 21/01/2017 04:26, Michael Richardson wrote: >

Re: [Anima] I-D Action: draft-carpenter-anima-ani-objectives-00.txt

This is a reply to an old but very interesting message. We're working on an update to the draft. Some of Toerless's points will be directly addressed in the new draft. Some of them are out of scope since the draft only aims to define formats. I have commented on a few others below. On 18/11/2016

Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-05.txt

Hi, Some comments, not in order of importance. > 2.3. Data Plane Independent Permanent Reachability It's probably worth noting in this section that the ACP does depend on some basics: e.g. layer 2 bridges functioning and intermediate nodes functioning (even if their data plane routing is

Re: [Anima] M_FLOOD vs M_DISCOVERY

Michael, You show the objective as ["AN_registrar", F_DISC, 255 ] i.e. with a null value. SHouldn't it include a value field that indicates the supported method(s)? I've been using values like "BRSKI-COAP" and "BRSKI-TLS". Just relying on the port numbers seems a bit schlonky. Regards Brian

[Anima] Hackathon, GRASP and C: a challenge to the WG

Hi, I've been entertaining myself by putting together an IPC interface to the GRASP Python prototype. (As of today, it seems to be working, but the code is not fit to publish yet.) Why? Because this is what we need for multiple independent ASAs to call a single instance of the GRASP core.

Re: [Anima] Fwd: Port and multicast address usage [Re: Anima@hackathon]

On 10/02/2017 06:15, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > UDP & TCP port: > > GRASP_LISTEN_PORT = 1021 > > You pick a "system" port. It might be better for experimenters not to. But those

Re: [Anima] Review of draft-ietf-anima-grasp-09

Charlie, CC to i...@ietf.org dropped for now, we don't need to bore everybody. I have Bcc'ed Benoit since I mention him below. Thanks for the careful review, it's just what we needed. For now, just a few top level comments below: On 14/02/2017 09:36, Charles Perkins wrote: > Reviewer: Charles

[Anima] Fwd: I-D Action: draft-carpenter-anima-ani-objectives-01.txt

Updated for consistency with various other drafts. Please read! There are issues to discuss, for example: There are a two options for ACP adjacency discovery: either each node periodically floods out its existence, or each node periodically uses GRASP discovery to find its neighbours. Which is

[Anima] Fwd: I-D Action: draft-liu-anima-grasp-api-03.txt

And here's an update to the GRASP API. Main changes: 1) Changed error return to integers: The previous design returned English-language error strings. This design returns an integer error code, but therefore needs the error codes to be enumerated. So far, there are 38, based on the prototype

Re: [Anima] Review of draft-ietf-anima-grasp-09

D/WG Chair guidance on the larger questions mentioned below. Regards Brian On 14/02/2017 12:18, Brian E Carpenter wrote: > Charlie, > > CC to i...@ietf.org dropped for now, we don't need to bore > everybody. I have Bcc'ed Benoit since I mention him below. > > Thanks for the caref

Re: [Anima] CoAP et al

Let's be clear about the Anima context for "bootstrapping". You don't have to look beyond the document abstract: " This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using vendor installed IEEE 802.1AR manufacturing installed certificates, in

Re: [Anima] Hackathon, GRASP and C: a challenge to the WG

y/remotes/ starting with the README. As an added bonus, I included a rough draft of the C header file for a GRASP API. All we need now is a C programmer to do the rest. Regards Brian On 21/02/2017 17:48, Brian E Carpenter wrote: > Hi, > > I've been entertaining myself by putting togethe

Re: [Anima] Review of draft-ietf-anima-grasp-09

Hi Charlie, While reviewing your comments, I came upon one that I don't understand: > 3.5.6.1. Flooding > ... > A GRASP device with multiple link-layer interfaces (typically a > router) MUST support synchronization flooding on all interfaces. If > it receives a multicast Flood

Re: [Anima] I-D Action: draft-ietf-anima-grasp-07.txt

There are some protocol changes in this version, corresponding to previous messages to the WG: Protocol change: Added TTL field to Flood message (issue 51). Protocol change: Added Locator option to Flood message (issue 51). Protocol change: Added TTL field to Discovery Response message

[Anima] Review of draft-ietf-anima-autonomic-control-plane-04

Hi, This is not an exhaustive review, because I've mainly focussed on the aspects that concern me most as co-author of the GRASP draft. But in general, I like this document and what it proposes. > Abstract > >Autonomic functions need a control plane to communicate, which >depends on

Re: [Anima] [homenet] write up of time without clocks

On 04/11/2016 21:07, Eliot Lear wrote: > Hi Brian, > > On 11/4/16 8:08 AM, Brian E Carpenter wrote: >> >> Also, much of this topic is systems engineering, not protocol design. >> However, at the protocol design level it seems apparent that autonomic >> mechanism

Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?)

On 05/11/2016 09:54, Max Pritikin (pritikin) wrote: > > >> On Nov 3, 2016, at 6:45 PM, Toerless Eckert wrote: >> >> On Tue, Nov 01, 2016 at 10:42:32PM +, Max Pritikin (pritikin) wrote: >>> Taken to the extreme one could argue that we need ANI to be self-contined >>> so

Re: [Anima] Desaster recover...

Jonathan, BRSKI (I not Y) is defined in draft-ietf-anima-bootstrapping-keyinfra-04 "Bootstrapping Remote Secure Key Infrastructures (BRSKI)". If there are incomplete or incorrect references in other documents, of course they need to be completed or corrected. Regards Brian On 07/11/2016

Re: [Anima] ANIMA state machines, take two

Michael, I like this. I have a few comments on some of your open questions: > Discovery: >mDNS or GRASP? I feel very strongly that we need the ANI to be as self-contained as possible. Therefore, it must be possible for the ANI to create itself without depending on mDNS. Therefore, we

Re: [Anima] concerns about selection of session-id in GRASP messages

Hi Michaeil, On 20/10/2016 04:59, Michael Richardson wrote: > > As I understand it, once an ASA has discovered a counterpart ASA in another > node, they will open a TCP connection. Some questions occured to me this > morning while cycling home from a working breakfast. Some clarification >

Re: [Anima] M_END, O_ACCEPT

On 20/10/2016 15:12, Michael Richardson wrote: > > Brian, is there some reason why the M_END could not be: > >accept-option = [O_ACCEPT, ?stuff] > > or is it your intention that if the one end has additional information to add > (such as port number where the requested service has been

Re: [Anima] GRASP issue 58: Maximum message size?

09:13, Michael Richardson wrote: > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > BC: Me too. I coded my prototype with recvfrom limited to 2048 bytes, > > but we probably need to specify something. On the other hand, Michael B > > wants to send

Re: [Anima] GRASP issue 56: Change Session-ID to 32 bits?

On 21/10/2016 02:02, Michael Richardson wrote: > > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > Oops, there was a prettifying bug in the previous version... > > ... > > > OK, so now I'll make one with multiple steps [pause whil

Re: [Anima] Prefix management Intent

On 18/10/2016 11:20, Michael Richardson wrote: > > I read draft-ietf-anima-prefix-management-01 today looking for a model for > how to define an ASA. I find section 5, and I it is reasonable, but I feel > that there are perhaps some critial details missing. > > I think that it's pretty important

Re: [Anima] Autonomic Registry

Pedro, > For instance, disaster recovery scenarios require to establish network > systems (virtual and physical) that should be autonomic and disconnected > from any previously centralized infrastructure. Yes, we have already understood this problem, but there's a trade-off between this and

Re: [Anima] review of grasp-08

Thanks Michael, we will wait a few more days before rolling up all comments received. I am fine with most of your suggestions. A few things caught my eye: >> in the case of a constrained-node network [RFC7228]. Yes, that clause is out of scope. >>>system calls with core GRASP functions

Re: [Anima] review of grasp-08

Comments in line.. On 25/11/2016 09:37, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > Thanks Michael, we will wait a few more days before rolling up all > > comments received. I am fine with most of your suggestions. A f

[Anima] example for M_FLOOD? [was review of grasp-08]

> Can we please have an example for M_FLOOD? Was there a problem with the one at https://tools.ietf.org/html/draft-ietf-anima-grasp-08#appendix-D.2 ? Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Desaster recover...

On 17/11/2016 12:42, Max Pritikin (pritikin) wrote: > > Assuming we work out the BRSKI questions such that bootstrapping during > disaster recovery is clearly defined I’d imagine the rest of anima work work > “magically” — in that the new equipment added to a network does what it is > intended

[Anima] For the next version of GRASP...

Hi, At the moment, the only suggested updates for the next version of the GRASP draft are in this message from Toerless: https://mailarchive.ietf.org/arch/msg/anima-signaling/KyPI7tvxuAt-ehxHZ4yiEMB-qeg I didn't hear anything in the Anima sessions in Seoul that would require updates to the

Re: [Anima] I-D Action: draft-carpenter-anima-ani-objectives-00.txt

A bit last minute but if you have a chance to look at this today, please do so. It attempts to make some important details more precise. Note: This draft is posted to allow systematic discussion of the various objectives in a consistent way. It is quite probable that rather than this

Re: [Anima] Intent per ASA or per AF?

On 18/11/2016 14:53, Michael Behringer (mbehring) wrote: > One question that just came up: Should Intent be designed per ASA or per AF? > > My suggestion previously was to segment Intent into sections per Autonomic > Functions. > > Example: Intent for the bootstrap function could be: > -

[Anima] Quick clarification re GRASP tests

Just to clarify a comment Bing made about the tests with my Python prototype: - I have tested it in a single host by running multiple GRASP instances. These tests require the host to listen to its own multicasts. Done on both Windows 7 and Linux. - I have tested it between Windows and Linux on a

Re: [Anima] Desaster recover...

On 13/11/2016 20:02, Michael Richardson wrote: > > Toerless Eckert wrote: > >> Devices that have been brought up and are in the network post > >> bootstrap are not relevant to the BRSKI document. > > > To me the most important goal should be to provide candidate

Re: [Anima] GRASP issue 55: Could discovery be performed over TCP?

On 13/11/2016 20:31, Michael Richardson wrote: > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > >> However, I think that we will have to replace the GRASP query with > >> something else, maybe just a CoAP request, as the TCP for GRASP is >

Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-04.txt

On 12/11/2016 15:54, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > registrars. In this case it will be possible for autonomic nodes that > > wish to join the AN to use GRASP with no need for mDNS. If we don't

Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?)

On 12/11/2016 15:57, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > True, and I don't have a clear definition of what that code will do. > > If it will actually support LL multicast send and receive sockets >

Re: [Anima] Intent per ASA or per AF?

On 21/11/2016 06:36, Michael Behringer (mbehring) wrote: >> -Original Message- >> From: Michael Richardson [mailto:mcr+i...@sandelman.ca] >> Sent: 20 November 2016 07:42 >> To: Michael Behringer (mbehring) >> Cc: anima@ietf.org >> Subject: Re: [Anima] Intent per ASA or

Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?)

On 04/11/2016 13:35, Toerless Eckert wrote: > On Tue, Nov 01, 2016 at 01:59:17PM +1300, Brian E Carpenter wrote: >> I will read that carefully, but for me that doesn't need justification, >> because >> we need the ANI to be self-contained, so depending on mDNS seems wr

Re: [Anima] [homenet] write up of time without clocks

On 04/11/2016 17:43, Eliot Lear wrote: > Hi Toerless, > > > On 11/3/16 8:54 PM, Toerless Eckert wrote: >> On Wed, Nov 02, 2016 at 10:18:06PM +0100, Eliot Lear wrote: >>> Hi Brian, >>> >>> Before we start imagining what the requirements in such situations are, >>> are they at all written

Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?)

On 04/11/2016 11:55, Toerless Eckert wrote: > On Wed, Nov 02, 2016 at 10:34:39AM -0400, Michael Richardson wrote: >> I have no problem with the use of a GRASP multicast discovery here. >> >> I wonder about the utility of the GRASP unicast TCP response to the ACP >> discovery. > > See my last

[Anima] RPL parameters for ACP

Hi, While wearing my Gen-ART reviewer's hat this morning, I found myself reading the details of a particular use case for RPL*. So, it seems to me that the ACP draft currently has a gap. It isn't enough for interoperability to just say "use RPL". A few choices and parameters need to be

Re: [Anima] I-D Action: draft-ietf-anima-grasp-09.txt

Hi, This version resolves a round of post-WGLC comments, mainly from Michael Richardson. There are various wording improvements and clarifications, and minor corrections. Also there are two real changes: 1. Slightly modified format for the Flood message, so that a separate locator can be

Re: [Anima] clarify +locator-option

Regards Brian Carpenter On 10/01/2017 03:43, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > >> When I read: divert-option = [O_DIVERT, +locator-option] > >> > >> I think that it means that +loc

Re: [Anima] I-D Action: draft-ietf-anima-prefix-management-02.txt

Hi, This version has the description of "Intent" replaced by a description of non-default parameter setting, since we do not yet have an Intent mechanism. This version should be implementable just with GRASP and the ACP. Please review, comments are welcome. Regards Brian On 10/01/2017 08:31,

Re: [Anima] Hackathon at IETF94 thoughts

ould probably bring three Dell Latitude laptops: E5450 > (i5-5200U, Windows 7, Ubuntu), E6400 (Core 2 Duo P9500, Windows 7, > Ubuntu), C600 (Pentium III, Lubuntu only). > > Bill > > On 12/01/2017 2:17 PM, Brian E Carpenter wrote: >> Apart from me and Michael, who else wants

Re: [Anima] Hackathon at IETF94 thoughts

Apart from me and Michael, who else wants to work on code and run it in Chicago on March 25 and 26? We need BRSKI, ACP and GRASP. Regards Brian On 30/12/2016 14:19, Michael Richardson wrote: > > Brian and I have been discussing thoughts about an ANIMA Hackathon at IETF94. > > The question

Re: [Anima] clarify +locator-option

On 09/01/2017 14:02, Michael Richardson wrote: > > When I read: > divert-option = [O_DIVERT, +locator-option] > > I think that it means that +locator-option means that one can multiple > options, and that they would be inside an array? > > So, for example: > > [O_DIVERT, [

Re: [Anima] M_FLOOD vs M_DISCOVERY

Regards Brian Carpenter On 09/01/2017 13:57, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > >> We want to use GRASP to permit the bootstrap proxy to discover where > >> the Registrar(s) are. As far as

Re: [Anima] M_FLOOD vs M_DISCOVERY

On 09/01/2017 06:27, Michael Richardson wrote: > > We want to use GRASP to permit the bootstrap proxy to discover where the > Registrar(s) are. As far as I can see there are really two options, and they > might not be mutually exclusive. > > a) start a multicast M_DISCOVERY which will be

[Anima] GRASP Python prototype updated

The Python code at https://www.cs.auckland.ac.nz/~brian/graspy/ now corresponds to draft-ietf-anima-grasp-09. If you downloaded any earlier code, I strongly suggest updating it. I fixed a few bugs, added the dry-run flag, and updated the Flood message syntax. Regards Brian

Re: [Anima] GRASP API in C?

On 24/03/2017 04:43, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > Hi, > > > We will discuss the GRASP API > > (https://tools.ietf.org/html/draft-liu-anima-grasp-api-03) in Chicago. > > > One r

Re: [Anima] GRASP API in C?

On 25/03/2017 07:46, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > >> Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > Hi, > >> > >> > We will discuss the GRASP API > > >

Re: [Anima] GRASP API in C?

On 25/03/2017 11:46, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > It doesn't deal well with flexible types either, a dangerous luxury in > > Python that I've got very fond of. But it seems to me that if a GRASP >

Re: [Anima] [homenet] prefix assignment

On 31/03/2017 03:50, Ted Lemon wrote: > On Mar 30, 2017, at 9:45 AM, Michael Richardson wrote: >> It would hand out space via HNCP, and if it ran out of space, get more. > > This can also be done with DHCP. Indeed. I'm not trying to force the Anima approach, just pointing

Re: [Anima] I-D Action: draft-ietf-anima-grasp-11.txt

This version has updates that are supposed to close the open issues discussed on Monday: Encryption changed to a MUST implement. Pointed to guidance on UTF-8 names. Over to the WG Chairs and AD for the next step. Regards Brian, Bing, Carsten On 31/03/2017 08:16,

Re: [Anima] prefix assignment

OK, I'll front-post. Where you want to plug in an ASA (autonomic service agent) is anywhere you want plug in some intelligence to govern an automatic process. Intelligence, for example, to figure out what to do if the user side asks for a /48 and the ISP offers a /60. So the ASA might negotiate a

[Anima] GRASP multicast frequency

One more thing from our tests this week. We noticed when testing at busy times that link-local multicasts were often dropped. We would see quite long gaps when discovery and flooding simply did not occur. Suspecting that the wireless network was limiting the rate of multicasts, I cheated for a

Re: [Anima] FYI: GRASP testing this week

On 30/03/2017 09:52, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > with the Python implementation was not possible. I also learned the > > hard way that the Python code throws an exception on a badly > > malfor

Re: [Anima] prefix assignment

On 30/03/2017 09:16, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > Where you want to plug in an ASA (autonomic service agent) is anywhere > > you want plug in some intelligence to govern an automatic process. >

Re: [Anima] [homenet] prefix assignment

On 30/03/2017 10:04, Juliusz Chroboczek wrote: >> There's already a thing called an HNCP agent. Why couldn't >> it be enhanced to negotiate with an upstream ASA for resources? > > Could you please clarify what you mean by "negotiate"? Current HNCP > implementations are provided with a bunch of

Re: [Anima] autonomic framework

So, are you going to stop changing the names now? Because each time you change them, I have to update draft-carpenter-anima-ani-objectives but more seriously my demo code too... Join Router is wrong. It forwards messages not packets. Maybe its next name should be Join Middlebox, but I'm happy

Re: [Anima] CASM BOF

On 21/03/2017 10:50, Brian E Carpenter wrote: > I've been tracking this a bit. Their main focus is on a YANG > interface between the NOC and the IPAM system. It's thanks to > me that the C stands for Coordinated instead of Centralized. > > I believe that our prefix management use c

Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-05.txt

Hi, > 5. Proxy Discovery Protocol Details ... > proxy-objective = ["Proxy", [ O_IPv6_LOCATOR, ipv6-address, >transport-proto, port-number ] ] If that's a GRASP objective, it needs to include the loop-count and flags fields. Also, I thought it was

Re: [Anima] on the use of RPL without RPI (was Re: [6lo] Adaption of ROLL for mesh-under)

On 14/04/2017 04:36, Michael Richardson wrote: ... > I also think we could in light of rfc2460bis renegotiation, argue for > insertion of RPI header by the ACP without IPIP encapsulation :-) I wouldn't bet on that for a few more weeks yet. We do have a couple of mitigations however: 1) Since the

Re: [Anima] SecDir review of draft-ietf-anima-grasp-09

On 10/03/2017 05:53, Barry Leiba wrote: >> > Personal opinion: encryption should be a MUST. >> >> I believe that we will have situations where we have a secured ACP into a NOC >> (to an edge router or VM hypervisor), and then we will have some unencrypted, >> but secured links to platforms in

Re: [Anima] I-D Action: draft-ietf-anima-prefix-management-03.txt

Hi, We have made a few small updates to make the text more precise. We believe this should be ready for WG Last Call as Informational. Regards Brian + co-authors On 10/03/2017 15:54, internet-dra...@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts >

Re: [Anima] Review of draft-ietf-anima-grasp-09

This was a gap in the document as a whole. Easy to fix, fortunately. Thanks Brian > > Regards, > Charlie P. > > > On 3/1/2017 5:25 PM, Brian E Carpenter wrote: >> Hi Charlie, >> >> While reviewing your comments, I came upon one that I don't understand: &

Re: [Anima] Review of draft-ietf-anima-grasp-09

On 04/03/2017 13:28, Michael Richardson wrote: > > Charlie Perkins wrote: > > I probably should have said more. I just meant that such nodes ought > to be > > allowed to have some network interfaces that do not participate in > GRASP. > > Please

Re: [Anima] privacy in discovery

On 12/03/2017 08:08, Michael Richardson wrote: > > I haven't read the document yet, just the abstract. > > I am not suggesting it, just relaying that this privacy issue seems to be > something others have recognized as a concern. Do you see it as a concern inside the ACP? I would have thought

Re: [Anima] Factory reset: Do we need two types?

On 14/03/2017 08:26, Michael Richardson wrote: > > Michael H. Behringer wrote: > > The configuration of the device is outside scope, I think! If a config > > change removes the last ACP tunnel (for example), then it's that > > removal that changes the

Re: [Anima] Questions open after Last Call review of GRASP

Replying to myself, I have added a note to the first issue. On 05/03/2017 15:51, Brian E Carpenter wrote: > Hi, > > We got two excellent reviews of draft-ietf-anima-grasp-09 > from Joel Halpern and Charlie Perkins. In fact the WG owes > Charlie a big round of applause for the thor

[Anima] Questions open after Last Call review of GRASP

Hi, We got two excellent reviews of draft-ietf-anima-grasp-09 from Joel Halpern and Charlie Perkins. In fact the WG owes Charlie a big round of applause for the thoroughness of his review. Of course, the authors will fix all the issues that are mistakes, omissions, or lack of clarity. We will

Re: [Anima] SecDir review of draft-ietf-anima-grasp-09

Thanks Barry. Good comments, but we have to get a new draft out before the deadline, so I'm not sure these will all make it in until the one after. Regards Brian On 08/03/2017 15:43, Barry Leiba wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to

Re: [Anima] SecDir review of draft-ietf-anima-grasp-09

e), Once we specify byte-by-byte comparison, do we need to worry about this in a protocol document? If someone is silly enough to specify an objective called 'example.org:Недостаточно握 déjà vu ' do we care, in the protocol design? Personal opinion: we don't need to say anything. Regards

Re: [Anima] on the use of RPL without RPI (was Re: [6lo] Adaption of ROLL for mesh-under)

MA wish that ROLL > publishes that doc? > > Take care, > > Pascal > >> Le 13 avr. 2017 à 23:31, Brian E Carpenter <brian.e.carpen...@gmail.com> a >> écrit : >> >>> On 14/04/2017 04:36, Michael Richardson wrote: >>> ... >>>

Re: [Anima] proxy discovery of registrar

On 03/08/2017 07:46, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > >> Toerless has instead written the M_FLOOD mechanism. > >> We started a thread a few weeks ago about this... what happened to it, > I > &g

Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017

I'm just coming back on a couple of points. Generally -04 is almost there... On 03/08/2017 13:08, Toerless Eckert wrote: ...>>> 2.1.8. Long term direction of the solution >> ...>1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the >>>network to enable use of ACP is long

[Anima] Message size limit in GRASP - is it a problem?

Hi, I assume everyone is aware that GRASP limits its message size to 2000 bytes. In case anybody thinks that could be a problem, I don't think it is. Or at least, it's easily overcome for objectives that might become large. Recently I've coded a pair of demonstration ASAs to check the

Re: [Anima] The open issue in draft-ietf-anima-prefix-management

1PM +1200, Brian E Carpenter wrote: >> As a reminder, we have two options in the draft for adding support >> of IPv4 prefix management: >> >> 1. Add a version number flag to the objective >> 2. Add a second objective specific to IPv4 >> >> So far the preferenc

Re: [Anima] Is this how BRSKI/IPIP works?

On 13/07/2017 21:40, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > OK, I'm getting there. More in line: > > >> 1) Registrar accepts any Lx1 as local. There is no precedent in v6 > >> APIs to open suc

Re: [Anima] Is this how BRSKI/IPIP works?

On 14/07/2017 08:58, Eliot Lear wrote: > Hi Toerless, > > > On 7/6/17 9:09 AM, Toerless Eckert wrote: >> On Thu, Jul 06, 2017 at 04:34:05PM +1200, Brian E Carpenter wrote: >>> It used to be, but the recommendation today is a pseudo-random >>> value (RFC7217)

Re: [Anima] I-D Action: draft-carpenter-anima-ani-objectives-02.txt

On 30/06/2017 15:01, Brian E Carpenter wrote: > Hi, > > As Sheng suggested, this is a complete update of the GRASP > objectives for BRSKI, the ACP and the stable-connectivity draft. > I apologise to Bing, my co-author, for not checking with > him, but time was rather short. &g

[Anima] draft-ietf-anima-grasp-15 OK

Hi, This version of GRASP hasn't been posted yet due to the pre-IETF posting cutoff, but it has allowed both IESG DISCUSS ballots to be cleared. The main difference is that the text about the security and transport substrate provided by the ACP has been rewritten (by Toerless, thanks!). There is

Re: [Anima] Use of M_FLOOD for discovery of Proxy

Cheers > Toerless > > On Mon, Jun 19, 2017 at 09:36:04AM -0400, Michael Richardson wrote: >> >> Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: >> >> If a node doesn't want to announce itself as a proxy, it would omit >> that >>

Re: [Anima] Is this how BRSKI/IPIP works?

More inline. > > On Fri, Jul 07, 2017 at 08:32:03AM +1200, Brian E Carpenter wrote: >> Indeed. But the general-purpose o/s stacks (I mean Linux, >> MacOS and Windows) have been using pseudo-random interface >> IDs for several years, since long before RFC7217. If you're >

Re: [Anima] I-D Action: draft-rfmesh-anima-iot-management-00.txt

Hi, A quick comment since I will not be in Prague. This draft opens an important topic. At least we should explore it in more depth. One comment is that specifying how GRASP unicast messages would work over UDP is not quite simple - that's why it isn't covered in the main GRASP spec. Ensuring

Re: [Anima] I-D Action: draft-nmdt-anima-management-bootstrap-00.txt

Hi, A few comments on this too. Again, it is a good topic to explore. 1. What's the relationship to draft-ietf-anima-stable-connectivity? 2. I am a bit confused by section 5.1. There is no such GRASP message as M_NEG_SYN. Are you proposing a negotiation objective or a synchronization objective?

Re: [Anima] Is this how BRSKI/IPIP works?

On 12/07/2017 12:44, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > Is the following correct? > > > Topology (ASCII art): > > Topology is essentially correct. > As you point out, RFC7217 is the recommendatio

Re: [Anima] IPIP in draft-ietf-anima-bootstrapping-keyinfra-07

On 12/07/2017 12:47, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > But the third locator sent by the Registrar indicates a meaningless > > link-local address, because it could come from many hops away. At

  1   2   3   4   5   6   7   >