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-----