Re: [tsv-area] FSA signalling issues

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 protected]>
To: ext JOHN ADAMS <[email protected]>
Cc: [email protected]; TSV Area <[email protected]>; NSIS <[email protected]>; IESG IESG <[email protected]>; monique morrow <[email protected]>; Scott Bradner <[email protected]>
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>

_______________________________________________
nsis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nsis