IETF Logo Mail Archive

Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt

"Joe Hildebrand (jhildebr)" <jhildebr@cisco.com> Tue, 10 March 2015 21:16 UTC

Return-Path: <jhildebr@cisco.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC871A8A0F for <spud@ietfa.amsl.com>; Tue, 10 Mar 2015 14:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 1wTYVTOW61JF for <spud@ietfa.amsl.com>; Tue, 10 Mar 2015 14:16:24 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1761A8A1B for <spud@ietf.org>; Tue, 10 Mar 2015 14:16:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2350; q=dns/txt; s=iport; t=1426022183; x=1427231783; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FUu3RD8RxDQ4YkXmGuFdq1zJJFksFpBKydO2YlSz8ic=; b=BPm/RqKtcWfM4B0ogkz1k399r8XadwONBwkLCLGl+R2ekIdi0HV9CF5R Zi/9kosuUqrBEcHygV+ld8wWFd+YuT0IZ503qDrqSmFQzKpTvVdb0RYIe o72+2nCqrJw+C3riIO7yHD/TTfUNts+qicEJMpFrEjU/KEHPy7V1SzV9t U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C8CQCGXv9U/5pdJa1cgwaBLASDBr1viCcCHIEUTQEBAQEBAXyEEAEBBCMRQwIQAgEIGgImAgICHxEVBwkCBA4FiBsDEapClg0NhSgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGJdoJEgXczB4JoL4EWAQSOFoIDiBGBSoEajEmCUYNDI4ICHBSBPG+BRH8BAQE
X-IronPort-AV: E=Sophos;i="5.11,377,1422921600"; d="scan'208";a="130690408"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 10 Mar 2015 21:16:22 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2ALGMsg019649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 21:16:22 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 16:16:21 -0500
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: "spud@ietf.org" <spud@ietf.org>
Thread-Topic: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt
Thread-Index: AQHQWE9zJBDJbJdH6EupEdFNpjrMAJ0UoPsAgABspACAAXROAP//pOyAgABngoD//58rgA==
Date: Tue, 10 Mar 2015 21:16:21 +0000
Message-ID: <077EA8A3-8086-4F41-A782-49B36733AA97@cisco.com>
References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <CA+9kkMDSMMUByAMOc8gSyMajyKj0ZtZzmFPg+J7bz-6AYkFYhw@mail.gmail.com> <CAOdDvNrRcMCnWMzBvL0Do16mmiajeR4OJRx36cxnppuaD7+81w@mail.gmail.com> <C0A46E88-A9C2-4EB3-B7B6-2DE20D0B957A@cisco.com> <CA+9kkMDaWrvZM3b7G8FyuiHL0nRO=kWLHjqxQjPjxqtoa1Dq=w@mail.gmail.com> <CAOdDvNq3NMP6ynqXmfoaVStFpRjVq70ZupVqt6ZmZutdg96SaA@mail.gmail.com> <E72790FC-643B-4874-8B08-21CC4A1C1156@cisco.com> <CA+9kkMBrS4ipG+FeyGHXPCtBddCsixmc995e7ni8Si5QwCep9w@mail.gmail.com>
In-Reply-To: <CA+9kkMBrS4ipG+FeyGHXPCtBddCsixmc995e7ni8Si5QwCep9w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/15.8.0.150225
x-originating-ip: [10.24.66.71]
Content-Type: text/plain; charset="utf-8"
Content-ID: <01BD9CCEF5111E449174B14443560C2A@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/dDntjKWRqhClk6FSvZa-fRlGbE0>
Cc: Patrick McManus <mcmanus@ducksong.com>, Ted Hardie <ted.ietf@gmail.com>
Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2015 21:16:26 -0000

On 3/10/15, 3:02 PM, "Ted Hardie" <ted.ietf@gmail.com> wrote:


>​So, I don't think this is the right thing to do in a substrate.  You may want to build a protocol that can do this on top of the substrate's capabilities, but gating acceptance of the substrate on this particular use case seems to me unwarranted fate sharing.

I'll buy that argument.  One notch simpler would be "see-other-address", with some indication of whether your initial packet had been forwarded or not.

>If you want an application-layer protocol that can handle service handoff, information like "Z-15 has path to path information for tube-id N" as an advisory message may be useful.    But if Z-15 has a different IP address, as above, there is no guarantee that
> the path will remain the same; anything from ECMP on up may change it.

Agree.

>Call me old-fashioned (or make me one, even better), but I believe it is easier here to use anycast IP addressing for the source addresses 

Did you mean the responder's (server's?) address here?  "Source" is a little confusing to me.

>while allowing the tube-id to be used to dispatch to the right back end.  In an SDN world, you might not even need that
> to be in L, but in the baseline network elements matching tables.

That doesn't sound old-fashioned to me at all. (I hope this message becomes the top Google hit for "good old-fashioned SDN", for example)

I like the potential combinations of anycast, SDN, and tube-IDs as sub-addresses, though.  The responder probably needs to note the address that was used to reach it, and use that address as the source on it's outbound packets - sendmsg(2) allows for that on some systems.

-- 
Joe Hildebrand

v2.23.0 | Report a Bug | By Email