RE: Multicast and Routing Headers//RE: Dumb question about routing headers

["Xiejingrong (Jingrong)" <[e-mail]>]

Hi Gyan,

Agreed with your analysis that, once the RH is used before a packet is transformed to a multicast packet on a node, the RPF may very much likely to fail on that node or the downstream nodes.
Usually the multicast RPF check based on MFIB/MRIB is a control-plane output with multicast signaling like PIM.
In the draft you mentioned, the forwarding-entry of a “BIER-specific” multicast address in MFIB will be a “pre-provisioning” output and should disable RPF.
Anyway, as the acronym “GDA” and the many text in RFC988/1112/2460 indicates, multicast address is not allowed to be “source-address” or in any type of routing-header.
That draft had been updated ever since this was clear, so please move on to the latest rev:
https://tools.ietf.org/id/draft-xie-bier-ipv6-encapsulation-06.txt

Very much appreciated for your comments!

Regards,
Jingrong


From: Gyan Mishra [mailto:[e-mail]]
Sent: Friday, May 29, 2020 7:19 AM
To: Xiejingrong (Jingrong) <[e-mail]>
Cc: 6man <[e-mail]>; Brian E Carpenter <[e-mail]>; Nick Hilliard <[e-mail]>
Subject: Re: Multicast and Routing Headers//RE: Dumb question about routing headers


Hi Jingrong

This question came up and I responded that there would be an RPF check failure from the perspective of customer signaling.  In that perspective the uRIB has to be up and stable  RPF interface set for mRIB and multicast data plane to build so from that perspective it did not seem it could work.

Thinking of it from the core side p-tree PMSI-UI/MI MVPN procedures tree instantiation RFC 6513 6514 over non MPLS SRV6 networks perspective, and
also after reading the draft below it makes sense that the last segment is a multicast address close to the destination of the p-tree egress PE.

https://tools.ietf.org/html/draft-xie-bier-6man-encapsulation-00#section-4.3

I agree with all your points that from my many years working with multicast architecture I agree a multicast address GDA “Group Destination Address” as the acronym states has to be a destination address and cannot be a source address.  When you craft a an ACL or QOS policy or sniffer capture filter its always SA (unicast address) <=> DA  (Class D Multicast address)


Kind Regards

Gyan

On Sun, May 24, 2020 at 11:47 PM Xiejingrong (Jingrong) <[e-mail]<mailto:[e-mail]>> wrote:
Hi!
I feel invited to this topic based on my work in the last many years about multicasting using IPv6.

[Q1] Is a routing header whose final destination is a multicast address, but whose previous segments are all unicast, valid?

[Comment-1] It is exactly what I had proposed in the initial BIERv6 draft:
Section 4.3: Routing header [SRH Header with Multicast Address as last SID] + Destination Option Header [BIER header in BIER Option TLV].
https://tools.ietf.org/html/draft-xie-bier-6man-encapsulation-00#section-4.3

[Comment-2] Later I found this had been considered ever since multicast-address was invented/designed by Dr. Steve Deering.
RFC1112: A host group address must never be placed in the source address field or anywhere in a source route or record route option of an outgoing IP datagram.
RFC2460: Multicast addresses must not appear in a Routing header of Type 0, or in the IPv6 Destination Address field of a packet carrying a Routing header of Type 0.
Though RFC2460 says only for RH0, but I believe it is a generic consideration following RFC1112, when in the time of RFC2460, the RH0 was considered a "template" of RH instead of a "place holder" now in RFC8200.
Besides, to give more history, RFC966 didn't realize the multicast address abuse as Source-Address, source-routing Option, but later RFC988 realized and fixed this, and RFC1112 is a following of RFC988.

I believe this could answer the many questions about using "multicast address" in IPv6 Source-Address, RH, etc. ---- Past and General consideration is NOT allowing.


[Q2] .... or whose intermediate destinations are multicast addresses?

[Commtne-3] I believe this is allowed as above comment-2 introduced, and as RFC2460/RFC8200 stated in many places (text below copied verbatim from RFC8200):
  Extension headers (except for the Hop-by-Hop Options header) are not
  processed, inserted, or deleted by any node along a packet's delivery
  path, until the packet reaches the node (or each of the set of nodes,
  in the case of multicast) identified in the Destination Address field
  of the IPv6 header.

  The Hop-by-Hop Options header is not inserted or deleted, but may be
  examined or processed by any node along a packet's delivery path,
  until the packet reaches the node (or each of the set of nodes, in
  the case of multicast) identified in the Destination Address field of
  the IPv6 header.

     10 - discard the packet and, regardless of whether or not the
          packet's Destination Address was a multicast address, send an
          ICMP Parameter Problem, Code 2, message to the packet's
          Source Address, pointing to the unrecognized Option Type.

     11 - discard the packet and, only if the packet's Destination
          Address was not a multicast address, send an ICMP Parameter
          Problem, Code 2, message to the packet's Source Address,
          pointing to the unrecognized Option Type.

[Comment-4] We've improved the proposal of BIERv6 to use Multicast address as intermediate destinations (with DOH carrying BIER header for replication).
https://tools.ietf.org/html/draft-xie-bier-6man-encapsulation-02#section-5
   In an IPv6 BIER domain, the Multicast Address of the IPv6 DA in an
   incoming BIER IPv6 packet indicates the BIER information of this
   'host', and the packet will be forwarded according to the BIER Header
   in the BIER Destination Option TLV in the IPv6 Destination Option
   extension header.

[Comment-5] Using multicast address as intermediate destinations is still in the text of the latest BIERv6 draft, but the preferred solution is to use unicast address as intermediate destinations for many design targets in a single proposal.
https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06#section-3.2
Summary comment is that, the multicast(or maybe multi-unicast/manycast) solution based on IPv6 EH has been lacking of considerations when discussing "IPv6 understanding" and "IPv6 Future".
It is the latest one we have worked on for 2+ years, and have requested 6man for review long time ago. Please feel welcome to discuss!


Thanks
Jingrong

-----Original Message-----
From: ipv6 [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Nick Hilliard
Sent: Monday, May 25, 2020 5:23 AM
To: Brian E Carpenter <[e-mail]<mailto:[e-mail]>>
Cc: 6man <[e-mail]<mailto:[e-mail]>>
Subject: Re: Dumb question about routing headers

Brian E Carpenter wrote on 24/05/2020 22:05:
> Is a routing header whose final destination is a multicast address,
> but whose previous segments are all unicast, valid?

..... or whose intermediate destinations are multicast addresses?

https://twitter.com/brenankeller/status/1068615953989087232

Nick

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD