Re: [72attendees] [tsv-area] FSA signalling issues

Joe Touch <touch@ISI.EDU> Wed, 17 September 2008 15:18 UTC

Return-Path: <72attendees-bounces@ietf.org>
X-Original-To: 72attendees-archive@ietf.org
Delivered-To: ietfarch-72attendees-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3AC03A6CAC; Wed, 17 Sep 2008 08:18:52 -0700 (PDT)
X-Original-To: 72attendees@core3.amsl.com
Delivered-To: 72attendees@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B510F3A6CAA; Wed, 17 Sep 2008 08:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XpXc0tZbQj7; Wed, 17 Sep 2008 08:18:47 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B6B903A6CB0; Wed, 17 Sep 2008 08:18:47 -0700 (PDT)
Received: from [128.9.176.37] (c1-vpn7.isi.edu [128.9.176.37]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m8HFHW1J011427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 Sep 2008 08:17:34 -0700 (PDT)
Message-ID: <48D11F8C.5050103@isi.edu>
Date: Wed, 17 Sep 2008 08:17:32 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: JOHN ADAMS <j.l.adams1@btinternet.com>
References: <243824.11987.qm@web86506.mail.ukl.yahoo.com>
In-Reply-To: <243824.11987.qm@web86506.mail.ukl.yahoo.com>
X-Enigmail-Version: 0.95.7
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: NSIS <nsis@ietf.org>, 72attendees@ietf.org, TSV Area <tsv-area@ietf.org>, IESG IESG <iesg@ietf.org>
Subject: Re: [72attendees] [tsv-area] FSA signalling issues
X-BeenThere: 72attendees@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for the attendees of IETF 72 meeting." <72attendees.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/72attendees>, <mailto:72attendees-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/72attendees>
List-Post: <mailto:72attendees@ietf.org>
List-Help: <mailto:72attendees-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/72attendees>, <mailto:72attendees-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: 72attendees-bounces@ietf.org
Errors-To: 72attendees-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



JOHN ADAMS wrote:
> Hi Lars,
>  
> and thank you.
>  
> A fundamental issue that I need help or guidance on is this question:
>  
> In IPv6 it is my impression (perhaps I am wrong) that there is an
> architectural principle. It is that any indications designed expressly
> to be read by a network node should b carried as an option field rather
> than in the data portion of the packet.

This is a general layering principle, and applies to all protocols
(i.e., signals for layer N should appear in the header for layer N).
Furthermore, signals in encrypted packets would not be accessible.

> If FSA signalling were to comply with that principle, it would need a
> new option code.
>  
> On the other hand, if FSA signalling packets only contained FSA
> signalling messages and could be recognised b network nodes by, for
> example, an EXP codepoint, then things could work another way. That is,
> the signalling packets are added as an unencrypted sub-stream to a flow,
> and the signalling is contained in the data portion of the packet.

I'm guessing that an EXP codpoint means MPLS; if so, then the signal
isn't at the same layer as the mechanism (presuming FSA is an IP
mechanism). Again, this mechanism seems like it would fail when IPsec is
used, because IPsec can't leave a portion of a given flow unencrypted.
Any header info that would cause IPsec to treat packets differently
(i.e., encrypt vs leave unencrypted) could be used by routing to forward
the packets differently - which destroys the path-coupling you need to
make FSA work (see Roland's note).

The solution that appears to support path-coupling best is using an IP
option. Note that even then, an (albeit goofy) policy could distinguish
forwarding entries based on option information (it seems like just about
everything else has been used for policy routing, including [!]
transport info).

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjRHtUACgkQE5f5cImnZrs72ACcCGdqf0pePTYzUWqXowcbpngz
LkoAoPH0a9NuysOi1YJ/9DTVfMnjP1as
=FPlc
-----END PGP SIGNATURE-----
_______________________________________________
72attendees mailing list
72attendees@ietf.org
https://www.ietf.org/mailman/listinfo/72attendees