Subject: Re: [tsv-area] FSA signalling issues

From: JOHN ADAMS <[email-masked]>
Date: Wed, 17 Sep 2008 12:09:04 +0000 (GMT)

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.

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. FSA nodes would then always look there (the data part of the packet) for signalling content. Non FSA nodes would simply forward the packet.

These two alternatives require less or more agreement within this community. In my editorial role on Q.flowstatesig, I have invited contributions on this topic with the aim of resolving this by the time the ITU-T SG11 meets again next January.

My preference would be for a new option code.

Regards,

John

----- Original Message ----
From: Lars Eggert <[email-masked]>
To: ext JOHN ADAMS <[email-masked]>
Cc: [email-masked]; TSV Area <[email-masked]>; NSIS <[email-masked]>; IESG IESG <[email-masked]>; monique morrow <[email-masked]>; Scott Bradner <[email-masked]>
Sent: Tuesday, 16 September, 2008 3:38:30 PM
Subject: Re: [tsv-area] FSA signalling issues

Hi, John,

thanks for promptly following up on some of the questions that arose  
following your presentation at TSVAREA in Dublin. I encourage the  
relevant working groups to continue this discussion with you in order  
to more fully evaluate how flow-state aware forwarding intersects with  
the broader Internet architecture.

Thanks,
Lars

On 2008-8-27, at 0:23, ext JOHN ADAMS wrote:
> I gave a talk at Dublin in the Transport Area Open meeting. The  
> subject was developments
> at the ITU-T on Flow State Aware (FSA) standardisation.
>
> A question raised at the IETF was (roughly) "why isn't a new  
> extension of RSVP being proposed
> to accommodate the requirements of FSA signalling?"
>
> I attach an intial response to that question in the form of an  
> issues list that will also be proposed as
> a new Appendix of the draft ITU Recommendation Q.flowstatesig. The  
> conclusions of this first
> analysis are that:
> - it is an aim that we try our hardest to fit within the preferred  
> architectural framework of RSVP
> - however there are a number of challenging issues and, since that  
> is the case, the preferred approach
>    is to keep other options open.
>
> Please get back to me with issues that will help the continued  
> progress of FSA at the next IETF
>
> Regards,
>
> John<RSVP and FSA compared.doc>

---

From: Roland Bless <[email-masked]>
Date: Wed, 17 Sep 2008 16:11:11 +0200

Hi John,

JOHN ADAMS wrote:
> 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.
>  
> 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. FSA
> nodes would then always look there (the data part of the packet) for
> signalling content. Non FSA nodes would simply forward the packet.

As an NSIS WG member, I see many parallels to the work we have
done in NSIS. GIST (http://tools.ietf.org/html/draft-ietf-nsis-ntlp)
seems to perform the interception and signaling
peer discovery part that you are looking for. We used a
Router Alert Option (see RFC2711 for IPv6 RAO)
for the signaling packet interception purpose
before, but due to IESG requirements this will be defined as an
experimental option. After quickly browsing through Y.2121, you
seem to call "in-band signaling" what we call "path-coupled" signaling:
the signaling packets will follow the flow's data path. (To me in-band
would mean in data packets). That is exactly what NSIS signaling
is providing. So currently, I don't see a reason, why
NSIS signaling shouldn't be a good match for your FSA signaling
solution.

> These two alternatives require less or more agreement within this
> community. In my editorial role on Q.flowstatesig, I have invited
> contributions on this topic with the aim of resolving this by the time
> the ITU-T SG11 meets again next January.
>  

Not clear to me, whether you really need such a new option for
your solution. Unfortunately, I couldn't attend the last IETF meeting,
so I missed your presentation and couldn't ask clarifying questions
this way...

Regards,
 Roland

---

From: Joe Touch <[email-masked]>
Date: Wed, 17 Sep 2008 08:17:32 -0700

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

> 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

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 17 Sep 2008 11:31:07 -0400

Can at least 72attendees be withdrawn from this thread ? I see no  
reason to get each message on that list, nor
to get them all multiple times. Likewise, this does not seem like an  
IESG issue to me.

Regards
Marshall

On Sep 17, 2008, at 11:17 AM, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> JOHN ADAMS wrote:
>> Hi Lars,
>>
>> and thank you.
>>
> -----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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/72attendees