Re: [tsv-area] FSA signalling issues

Joe Touch <[email protected]>
Newsgroups gmane.ietf.nsis
Message-ID <[email protected]>
-----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-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.