Subject: [Anima] GRASP ALL_GRASP_NEIGHBORS

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Apr 2020 11:16:20 -0400

Brian, I was looking for the multicast destination for GRASP DULL messages.

Section 6 tells me that IANA has not yet assigned it.
I'm surprised we didn't ask for an Early Allocation.
Is it worth asking now?

Did I miss something?
-15 document says "TBD1"

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Apr 2020 11:44:10 -0400

> I'm surprised we didn't ask for an Early Allocation.

I found it in the IANA list.
I suggest the XML be updated to indicate that 0x13 was assigned, or maybe you
already did this with the RFC-editor?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Apr 2020 09:55:18 +1200

> already did this with the RFC-editor?

No, that normally gets resolved when they actually start editing, but yes of course it's on my checklist.

I'm quite sure the early aassignments were announced on the list, but when I forget what values were pre-assigned I just go and look at my code:

ALL_GRASP_NEIGHBORS_6 = ipaddress.IPv6Address('ff02::13')   # LL multicast
ALL_GRASP_NEIGHBORS_4 = ipaddress.IPv4Address('224.0.0.119') # LL multicast
GRASP_LISTEN_PORT = 7017 # IANA port number

Regards
    Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Apr 2020 18:14:45 -0400

> I'm quite sure the early aassignments were announced on the list, but
    > when I forget what values were pre-assigned I just go and look at my
    > code:

I thought that early allocations were supposed to go into the document so
they don't get assigned twice by mistake.

    > GRASP_LISTEN_PORT = 7017 # IANA port number

Thank you.

Is there any reason why the source port (for DULL, and normal) can't be port 7017 as well?
It clearly could be any port...

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Apr 2020 18:22:09 -0400

I suspect that for most GRASP purposes, even if there is a layer 2 
network between the parties,  we are not much worried about how LAG 
handles GRASP packets?   If we care about that, then the source port 
should be randomized between flows, and stable for sequences of related 
messages.

Yours,
Joel

On 4/27/2020 6:14 PM, Michael Richardson wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Apr 2020 11:24:19 +1200

I think we don't care, because GRASP traffic density should be quite modest so load balancing isn't really an issue. In response to Michael, I don't think the source port matters at all for M_FLOOD messages. My code uses the o/s default, but it has no significance to the recipient.

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Apr 2020 22:54:21 -0400

Joel M. Halpern <[email-masked]> wrote:
    > I suspect that for most GRASP purposes, even if there is a layer 2 network
    > between the parties,  we are not much worried about how LAG handles GRASP
    > packets?   If we care about that, then the source port should be randomized
    > between flows, and stable for sequences of related messages.

The idea being that the different 5-tuples would wind up on different links
of the LAG, correct?

Brian E Carpenter <[email-masked]> wrote:
    > I think we don't care, because GRASP traffic density should be quite
    > modest so load balancing isn't really an issue. In response to Michael,
    > I don't think the source port matters at all for M_FLOOD messages. My
    > code uses the o/s default, but it has no significance to the
    > recipient.

I agree with Brian: the DULL message is basically just a probe sent every few
seconds.  The bulk traffic would run over IPsec, so there will be an ESP SPI#.
How would a LAG flow balancer deal with that?  I don't think it would balance
at all unless two SAs were negotiated.  I think that the flow header could
also be tweaked in some kind of round robin fashion.

But, if it's a MC-LAG, then the ACP really wants to see both chassis
seperately.  So it occurs to me that we could hack LACP rather than LLDP :-)
It appears that it uses a specific multicast destination.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Apr 2020 23:14:11 -0400

LAGs can balance IPSec because the SPI is cafefully placed in the same 
location as the UDP / TCP port numbers, so if the LAG recognizes the 
protocol type (which most do), it can use the SPI just teh way it uses 
the port numbers.

Yes, it is a hack.  It is an OLD hack.

Yours,
Joel

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 28 Apr 2020 07:37:30 +0200

> they don't get assigned twice by mistake.

This is no longer an early allocation, as the document is approved; the only thing left to do for IANA is insert the RFC number upon publication.

BTW, IANA also has this quite useful web site, and grasp is a great search term:

https://duckduckgo.com/?q=grasp+site%3Aiana.org

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 28 Apr 2020 09:14:33 -0400

Joel M. Halpern <[email-masked]> wrote:
    > location as the UDP / TCP port numbers, so if the LAG recognizes the protocol
    > type (which most do), it can use the SPI just teh way it uses the port
    > numbers.

Yes, I thought as much, but since only a single SA would be negotiated, as
long as the SPI# remains the same, then it would hash the same.

    > Yes, it is a hack.  It is an OLD hack.

:-)
Those are the best.