RE: [EXTERNAL] Embedding IP information in an IPv6 address (OMNI)

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Thu, 15 October 2020 23:27 UTC

Return-Path: <Fred.L.Templin@boeing.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 729053A0C99; Thu, 15 Oct 2020 16:27:12 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=boeing.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 M5doIqzoINMs; Thu, 15 Oct 2020 16:27:11 -0700 (PDT)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4093A0BA8; Thu, 15 Oct 2020 16:27:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09FNR8Nu027816; Thu, 15 Oct 2020 19:27:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602804428; bh=zQ5BSEHKM76W0RDBlLDvQjyX6b6n0WhTdgxx8ip4aX0=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Z6D6h+2rcCSBlctpIzUsnW0Yfi9FDZFYyneDvvfwuLtpNdxoC3LBXkGEAM4G7U9hV AWmF5V0x15sY1x3v3OFOarLoGmQerIb56HtGgq3Lc5NRsNJPPAJmbhZM4ifQ6651Cv xt8b9OgQI4SArSGxqOdPHYcGK5uEFdnBsUoG1BuGDtwxbYiEfzthJoYYP9w+kuqQje 9rSFCkgo+GABZngY4tNQh2A8KrvZZX+9QoJ2n0aoerFt/qnmkvqABShorsnHDMSr7L 4arg2oBAdPnBxzbwZgrIQyWNx7FjjQ3Hbku8nx9M4wZbfG0zNk/j3ncbWjXPnQu9Vz VacvB4Fpno2Qg==
Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09FNR3YK027791 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 15 Oct 2020 19:27:03 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Thu, 15 Oct 2020 16:27:02 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Thu, 15 Oct 2020 16:27:02 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Bob Hinden <bob.hinden@gmail.com>
CC: =?utf-8?B?T2xlIFRyw7hhbg==?= <otroan@employees.org>, IPv6 List <ipv6@ietf.org>, "atn@ietf.org" <atn@ietf.org>
Subject: RE: [EXTERNAL] Embedding IP information in an IPv6 address (OMNI)
Thread-Topic: [EXTERNAL] Embedding IP information in an IPv6 address (OMNI)
Thread-Index: AQHWo0qvG0cfNv1bmE28SdePcRf5nA==
Date: Thu, 15 Oct 2020 23:27:02 +0000
Message-ID: <00d2ef656354457885bf6f9c49907f1b@boeing.com>
References: <6664a427f0334468ac0b8cba75b37d03@boeing.com> <B5035814-3F27-4B81-A585-24F114DE5AEC@gmail.com> <423a090e400a4ca3960cee27364b1a16@boeing.com> <437F5B96-B744-4ABE-ABA7-F2A50EAB9035@gmail.com>
In-Reply-To: <437F5B96-B744-4ABE-ABA7-F2A50EAB9035@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 9DA32A089F9321B483A410C74818FB35BD4BCCFDBE1E36BFB2CD6CB2B7EAC7F82000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/X3AzxZfKAsSkzOO-TCKJL1r9cgg>
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, 15 Oct 2020 23:27:13 -0000

Bob,

> -----Original Message-----
> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> Sent: Thursday, October 15, 2020 4:20 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Bob Hinden <bob.hinden@gmail.com>om>; Ole Trøan <otroan@employees.org>rg>; IPv6 List <ipv6@ietf.org>rg>; atn@ietf.org
> Subject: Re: [EXTERNAL] Embedding IP information in an IPv6 address (OMNI)
> 
> Fred,
> 
> > On Oct 15, 2020, at 4:08 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> >
> >>>
> >>
> >> I think this is a bad idea, that is trying to make a set of networks with a whole range of characteristics (i.e., speed, delay, drop rates,
> >> errors, cost, etc.) look like a single "big bridged campus LAN”.   Most people have stopped buildings “big bridged campus LANs” a
> long
> >> while ago, what your are proposing is much harder given the different characteristics of the networks you mention.
> >
> > I think you may have gotten a polar opposite read from what the OMNI technology
> > is all about - OMNI is about diversity; not homogeneity. The OMNI "multilink" concept
> > in particular is about accommodating all manners of data links having diverse properties
> > and characteristics, while presenting the best possible performance profiles to mobile
> > nodes in the face of dynamically changing conditions. The "bridged campus LAN"
> > concept is not a physical thing; it is a virtual one that allows nodes to communicate as
> > single-hop neighbors at the IP layer while their underlying data link properties may be
> > varying dynamically. This discussion now starts to enter into the realm of what we have
> > been debating in the ICAO working groups for the past several years, and has motivated
> > the design based on expert input from the aviation community. And, what is good for
> > aviation also turns out to be good for the worldwide mobile Internet for any manners
> > of mobile nodes.

To clarify what I meant when I said "L2 bridge", I was actually referring to plain IPv6 routers
that operate on the RFC2463 encapsulation header *at a layer below IP*. These routers run
plain old BGP and exchange SLA routes. But again, this happens at a layer below the IP
layer seen by the transports and applications.

> I think I understand what you are trying to do.  I just don’t think this will work, some problems are best not solved at L3.   As I outlined
> below, I think the transport layer (and probably application layer) will also need to be involved.

We are not solving this at L3; we are solving it at the adaptation layer below the IP
layer seen by the transports and applications. It is called the OMNI Adaptation Layer.
And, if you want to see it working I would be happy to demonstrate with real
running code.

Thanks - Fred

> Bob
> 
> 
> >
> > Fred
> >
> >> I think a better approach is to treat the networks separately and use transport protocols techniques to use them efficiently
> separately
> >> and concurrently.   Likely the transport protocols and applications above them will need to be aware of the underlying networks.
> >>
> >>>
> >>>>> About changes to IPv6, all that has been asked so far is for the OMNI
> >>>>> interface to define its own link-local addresses - having that, none of the IPv6
> >>>>> standards like RFC4861, RFC8200 etc. are changed.
> >>>>
> >>>> The OMNI draft updated RFC1191, RFC3879, RFC4291, RFC4443, and RFC8201.
> >>>
> >>> When I said "all that has been asked for *so far*", I meant in terms of what has
> >>> been discussed on the list up to now. Up to now, the only aspects of OMNI we
> >>> have touched on are the LLAs and SLAs, and it is only RFC3879 and RFC4291 that
> >>> are in question. So, until we get around to discussing the OAL let's put the other
> >>> RFCs aside for now.
> >>
> >> I disagree, you are clearly proposing a lot of changes, discussing them separately doesn’t change that.
> >>
> >> Bob
> >>
> >>
> >