David 'equinox' Lamparter <equi...@diac24.net> wrote:
> I've just submitted draft-equinox-6man-sub-link-scope-multicast-00.
> The point of this draft is to expose the Ethernet 01:80:C2 'special'
> limited scope multicast addresses for use in IPv6.Interesting. I then read: draft-acee-idr-lldp-peer-discovery. Yes, it would be safe for data center links only :-) I'm unclear if equinox-6man-sub-link-scope would somehow replace/refactor this? https://datatracker.ietf.org/doc/draft-filsfils-rtgwg-lightweight-host-routing/ I found this weirder. Why not just use an OSPFv6 stub? Such a thing wouldn't even need to listen, just blabber, I think. With sub-link-scope-multicast, this would work, better, right? https://datatracker.ietf.org/doc/draft-gong-spring-lldp-srv6-extensions/ In the very fast read, I didn't quite understand what a *host* needs to tell SRv6 infrastructure, just that it needed it. This document, like acee-idr-lldp defines another TLV over LLDP. ANIMA definitely wants equinox-6man-sub-link-scope-multicast! When we do discovery with GRASP for ACP peers, we'd really like to discover all the L2 things in preference to making overly broad meshes across an L3 multicast domain. So I wrote draft-richardson-anima-l2-friendly-acp-02 and it went through some variations. (Now expired, but not forgotten) It puts the GRASP (RFC8990) messages over LLDP. ANIMA's RFC8994/RFC8990 discovery M_FLOOD mechanism (RFC8994 section 6.4, RFC8990 section 2.8.11) can easily be used on its own, without implementing any other parts of GRASP. It uses CBOR, vs yet-another-partly-bespoke TLV mechanism. (True, the TLV in two of the documents look identical, and are identical to many other TLVs) Maybe there is convergence that we can do here. > (6man charter includes "addressing architecture", hence that intended > WG) :-) The document could use a few more words of overview and explanation for those not intimately familiar with the v6-multicast architecture, but I understood enough to implement. I think that because of the mapping to mac prefix 01:80:C2 that existing managed switch fabrics will know not to forward further. I think that if I have a system plugged directly into a managed switch that this multicast will not get beyond that switch. If I have a system plugged into an unmanaged ethernet switch, that all of the systems on that unmanaged switch will see this multicast, but it won't propogate further. .. with the clarifications from section 7.1 that I didn't know about before. > From: internet-dra...@ietf.org Date: Fri, 25 Jul 2025 06:45:25 -0700 > A new version of Internet-Draft > draft-equinox-6man-sub-link-scope-multicast-00.txt has been > successfully submitted by David 'equinox' Lamparter and posted to the > IETF repository. > Name: draft-equinox-6man-sub-link-scope-multicast Revision: 00 Title: > Sub-Link Scoped IPv6 Multicast Addressing Date: 2025-07-25 Group: > Individual Submission Pages: 13 URL: > https://www.ietf.org/archive/id/draft-equinox-6man-sub-link-scope-multicast-00.txt > Status: > https://datatracker.ietf.org/doc/draft-equinox-6man-sub-link-scope-multicast/ > HTML: > https://www.ietf.org/archive/id/draft-equinox-6man-sub-link-scope-multicast-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-equinox-6man-sub-link-scope-multicast > Abstract: > The IPv6 addressing architecture for multicast has the scope of a > multicast group embedded in its address, with the smallest non- > reserved scopes being interface-local and link-local, numbered 1 and 2. > This document suggests the introduction of a scope inbetween these two, > for use with lower-layer transport multicast that reaches parts of a > link. Since there is no room to insert a scope value for this, a > separate address block is used. A mapping for Ethernet as lower-layer > transport is provided. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
