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

[jouni korhonen <[e-mail]>]

Hi,



> On May 26, 2017, at 3:55 AM, Balázs Varga A <[e-mail]> wrote:
> 
> 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). 

Good points.


> 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 


segment routing had always been there for unicast flows. it is an ugly beast tbh ;)

> 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. 

Segment routing architecture explicitly states:

6.  Multicast

   Segment Routing is defined for unicast.  The application of the
   source-route concept to Multicast is not in the scope of this
   document.

I am not sure how this affects the way forward. We could make that into our scope, though.

6man SRH document has this statement, which I am not sure how to interpret:

..
   4.    FIB lookup on updated DA
..
   o  If the FIB lookup matches a multicast state, then the related
      Reverse Path Forwarding (RPF) check must be considered successful.

> 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.

Indeed.

- Jouni


> 
> 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