Re: Compressed Routing Header idea

Gyan Mishra <hayabusagsm@gmail.com> Fri, 22 May 2020 14:10 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 1FEF53A0999; Fri, 22 May 2020 07:10:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.986
X-Spam-Level:
X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, HTTPS_HTTP_MISMATCH=0.1, 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 Ai4KaG1gPAye; Fri, 22 May 2020 07:10:32 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 665A03A0994; Fri, 22 May 2020 07:10:32 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id y17so8589693ilg.0; Fri, 22 May 2020 07:10:32 -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=5nL5Dn1RGnnPResE3W4IGdjlspjdvsjGgJD3KcYs9wo=; b=nkQb9ngnRpttYH3Yk1iiQBaEBnkWyUVKLftuYRzmtBweKxFPtxLLIx9Vj4qX5a5T8z 1baVJAThI+idn0wJOOxJ/hMAdwPIVsRwgqpLdjfsADt4iGBpOKfRy1dUHf4vXdL2to+F SBGwVca/2V+vBmt2UlbEJP2kmc2QRKXdwPdCXhgj04C870UGpfmwWzNPkem/Oy82cUH/ qOryYACxG3rg3Xl9iAUoZ2kP/y9gv0kA7jgG+bpZ5WOvgGdEVPrjZFv9BZxKg5jISSr0 N0sdHt/I1EZnC8+XL4VUpMOn5opHN0rUD96GAJ0yv5CLUx9NsKRTPhgwh87jQE52UTvK xusg==
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=5nL5Dn1RGnnPResE3W4IGdjlspjdvsjGgJD3KcYs9wo=; b=DmQxI8DWhJEXQWXwfVRON3Z7Qw/pQ97qDtTu0CqR7K+MoYF25SPd7Pa6R4ewcPRZhw +4z7AosU/qfggGgEx+PKOBFbmEcZbrwhuUDK73MTjq1N+jDCZ5Oum8IslrUbjkz4FX1E ai/+GvAIexDD4FNSN4pX5ltLuMlK5PKPQ2tGKwhmQV9M5RGUr5ajRpiSXUzcROGnfIJI SHQG5SAKoXEkRuFbcgmNJxXPYONwzGQmSZWuVLcd1KSddsubxb6IhqLwLxO+rlhiic+Q bNWpHs3SZceLCZgViGk9o+xUhAYNgu5K6r3YistTOnVa9HDSR/NY0E9/MXeJj1A93MXr NvVQ==
X-Gm-Message-State: AOAM533owN3HGvsPs/yfgk6+Bhaa823Zj4cAGmHpqzvm7HwA5ygoFIBK OXfnjw+dAnzQFrAL24sEk82+D4tWWOtbvpX/eKs=
X-Google-Smtp-Source: ABdhPJyYTvBMzlvWdMDZAIi7dsTZqxtG9VWIOE8LbMYkcKYr77pEJgMm9VtiRFxA9etLWWY4eGu89RJZogb96O6Xn5g=
X-Received: by 2002:a92:c948:: with SMTP id i8mr13746657ilq.258.1590156630648; Fri, 22 May 2020 07:10:30 -0700 (PDT)
MIME-Version: 1.0
References: <2a844eb431b346b8931196c5e21d33ae@boeing.com> <MN2PR11MB35654AC2F2C85717097DA6C6D8B80@MN2PR11MB3565.namprd11.prod.outlook.com> <e3c8e3a6e80047cd9033e48997e0bb99@boeing.com> <CABNhwV2RCii_e6H1L2BgoyqjzGOOWf6+=CN_KJc+KmH9eYZRgw@mail.gmail.com> <4af522c96b53457781e428432543e592@boeing.com> <DM6PR05MB6348D50CEDC3E2D502E943C6AEB70@DM6PR05MB6348.namprd05.prod.outlook.com> <9de501a671be4fc1a8a6210f56429fe4@boeing.com> <CALx6S35Co+XXzTY8=f19ksQLgfCMAfS9g29V9iN-URd9my9U+w@mail.gmail.com> <542fb2ad1d0943f99904986a48456013@boeing.com>
In-Reply-To: <542fb2ad1d0943f99904986a48456013@boeing.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 22 May 2020 10:10:19 -0400
Message-ID: <CABNhwV2CjMqy6PRdEogYpz8X3QrGSm2Hgwu+u0cAYLMpa+_b_Q@mail.gmail.com>
Subject: Re: Compressed Routing Header idea
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
Cc: 6MAN <6man@ietf.org>, IPv6 List <ipv6@ietf.org>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Ron Bonica <rbonica@juniper.net>, Tom Herbert <tom@herbertland.com>
Content-Type: multipart/alternative; boundary="0000000000001b6cd805a63d31ff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/YBVcN0z1MFniYr5o8kyhWmPbI7c>
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: Fri, 22 May 2020 14:10:35 -0000

Hi Fred

Replying to you original question regarding PSP.  So with SRv6 PSP is
enabled by default, however if the PSP option was disabled then the PSP
node will not remove the EH.  In that case the final destination USP node
will remove the SRH and deencap perform USD pseudocode and and forward to
L3 for processing.

Is that what you are trying to do - keep SRH intact in packet to final
destination?

Thanks

Gyan

On Fri, May 22, 2020 at 9:09 AM Templin (US), Fred L <
Fred.L.Templin@boeing.com> wrote:

> Hi Tom,
>
>
>
> >In your case, why not just encapsulate ip-ip with the routing header and
> have the decap point be the penultimate node?
>
>
>
> I want the packet to traverse N IPv6 Internets via standard IPv6 routing
> before
>
> the router in the N+1th IPv6 Internet performs IP-in-IP encapsulation to
> forward
>
> to the final destination. It is in the AERO spec if you wanted to have a
> look. Also,
>
> since I am doing segment routing within a mid-layer encapsulation header
> that is
>
> guaranteed not to have an AH it should be OK.
>
>
>
> Fred
>
>
>
>
>
> *From:* Tom Herbert [mailto:tom@herbertland.com]
> *Sent:* Thursday, May 21, 2020 6:52 PM
> *To:* Templin (US), Fred L <Fred.L.Templin@boeing.com>
> *Cc:* Ron Bonica <rbonica@juniper.net>; Gyan Mishra <hayabusagsm@gmail.com>;
> 6MAN <6man@ietf.org>; Pascal Thubert (pthubert) <pthubert@cisco.com>;
> IPv6 List <ipv6@ietf.org>
> *Subject:* Re: Compressed Routing Header idea
>
>
>
>
>
> On Thu, May 21, 2020, 6:44 PM Templin (US), Fred L <
> Fred.L.Templin@boeing.com> wrote:
>
> Hi Ron,
>
>
>
> What I am concerned with  is the case where the ultimate hop is over a
> very slow link
>
> (e.g., 100Kbps or less). Any form of compression can help, and compressing
> away a
>
> Routing Header could result in a small savings – but a savings nonetheless.
>
>
>
> So, why not just truncate it? The final destination won’t miss it and will
> never be
>
> aware that it was ever there in the first place.
>
> Fred,
>
>
>
> That's not guaranteed. For instance, if an AH is present then validation
> will break at the final destination if the RH was deleted or it otherwise
> modified in a non-conformant way. This is case of the ongoing discussion
> about whether intermediate nodes can insert, delete, or process extension
> headers is flight (RFC8200 states they cannot).
>
>
>
> In your case, why not just encapsulate ip-ip with the routing header and
> have the decap point be the penultimate node?
>
>
>
> Tom
>
>
>
> Thanks - Fred
>
>
>
> *From:* Ron Bonica [mailto:rbonica@juniper.net]
> *Sent:* Thursday, May 21, 2020 3:33 PM
> *To:* Templin (US), Fred L <Fred.L.Templin@boeing.com>; Gyan Mishra <
> hayabusagsm@gmail.com>; 6MAN <6man@ietf.org>
> *Cc:* IPv6 List <ipv6@ietf.org>; Pascal Thubert (pthubert) <
> pthubert@cisco.com>
> *Subject:* RE: Compressed Routing Header idea
>
>
>
> Fred,
>
>
>
> When a node decrements Segments Left to 0, it causes all subsequent nodes
> to ignore the Routing header. So, I don’t see a good reason to remove the
> Routing header. It will be ignored by all downstream nodes anyway.
>
>
>
>                                                           Ron
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Templin (US), Fred L <Fred.L.Templin@boeing.com>
> *Sent:* Thursday, May 21, 2020 4:00 PM
> *To:* Gyan Mishra <hayabusagsm@gmail.com>; 6MAN <6man@ietf..org
> <6man@ietf.org>>; Ron Bonica <rbonica@juniper.net>
> *Cc:* IPv6 List <ipv6@ietf.org>; Pascal Thubert (pthubert) <
> pthubert@cisco.com>
> *Subject:* RE: Compressed Routing Header idea
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi, just seeing this question now (below). The idea is that the router
> that processes
>
> the penultimate SID would “pair” it with the ultimate SID so that the
> penultimate SID
>
> is written as the final IPv6 destination while the ultimate SID (which may
> include an
>
> address and port number) is used as a destination for IPv6-in-IP
> encapsulation. So,
>
> the final hop router before the final destination would be the one to
> extract it.
>
>
>
> I had a somewhat related question – can the final hop router before the
> final
>
> destination delete the Routing Header before forwarding?
>
>
>
> Thanks - Fred
>
>
>
> Fred
>
>
>
> Curious what would be the particular application use case for variable
> compressed routing header to add ancillary info like port or other
> miscellaneous info.
>
>
>
>  I am guessing the final destination would have to extract the ancillary.
> In a connection the tcp or udp source is the same unless using RPC or an
> app using dynamic port allocation and want to save the port info somewhere
> else.
>
>
>
> https://datatracker.ietf.org/doc/draft-templin-6man-crh-variable/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-templin-6man-crh-variable/__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl9lvoN3y$>
>
>
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Mon, May 18, 2020 at 11:12 AM Templin (US), Fred L <
> Fred.L.Templin@boeing.com> wrote:
>
> Pascal, thanks I did not know about this but at first glance I do not
> believe RFC8138 fully
> satisfies what I need. First, I want to be able to support both left-side
> (most significant
> bits) and right-side (least significant bits) compression. Second, I want
> to be able to
> compress to the byte granularity for any length from 0 to 16 bytes. And,
> third, I want
> to be able to include an ancillary piece of information (e.g., an
> application port number)
> with each IPv6 address. So, I submitted a short draft showing the format
> that I would
> see as being flexible to support my use case and I think perhaps many
> other:
>
> https://datatracker.ietf.org/doc/draft-templin-6man-crh-variable/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-templin-6man-crh-variable/__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl9lvoN3y$>
>
> I did include a reference to RFC8138 - let me know your thoughts.
>
> Fred
>
> > -----Original Message-----
> > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
> > Sent: Monday, May 18, 2020 7:55 AM
> > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>; IPv6 List <
> ipv6@ietf.org>
> > Subject: RE: Compressed Routing Header idea
> >
> > Hello Fred:
> >
> > Are you aware of RFC 8138? See
> https://tools.ietf.org/html/rfc8138#section-5.1
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8138*section-5.1__;Iw!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0b3-Gbz$>
> > The addresses in the source route header can be compressed as follows:
> >
> > "
> >
> >      +-----------+----------------------+
> >      |   6LoRH   | Length of compressed |
> >      |   Type    | IPv6 address (bytes) |
> >      +-----------+----------------------+
> >      |    0      |       1              |
> >      |    1      |       2              |
> >      |    2      |       4              |
> >      |    3      |       8              |
> >      |    4      |      16              |
> >      +-----------+----------------------+
> >
> >                        Figure 7: The SRH-6LoRH Types
> >
> > "
> > You need multiple SRH-6loRH if you have different sizes to accommodate..
> >
> > Keep safe
> >
> > Pascal
> >
> > > -----Original Message-----
> > > From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Templin (US), Fred L
> > > Sent: lundi 18 mai 2020 16:04
> > > To: IPv6 List <ipv6@ietf.org>
> > > Subject: Compressed Routing Header idea
> > >
> > > Hi, I have a use case where some IPv6 addresses that would go into a
> routing
> > > header are more compressible than others and so I am wondering if some
> kind
> > > of "hybrid" compressed routing header would be possible.. For example,
> if one
> > > address can be compressed down to
> > > 16 bits, then include only those 16 bits; if a different address can
> only be
> > > compressed down to 32 bits, then include the 32 bits; if yet a
> different address
> > > cannot be compressed at all, then include all 128 bits. And, there may
> be many
> > > more sizes in between.
> > >
> > > RFC4191 Section 2.3 shows an example of how an IPv6 prefix/address can
> be
> > > compressed to a variable length. Essentially, a length byte followed
> by a
> > > variable-length prefix. That way there would still be "pretty good
> compression"
> > > albeit with an extra byte per prefix. And, it would be a generalized
> form that
> > > would only require a single routing header type value.
> > > How would it be if we did something like that?
> > >
> > > Fred
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0Q2OkFT$>
> > > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!ViLHxbEJqhubTR_jBFZ9qv59Xn3jPyPGQcTN33jDxZuo2nzpBinDu4TXl0Q2OkFT$>
> --------------------------------------------------------------------
>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: 301 502-1347
>
> Email: gyan.s.mishra@verizon.com
>
>
>
>
>
> --------------------------------------------------------------------
> 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