Re: [Detnet-dp-dt] IPv6 and multicast [FUNDAMENTAL issue]

[Balázs Varga A <[e-mail]>]

Yeeaahhh, that's true regarding IETF ... 

Anyway, there is a FUNDAMENTAL multicast issue for DetNet.

I have started to review in detail the solution draft and I have a fundamental issue with multicast in the context of IPv6 & DetNet.
DetNet flows having an IPv6 multicast destination address may not gain from PREF (packet replication and elimination). This is 
because of the reverse-path-forwarding check (RPF check, see details below), which is essential part of each multicast 
implementations. 

For PREF we need disjoint paths. So PREF node receives the DetNet replica-flows via disjoint paths, however packets received 
over the paths may fail the RPF check and those will be discarded on ingress. Therefore the PREF process will not receive all 
the replica-flows (in worst case it may receive nothing when no one of the disjoint paths are able to pass the RPF check). 

As a result only DetNet flows with a unicast dst-IP-address can gain from PREF. For DetNet flows with multicast dst-IP-address
we need a workaround. 
(1) bypass RPF (seems to be mission impossible, breaks data plane essentials) or 
(2) other means (e.g., combine PREF mandatory with some other functions like tunneling)

For the "other means" we could use the SRH (segment routing header). We need it for ensuring the disjoint paths anyway. So 
the DetNet IPv6 packet will be encapsulated and the result will be a unicast IPv6 packet. Encapsulation may occur at the edge node
of the detNet domain (PE node). For DetNet-capable sources adding SRH may happen already in the source. SRH does not mandate 
what IPv6 addresses can be in the segment list, so the last one can be even a multicast address if the network scenario allows it. :--)))
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 

With that SRH based solution we fallback to the unicast scenario. :--))) Also placing the PREFs are at the SRH segment endpoints so 
encoding the seq.num. to a destination header is an obvious solution. 

Have I missed something? Comments are welcome.

Note: This is not an issue in L2 networks (IEEE) as L2 multicast default forwarding is flooding. And there is no RPF check for L2 
multicast ( as we have no glue where the L2-src is :--))) ). So using multicast dst-addresses was a rational approach in L2 networks,
but it is more challenging in L3 networks. 

Note2: This is not an issue in MPLS networks as LSPs are used and the PW encapsulation hides IP addresses. Forwarding on P2P and 
P2MP LSPs do not care what is inside and neither does PREF as it works based on the PW encapsulation information.

Cheers 
Bala'zs

BACKGROUND - IP multicast forwarding rules:
"Every multicast packet received must pass an RPF check before it is eligible to be replicated or forwarded on any interface.
The RPF check is essential for every router's multicast implementation. When a multicast packet is received on an interface, 
the router interprets the source address in the multicast IP packet as the destination address for a unicast IP packet. The 
source multicast address is found in the unicast routing table, and the outgoing interface is determined. If the outgoing 
interface found in the unicast routing table is the same as the interface that the multicast packet was received on, the 
packet passes the RPF check. Multicast packets that fail the RPF check are dropped because the incoming interface is not 
on the shortest path back to the source."


-----Original Message-----
From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of Jouni Korhonen
Sent: 2017. május 26. 0:02
To: Balázs Varga A <[e-mail]>
Cc: [e-mail]
Subject: Re: [Detnet-dp-dt] IPv6 and multicast

Hi,

I hear you. However, these kinds of things are issues IETF wise.. protocol purists, you know ;) Also, we have precedence using hop-by-hop options in rfc6621 (see Section 6.1). So I might actually be leaning towards favoring hop-by-hop as a generic solution even if it has an undesired impact for nodes that do not need to look the option up. At least the same solution would then work for both unicast and multicast.

- JOuni

-- 
Jouni Korhonen, Broadcom, Core Switching Group
[phone]



> On May 25, 2017, at 4:35 AM, Balázs Varga A <[e-mail]> wrote:
> 
> Hi,
> 
> I would take a pragmatic view on this. The rules of using the extension header options
> are defined primarily for "routing" decision purposes of the IP layer. However PREF is 
> a detnet service layer function by definition. So, PREF can simple check whatever 
> header fields are there in the IP packet to do its own task (namely replicate and 
> eliminate) even if the PREF node is not the destination node.
> 
> Therefore, destination option is absolutely fine as seq.num. Hop by hop would cause 
> unnecessary load for intermediate nodes to examine and process an option that 
> contains seq.num which is useless for them. 
> 
> Cheers
> Bala'zs
> 
> -----Original Message-----
> From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of Jouni Korhonen
> Sent: 2017. május 24. 23:55
> To: [e-mail]
> Subject: [Detnet-dp-dt] IPv6 and multicast
> 
> Continuing the discussion we had about IPv6, multicast and destination options. In a multicast case only the final receivers of the packets (i.e. the nodes joining to the multicast group as end hosts) would examine the Destination Option. I am not sure if this is the desired behavior? On the other hand a Hop by Hop option would be examined by all intermediate nodes whether they are PREF processing or not. Whcih one you would think is a better approach?
> 
> When using unicast and things like segment routing the behavior of the nodes is more straight forward. The processing of the Destination Option is done each time one of the routing option destinations are reached.
> 
> - Jouni
> 
> 
> 
> -- 
> Jouni Korhonen, Broadcom, Core Switching Group
> [phone]
> 
> 
> 
> _______________________________________________
> Detnet-dp-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt

_______________________________________________
Detnet-dp-dt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/detnet-dp-dt