55: Could discovery be performed over TCP?
Michael is concerned by the use of insecure link-local multicast.
MR: I wonder if we shouldn't just send discovery messages on
always-up TCP connections from GRASP_LISTEN_PORT<->GRASP_LISTEN_PORT.
BC: Yes, if the ACP could give me an API call for that.
56: Change Session-ID to 32 bits?
MR: Given that CBOR has only 1,2, and 4 byte uintegers, why do we have a 24-bit
session-id?
BC: Well, it's a hangover from the pre-CBOR TLV format. But I think it's true
that we'd
increase the average message size by making it 32 bits, since there are a lot
mor
57: Add M_INVALID message?
MR: What does one do with an invalid msgtype? Options are:
1) ignore (drop msg)
2) die: drop TCP connection
3) reply with ???-M_INVALID or something.
BC: I'm inclined to add M_INVALID as a MAY, or possibly a SHOULD,
but with a rule that you MUST NOT repl
58: Maximum message size?
MR: I'm also a bit concerned that we have no statement about maximum message
size.
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
infinitely long
Intents, I th
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
> questi
On 19/10/2016 21:41, Michael Behringer (mbehring) wrote:
>> -Original Message-
>> From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Brian E
>> Carpenter
>> Sent: 18 October 2016 22:06
>> To: Anima WG
>> Subject: [Anima] GRASP issue 58: Max
On 20/10/2016 08:59, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > Michael is concerned by the use of insecure link-local multicast.
>
> No. That's not my concern, actually.
>
> My original concern was that, when doing discovery outside of th
Hi Michael,
That seems like a good idea. I think there might be an element of
redundancy but maybe that is not such a bad thing.
Regards
Brian
On 20/10/2016 01:37, Michael Richardson wrote:
>
> Brian, I began reading draft-carpenter-anima-asa-guidelines-00 and also
>draft-liu-anima-g
On 20/10/2016 09:03, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > MR: Given that CBOR has only 1,2, and 4 byte uintegers, why do we have
> > a 24-bit session-id?
>
> > BC: Well, it's a hangover from the pre-CBOR TLV format. But I t
20/10/2016 09:13, Michael Richardson wrote:
> Brian E Carpenter 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 infinitely long Intents, I t
On 20/10/2016 14:58, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
>
> >> Brian E Carpenter wrote: > Michael is
> >> concerned by the use of insecure link-local multicast.
> >>
> >> No. That's not my concern, act
On 20/10/2016 15:01, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > As I said, I don't really see the issue there. According to
> > https://tools.ietf.org/html/draft-ietf-anima-grasp-07#section-3.6 the
> > negotiation (or synchronization) s
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 start
Oops, there was a prettifying bug in the previous version...
On 20/10/2016 15:01, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > As I said, I don't really see the issue there. According to
> > https://tools.ietf.org/html/draft-ietf-anima-g
On 21/10/2016 01:56, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> >> What I was saying was, *IF* I know how to find a machine with an open
> >> GRASP_LISTEN_PORT, and I connect to it, and unicast a DISCOVERY, that
> >> I should rec
On 21/10/2016 02:02, Michael Richardson wrote:
>
>
> Brian E Carpenter wrote:
> > Oops, there was a prettifying bug in the previous version...
>
> ...
>
> > OK, so now I'll make one with multiple steps [pause while I run my
> > example gene
On 23/10/2016 08:37, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > On 21/10/2016 01:56, Michael Richardson wrote:
> >>
> >> Brian E Carpenter wrote:
> >> >> What I was saying was, *IF* I know how to find a machine with an
On 24/10/2016 09:17, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > On 21/10/2016 02:02, Michael Richardson wrote:
> >>
> >>
> >> Brian E Carpenter wrote:
> >> > Oops,
I'm going to take silence as assent: i.e. we will specify
a default maximum message size of 2048, and leave the question
of how it can be exceeded to be a negotiable property of individual
objectives.
Regards
Brian
On 20/10/2016 15:34, Brian E Carpenter wrote:
> On one point:
>
&g
And I'm going to take silence on this one as assent, and add the
message to the spec (and test it in the prototype).
Regards
Brian
On 19/10/2016 21:47, Michael Behringer (mbehring) wrote:
>> -Original Message-
>> From: Anima [mailto:anima-boun...@ietf.org] On
to increase the space to 32 bits, since
as Michael observed it will be stored as a uint32 anyway, in practice, and the
impact
on CBOR size is minor.
Regards
Brian
On 24/10/2016 16:28, Brian E Carpenter wrote:
> On 24/10/2016 09:17, Michael Richardson wrote:
>>
>> Brian E Carpent
Hi,
This version is intended to respond to all the comments we received so far,
including those discussed on the design team list. Special thanks to
Michael Richardson for his thorough analysis.
There are a couple of protocol changes:
1. Added an M_INVALID message, so that a node can tell its pe
the reason we noted the *possibility*
of doing this in grasp-08 is because it seems clearly harmless. So from the
GRASP spec point of view, I consider the issue closed.
Regards,
Brian
> Cheers
> Toerless
>
> On Sat, Oct 22, 2016 at 03:37:56PM -0400, Michael Richardson wrote:
&g
Hi,
This is about the bootstrapping draft, but I will start by quoting Toerless
from another thread:
On 01/11/2016 11:18, Toerless Eckert wrote:
> On Mon, Oct 31, 2016 at 01:23:36PM +1300, Brian E Carpenter wrote:
>>> I am confused about the reason for this discussion. It seems yo
Hi Toerless,
On 01/11/2016 11:18, Toerless Eckert wrote:
> On Mon, Oct 31, 2016 at 01:23:36PM +1300, Brian E Carpenter wrote:
>>> I am confused about the reason for this discussion. It seems you are trying
>>> to figure out how to minimize the impact of the insecure multicas
Hi,
We haven't updated draft-liu-anima-grasp-api for this meeting, or requested
an agenda slot for it. It didn't need any significant changes for
the -08 version of GRASP. However, we (the authors) believe that this
is essential work and we definitely intend to improve the document
and request its
Hi,
We haven't updated draft-ietf-anima-prefix-management for
this meeting and haven't requested a slot for it. However,
it's important work that needs to be finished. At the moment,
the main issue is that the section on Intent needs to be
improved.
1) It uses some made-up notation for Intent. Th
In line...
On 02/11/2016 11:42, Max Pritikin (pritikin) wrote:
>
>> On Oct 31, 2016, at 6:59 PM, Brian E Carpenter
>> wrote:
>>
>> Hi Toerless,
>> On 01/11/2016 11:18, Toerless Eckert wrote:
>>> On Mon, Oct 31, 2016 at 01:23:36PM +1300, Brian E Carp
up of time without clocks
Date: Wed, 2 Nov 2016 08:38:04 +1300
From: Brian E Carpenter
Organization: University of Auckland
To: home...@ietf.org
On 02/11/2016 03:52, Philip Homburg wrote:
...
> Which brings me to the following: given that all code has security issues,
> maybe devices shoul
t; yet.
>>
>> The approaches provided here work with some prior planning but are not
>> magical.
>>
>> Do you have pixie dust to suggest?
>>
>> - max
>>
>>> On Nov 1, 2016, at 8:53 PM, Brian E Carpenter
>>> wrote:
>
On 03/11/2016 03:37, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > Currently the GRASP code finds out how many physical interfaces it has
> > and for each one creates a multicast sending socket. It also has a
> > socket that listens for incoming
In line...
On 03/11/2016 03:34, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> te> b) I have just posted ACP draft -04 in which i have reversed the
> choice
> te> of mDNS for ACP discovery by neighbors from the -03 text which had
> te> mDNS. So -04 defines to use (DULL) GRAS
On 03/11/2016 10:18, Eliot Lear wrote:
> Hi Brian,
>
> On 11/2/16 8:09 PM, Brian E Carpenter wrote:
>> Firstly, no, I have no pixie dust, and I agree that we need to preserve
>> security even after a disaster. But on the other hand, if autonomic
>> networks matter at
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 ema
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 somewhere
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 see
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
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 depending on IP seems
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 21:42
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 some
Hi,
This message is part of an off-list discussion I've been having with Toerless,
but
I hope it's of general interest. The topic is how GRASP will "see" the network
when the ACP is running. I've been concerned that the ACP draft isn't specific
enough about this: what interfaces, sockets and sock
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 mus
So, I guess you've arrived... below:
On 12/11/2016 15:51, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> > I am confused about the reason for this discussion. It seems you are
> > trying to figure out how to minimize the impact of the insecure
> > multicast piece of GRASP, but
On 12/11/2016 15:52, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> >> Which, I have to point out, is not a consensus position; design teams
> >> propose, they don't decide. I'm waiting to see the next draft before I
> >> raise this issue on the WG list.
>
> > Right. I gu
On 12/11/2016 15:54, Michael Richardson wrote:
>
> Brian E Carpenter 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 do
>
> Please be clear: are these e
On 12/11/2016 15:56, Michael Richardson wrote:
>
> Brian E Carpenter 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 d
On 12/11/2016 15:57, Michael Richardson wrote:
>
> Brian E Carpenter 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
> > exactly like physical LL interf
On 12/11/2016 15:57, Michael Richardson wrote:
>
> Brian E Carpenter 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
> > exactly like physical LL interf
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 users with
> > de
On 13/11/2016 20:31, Michael Richardson wrote:
> Brian E Carpenter 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
> >> rather too much for some.. To be
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 secur
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
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 bei
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
Max,
Cherry-picking your comments; I will respond to Toerless's detailed
comments later:
On 18/11/2016 12:33, Max Pritikin (pritikin) wrote:
> Some comments on the BRSKI discussion inline,
>
>> On Nov 17, 2016, at 3:17 PM, Toerless Eckert wrote:
>>
>>
>> Thanks Brian & Bing
>>
>> Inline
>>
>
The ACP is not an ASA, it's actually a set of components,
and probably it includes several daemons.
However, I think that modelling the ACP *neighbor discovery function*
as an ASA is correct - it will after all be using GRASP, and it will
probably need to run indefinitely because of handling new n
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:
> - allo
Off list.
Will do. Not before Monday though. Safe travel home.
On 18/11/2016 15:10, Michael Behringer (mbehring) wrote:
>> -Original Message-
>> From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Brian E
>> Carpenter
>> Sent: 18 November 2016 10:32
>
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 draft,
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 per AF?
>>
>>
>> Mic
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 runni
Comments in line..
On 25/11/2016 09:37, Michael Richardson wrote:
>
> Brian E Carpenter 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 few
> > things
On 25/11/2016 18:30, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > Right. But to be very clear, at the moment the M_FLOOD syntax is
>
> > flood-message = [M_FLOOD, session-id, initiator, ttl, (locator-option
> > / []), +objective]
>
>
On 25/11/2016 09:37, Michael Richardson wrote:
...
> >> 3.5.4.4: QUERY re: The relayed discovery message MUST have the same
> >> Session ID as the incoming discovery message and MUST be tagged with
> >> the IP address of its original initiator (see Section 3.8.4).
> >>
> >> I th
> 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
Replying on some details in Michael's review. Points that are omitted here
are either obvious and will be fixed in the next version, or are already
the subject of other threads:
On 24/11/2016 11:47, Michael Richardson wrote:
...
> 2.1 [Requirements for Discovery] --- does this belong in GRASP, vs
I put this aside just before the IETF:
On 05/11/2016 04:02, Toerless Eckert wrote:
> On Fri, Nov 04, 2016 at 08:33:43PM +1300, Brian E Carpenter wrote:
>>> GRASP should have a separate socket for each interface
>>
>> How many interfaces do you mean? With no ACP, GRASP kno
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 specified.
Hi,
I support adoption of the draft, since we need it as part of Anima.
A couple of points seem to need attention before we get to WGLC:
> NOTE: AT THIS TIME, THE SIGNING STRATEGY HAS NOT BEEN SELECTED
I think that needs to resolved.
>Implementations MUST ensure devices have
>an accura
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 asso
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
__
This draft has been expanded from the earlier version to fill in some
gaps. The authors would welcome more thoughts and contributions. If
Anima is a success there will be many ASAs, so it seems important to have
some guidelines.
Regards
Brian Carpenter
On 07/01/2017 08:09, internet-dra...@ietf
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 propaga
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, [ [O_IPv6_LOCATOR,
Regards
Brian Carpenter
On 09/01/2017 13:57, Michael Richardson wrote:
>
> Brian E Carpenter 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
> >
Two minor things:
[O_IPv6_LOCATOR, fe80::1234, 41, nil]
The address is represented as 128 bit quantity, bytes .size 16 in CDDL, so
it will actually just be an in6_addr in C terms. If you really want
to write it down, 0xfe801234
nil is a valid element in CDDL, but is there
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,
Regards
Brian Carpenter
On 10/01/2017 03:43, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> >> When I read: divert-option = [O_DIVERT, +locator-option]
> >>
> >> I think that it means that +locator-option means that one can multipl
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 ha
or Chicago, I could 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,
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:
>
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
O
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 1
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 down).
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
releases
Some of us from the Anima WG will try to do interop stuff at the hackathon.
See https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=98hackathon
Please sign up - and if you plan to bring Anima code, let us know!
Otherwise, you'll need a laptop running Linux or Windows, with
Python 3 (*n
Forwarded Message
Subject: Port and multicast address usage [Re: Anima@hackathon]
Date: Sun, 5 Feb 2017 17:49:56 +1300
From: Brian E Carpenter
Organization: University of Auckland
To: hackat...@ietf.org
Since we don't have any IANA allocations yet, Anima code
will need to us
On 10/02/2017 06:15, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > UDP & TCP port:
> > GRASP_LISTEN_PORT = 1021
>
> You pick a "system" port. It might be better for experimenters not to.
But those are the only ports reserved
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 be
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 impl
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 Pe
without some AD/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.
>
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.
How?
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 to
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 Synchron
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 understa
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 excuse the unclear brevity of my rem
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 get
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
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
201 - 300 of 838 matches
Mail list logo
