IETF Logo Mail Archive

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

Jouni Korhonen <jouni.korhonen@broadcom.com> Thu, 25 May 2017 22:02 UTC

Return-Path: <jouni.korhonen@broadcom.com>
X-Original-To: detnet-dp-dt@ietfa.amsl.com
Delivered-To: detnet-dp-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477A9127B5A for <detnet-dp-dt@ietfa.amsl.com>; Thu, 25 May 2017 15:02:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 3DLqZynHE3kX for <detnet-dp-dt@ietfa.amsl.com>; Thu, 25 May 2017 15:02:12 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 290C8129B77 for <Detnet-dp-dt@ietf.org>; Thu, 25 May 2017 15:02:12 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id u75so186952320qka.3 for <Detnet-dp-dt@ietf.org>; Thu, 25 May 2017 15:02:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SscZA+wCM7SRG0m69kEOK4HrJXKSz6lKc44+QTaYVbY=; b=e5gobRLUE+bxm2lu3f1Kr0Dd1CVpXlaaq30LKWHz08wgEekgqsd19T2nmBcC9JXpI6 tA8NHCA/4QNdQDpUBuS7LsIwYs9DR5n2/UHEqIRNWo90mlWon6tckTJRV+a11qlWesY2 XYPXF6YbUVlqtHGC8Rg3vXyiwbO653Cw3wDag=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SscZA+wCM7SRG0m69kEOK4HrJXKSz6lKc44+QTaYVbY=; b=aRiSIqje6duZoCSECyo78QwbDHz7envfcBdVKJ5Y53sJESQFD1Z1RCX/r8u3QUDunF ln93IPtRgq2rJBuoQwZYGuKgYYB8aPN8JtpM7lXGr0Mn1jaDmdEIDK65eT25bdp/yVwz JXaeeEOuK3jZWDlWsI/pa+n3s9Y8IbNwvwnwHEtD0vf5pZSN1KGZAu7dMvdrGSyKnIPR hz2PYpwBnH1omF9P7XkLvWPLvnKnC6vdu0pPsc6ZUSoRey2mAjrtFINZtu2oXpE+5lFm GV3sTooJZ1djxjkOtpZzvf2eiv2eNf6wRU2dvDpbC0TfnmVtFTJ0x0NDiwsAsEBfm+2B TSOg==
X-Gm-Message-State: AODbwcAYHt3LnOSaNRTCMVlmV0P7flubJOMlbrvugXl5JrknJ1/Y6sfn CeOCEvajdz8ryj4H
X-Received: by 10.55.114.4 with SMTP id n4mr37134142qkc.259.1495749731171; Thu, 25 May 2017 15:02:11 -0700 (PDT)
Received: from [192.168.89.94] ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id n19sm5518200qkn.66.2017.05.25.15.02.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 15:02:10 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jouni Korhonen <jouni.korhonen@broadcom.com>
In-Reply-To: <DBXPR07MB128599719F40557B420E3E5ACFF0@DBXPR07MB128.eurprd07.prod.outlook.com>
Date: Thu, 25 May 2017 15:02:08 -0700
Cc: "Detnet-dp-dt@ietf.org" <Detnet-dp-dt@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <749A92ED-8363-4B74-B508-177160D52BD8@broadcom.com>
References: <7A8644F8-9A31-44FC-8561-C3D2B48FB356@broadcom.com> <DBXPR07MB128599719F40557B420E3E5ACFF0@DBXPR07MB128.eurprd07.prod.outlook.com>
To: =?utf-8?Q?Bal=C3=A1zs_Varga_A?= <balazs.a.varga@ericsson.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/62zI2tZeLhogDL6pDnXVs0NGuK4>
Subject: Re: [Detnet-dp-dt] IPv6 and multicast
X-BeenThere: detnet-dp-dt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DetNet WG Data Plane Design Team <detnet-dp-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet-dp-dt>, <mailto:detnet-dp-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet-dp-dt/>
List-Post: <mailto:detnet-dp-dt@ietf.org>
List-Help: <mailto:detnet-dp-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet-dp-dt>, <mailto:detnet-dp-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 May 2017 22:02:14 -0000

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
+1-408-391-7160



> On May 25, 2017, at 4:35 AM, Balázs Varga A <balazs.a.varga@ericsson.com> 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:detnet-dp-dt-bounces@ietf.org] On Behalf Of Jouni Korhonen
> Sent: 2017. május 24. 23:55
> To: Detnet-dp-dt@ietf.org
> 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
> +1-408-391-7160
> 
> 
> 
> _______________________________________________
> Detnet-dp-dt mailing list
> Detnet-dp-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt

v2.8.7 | Report a Bug | By Email