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

Gyan Mishra <hayabusagsm@gmail.com> Thu, 28 May 2020 23:19 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001453A0F8C for <ipv6@ietfa.amsl.com>; Thu, 28 May 2020 16:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnpPfRSI8Bqu for <ipv6@ietfa.amsl.com>; Thu, 28 May 2020 16:18:59 -0700 (PDT)
Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F312B3A0F8B for <ipv6@ietf.org>; Thu, 28 May 2020 16:18:58 -0700 (PDT)
Received: by mail-il1-x144.google.com with SMTP id q18so694951ilm.5 for <ipv6@ietf.org>; Thu, 28 May 2020 16:18:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=25qFlKs/9PSndUvkg79ZiVQydrl6B2vpGHnKerGJ7mM=; b=QbILOl+DiUNtXRrlI3wbK/ysr9n0xrGjb8N4wyy/NvM4dv1RswcC/tQKUUejSoekb6 uhSa9bpSCWEOIUGSPkGz4f/M7CCQqZYkf6zdVxnsNsfWQ17RbZ3glHTsAE/jdh7glBSe xI/BbhFllz3W956/y7rcS5tonfDsDZ4rvGqsHTEH4MDb1Ez599TdmHfAfnc3mFxmTuGq SATZARJ5QLUody96tKmCAso7yAuFGqhEY1jbaNO7XZwUsI9sBYSFoIDOFMwpz5k6zS8K OBIVSTXH+Jm03hVXH9oQTfWF4ZOM/uUDDtAjQA4FxI0cbQ1xHYh2hcm8C2PXWJOJ2zEq s1+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=25qFlKs/9PSndUvkg79ZiVQydrl6B2vpGHnKerGJ7mM=; b=cU4PDvzVprZgR49Et/+uy8VNJztbob6mGe2LBNY4dWL40NvL/3G1lqxpceLmSG1N40 ARErqUyeW64Uvdi6FJdqLJ02Sxg5wjOO3k9GEO59rvTeLP5YuwRfEk25FoA9j4XXGtfw btE6szQ5OKq43R1H1EMjzVKnALLzC9OgykjQrHRErL4q1kY/5Uxcw1WEnOrAHSEbeXF9 24injh1+D7REa5fDD7hUHihxq40+AUONVd8OJgi9E6Md/rpczcolKtX2VKx+aZILISUv T3+1CEtEeSBgocJgZBnpw4FFOR8zXi8NrBlTnAM+3XPrLa0af6rnmQSU6pCO0o9qmbwT 9v0Q==
X-Gm-Message-State: AOAM531R1efl+x79L/ToFDRlcb4lnYNLWNZEoAY1kZ395ufaieb0j2ED NVvGG8+0VNVaf7g/LUHwxKYb4/I/hdNIsxdApek=
X-Google-Smtp-Source: ABdhPJycq1mhhKRnu4n8JNm5p4iaEQ6HGVi3yHxQvRKsgen4loDf1gOPzCc/ydrgDtKKGt1MR/ALDtEkC5ZYLkImG9Y=
X-Received: by 2002:a92:b11:: with SMTP id b17mr5001290ilf.257.1590707938188; Thu, 28 May 2020 16:18:58 -0700 (PDT)
MIME-Version: 1.0
References: <c0d1ee71781241f3a7ef524cbac1fc35@huawei.com>
In-Reply-To: <c0d1ee71781241f3a7ef524cbac1fc35@huawei.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 28 May 2020 19:18:47 -0400
Message-ID: <CABNhwV1_Y5xZjdXoVs621+TqTtNYvvy-Zve=v+Td-Fwnm9tnHA@mail.gmail.com>
Subject: Re: Multicast and Routing Headers//RE: Dumb question about routing headers
To: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
Cc: 6man <ipv6@ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Nick Hilliard <nick@foobar.org>
Content-Type: multipart/alternative; boundary="00000000000098e0b305a6bd8da8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vrzXEPztDZG0LcrrboS5tjzYZyE>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2020 23:19:01 -0000

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) <
xiejingrong@huawei.com> 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:ipv6-bounces@ietf.org] On Behalf Of Nick Hilliard
> Sent: Monday, May 25, 2020 5:23 AM
> To: Brian E Carpenter <brian.e.carpenter@gmail.com>
> Cc: 6man <ipv6@ietf.org>
> 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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD