Re: [tsv-area] FSA signalling issues

Hi John,

JOHN ADAMS wrote:
> 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.

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.
>  
> My preference would be for a new option code.

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