I suppose that you have to question whether IP is the ideal base for multicast? Our networks are no longer mono-protocol and multicast tends to be domain specific. Many of the original uses for multicast are now dominated by unicast packet duplication with edge computing making this less of a bandwidth hog, so it is not clear what the long term future of multicast is. - Stewart > On 4 Jan 2023, at 19:59, Dino Farinacci <farinacci@xxxxxxxxx> wrote: > > You need a source address for multicast, unless you use shared-trees. And the multicast working groups at the IETF have pushed SSM forward quite a bit. So source-trees prevail. > > Dino > >> On Jan 4, 2023, at 5:54 AM, Stewart Bryant <stewart.bryant@xxxxxxxxx> wrote: >> >> >> >>> On 4 Jan 2023, at 09:35, George Michaelson <ggm@xxxxxxxxxxxx> wrote: >>> >>> Put a nonce source ip in the packet header and the real source as 4-16 bytes of PFS protected payload. >> >> Indeed we know that there is no need for an SA other than to support the most primitive types of communication or the most primitive types of detection of errors or spoofed packets. Though a spoofed SA may fall foul of the latter and cause the packet to be dropped. MPLS works fine without SAs. >> >>> >>> Use asymmetric routing. A single point of capture which isn't close to source or destination is occluded. >> >> Just to note that some protocols would like path symmetry for round trip delay equalisation. NTP is a good example. However this more a wish than a promise as ECMP is not symmetr >> >> Indeed, picking up on the earlier note about encrypted source routing, back in the very early days of MPLS SR we speculated about obscuring the labels so as to introduce a primitive form of end to end path control with limited visibility and limited ability of nefarious nodes to send over premium paths. >> >> Stewart >> >> >>> >>> Can't fix a warrant tap, but can at least obfuscate for on-path. >>> >>> G >> >
