Re: [Roll] Transit vs. Target in P DAO

Rahul Jadhav <rahul.ietf@gmail.com> Wed, 23 September 2020 15:16 UTC

Return-Path: <rahul.ietf@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DAA3A0EFD for <roll@ietfa.amsl.com>; Wed, 23 Sep 2020 08:16:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 o3ncVKiaHLlq for <roll@ietfa.amsl.com>; Wed, 23 Sep 2020 08:16:56 -0700 (PDT)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 8063E3A121B for <roll@ietf.org>; Wed, 23 Sep 2020 08:16:34 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id gx22so163164ejb.5 for <roll@ietf.org>; Wed, 23 Sep 2020 08:16:34 -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; bh=VOTAQIj+eAslvrZPRSt/j8UCy6doXtEOnhl2ymS47l8=; b=f93i0AZPdYFxe2QmipKgyj3knMNgGhxGIi3/aqrAqpyPOkCLXv4CwuFtj4WKph2Wpj IfH405wa4ziIoJA0PQ3WGuVMiof0Kp9MUOG5KOjP1tZySffj59nMjY4+ZrWdXORiEQPd IsZ73IpbvDQqszSP9OFL4MNc8HT2h5IB/opFpYFYbFPDOlpf04U5zTT8RpDQDdWYyIGg QoNJqvU7BAIWEDlWNUa03sKJmVx5WjJtRFwzdF6cU9iPwr6k3WtMBXHZRuyGfewI008R BI1H4nx4rX/4AXbf312npVLiQ8HihnZKtjy3t6L87fQ7QVgOnuxmLdiLd3wVVwJfJ451 wplw==
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; bh=VOTAQIj+eAslvrZPRSt/j8UCy6doXtEOnhl2ymS47l8=; b=OeyLd4fqzDWQ7cH2mO7/hnbkK4K21otSELic7OHJC7mOd+26kwa1EvRuLxeSj6I8K9 ufHABs8WcKI245cTi5n2vYX7T0SdbWFwLpdEVNOmrtc/11+Qp8UMOh3lpgM6AgDOUlPM m8EZ9vO73OEBciRY3CyiWVP2XYB9WTZp0ZN/twtOmb3DPSVAFu8q76Ea5iaI7sLN0t2f Omqr5XLbfb4/Xv0VtFhm2mYyKPLY1JRE3c5MX1gfmGfaZNk6E9Go1XOlcZBvTwq8i0bn ZRdM+Q6vIrcst26kFbnqf4koDaTbvLJsDRMT3NkYQDHSy6O/MCX+DAojL75km5fCRMik DsZA==
X-Gm-Message-State: AOAM530F8NA3oO2i42aupn3TnzbwlYesIUzYaD/hXE/17G0c9Yq9Xqd/ S8yRvl790hANcCv2mcU3wM9bzb7CGSh3Gzo2PHpJaZrH+7JfHA==
X-Google-Smtp-Source: ABdhPJx8vhhMzcpua145w/017ba6UfEmPIKgknwumFUdpK1xra4tNuoTCTKRCVua81QRnFpLbFVjShWhBDxNu8050tY=
X-Received: by 2002:a17:906:1f94:: with SMTP id t20mr88049ejr.493.1600874192773; Wed, 23 Sep 2020 08:16:32 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR11MB356579DFCCC250A2BAFCF206D83B0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB356579DFCCC250A2BAFCF206D83B0@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Rahul Jadhav <rahul.ietf@gmail.com>
Date: Wed, 23 Sep 2020 20:46:21 +0530
Message-ID: <CAO0Djp0-tQTQEH0t8AL31O3omiJ-A_EtYicNwsj-tGPyGNwCOQ@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000097240b05affc91de"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/J3Qop6-zKaOqKRcSaYlEPZUSsmY>
Subject: Re: [Roll] Transit vs. Target in P DAO
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2020 15:16:58 -0000

Hi Pascal,

I have a few questions in the context (with respect to the problem
statement, not proposals):

Currently, the draft allows the Root to send multiple RTOs which could
contain the egress target and all the (immediate) children and siblings.
The VIO option list would contain all the hops on which to install these
target routes. Doesn't this already handle the problem statement you
mentioned? Using this the root can install routers not only to the egress
but also to its immediate children, isn't it?

Is the point to not install the route on behalf of egress but only for the
egress's children/siblings? Is this the objective to achieve?
It would be great to have a sample topology to base this discussion on.

One another point: The draft talks about "serial Track" .. is that
synonymous to the "serial path" you mentioned in your mail. Does serial
Track indicate a track with a single projected segment? Would be better to
have this term described in the terminology section in the doc. Thanks.

Best,
Rahul

On Tue, 22 Sep 2020 at 16:35, Pascal Thubert (pthubert) <pthubert=
40cisco.com@dmarc.ietf.org> wrote:

> Dear all ;
>
>
>
> Say we are building a serial path using P DAO: in that case,  we are
> building a tunnel from the Track Ingress to the Track Egress, where the
> Track is signaled in the packet by the local RPLInstanceID in the RPI and
> the destination IPv6 address. The outer header may also have a SRH in case
> of non storing P DAO.
>
>
>
> In the current version of the P DAO draft we use a RPL Target Option (RTO)
> to signal the Track Egress and the new Via options (CMOs) to indicate the
> hops. But say we do not want to reach the Tunnel egress but one of its
> children or siblings. How can we signal that these guys are reachable over
> the tunnel?
>
>
>
> Proposal A)
>
>
>
> If we want to be able to signal that, it could be more consistent with RPL
> to use:
>
> - one or more RTOs to indicate the targets of the route, can be any of the
> children and siblings
>
> - Exactly one Transit Information Option (TIO) to indicate the tunnel
> egress
>
> - then one VIO or one or more SRVIOs (as we currently do)
>
>
>
> The result would be that the Track terminates at the “Parent” indicated in
> the TIO but can be used to reach any of the children and siblings indicates
> as targets
>
>
>
> Proposal B)
>
>
>
> Maybe we want to signal that only certain DetNet Flows should be placed in
> the Track. In that case, The RTO is not sufficient and we’d need the
> 6tuple. If we take that path, we’d need to create a new Flow option that is
> a Flow descriptor, in which case we’d get
>
> - one or more Flow Options to indicate which flows  are encapsulated in
> the Track
>
> - Exactly one RTO  (as we currently do) OR Exactly one TIO (as in Proposal
> A) to indicate the tunnel egress
>
> - then one VIO or one or more SRVIOs (as we currently do)
>
>
>
>
>
> What do you guys think?
>
>
>
> Pascal
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>