Re: [Trigtran] TRIGTRAN BoF at IETF 56

[Kacheong Poon <[e-mail]>]

Included message from "Spencer Dawkins" <[e-mail]>:

>----
>Carl and I will be hosting a second TRIGTRAN BoF at IETF 56.
>
>The working copy of the BoF Agenda is available below (and is 
>being sent to [e-mail]).
>
>We will present issues discussed in the Framework draft, available at 
>http://www.ietf.org/internet-drafts/draft-dawkins-trigtran-framework-00.txt.

I believe there will be a lot more comments if this announcement
is also made to the tsvwg mailing list.  So I cc this reply to
that list.

>This BoF is intended to lead to the formation of a TRIGTRAN working group,
>so most of our time together will be dedicated to answering a series of
>questions to figure out if we're doing the right thing.
>
>Please plan to attend and be opinionated.
>
>Spencer, for Spencer and Carl
>
>p.s. The Problem Statement draft will be available at
>http://www.ietf.org/internet-drafts/draft-dawkins-trigtran-probstmt-01.txt,
>as soon as it's announced. The only changes we've made were updates to
>reflect constraints in the minimal architecture model that we adopted
>at IETF 55.
>
>p.p.s. The meeting minutes from the first BOF are available at
>http://www.ietf.org/proceedings/02nov/239.htm
>
>p.p.p.s. My e-mail address is changing to [e-mail],
>effective immediately.

....

>AGENDA:
>
>- Agenda Bashing								10 minutes
>
>- Issues identified in TRIGTRAN Framework draft			20 minutes
>	Constraints of Minimal Architecture

Or is it really the constraint of the current Internet
architecture?  Many researchers are already looking at
the next generation Internet and this is probably one
area where they will work on.  So is it really reasonable
for this proposed WG to solve an architecture problem?
Or is what people actually want something not constrained
by the current Internet architecture?

IMHO, trigger is the wrong name to use.  Pardon my English,
but to me, trigger means an immediate response to a certain
event.  But maybe the only thing we can do is to provide
some form of signal, does not necessarily need to be immediate,
to the end points.  Signalling message seems to be a more
appropriate name.

Anyway, it seems to me that what people want here is to have a
way for transport to find out a little bit more about the network
so that it can react more effectively to different network events.
And using signals ("triggers") to do that can be one mechanism.

Should a TRIGTRAN WG be formed now if there can be other mechanisms
to do that?  Should we evaluate them before making a decision on
which one to use, signalling being one?  Another obvious mechanism,
as opposed to active signal, is polling by transport on some
network elements.  I am not suggesting that it is better or worse
(probably worse (-:) than active signal.  But I believe setting
up a WG at this point without even some discussion and evaluation
on other mechanisms is not the appropriate thing to do.

>	Form of Registrations
>	Form of Notifications
>	Allowable Responses to Notifications
>	Deployment Issues
>	Preliminary Security Assessment
>
>- Questions leading to a WG charter					50 minutes

It seems that this should be the first agenda item.  The reason
is that if people don't even think that signal ("triggers") is
the right mechanism to achieve what we want, it does not
make sense to discuss a framework document.  So maybe the two
items should be swapped?

>	- is an end-to-end solution sufficient, 
>		or do we really need help from the network?

Or as mentioned above, can we have reasonable help from
the network without some modifications to the current Internet
architecture?  Is a non-e2e solution sound?

>	- are explicit messages required?
>	- can we agree on the list of canonical triggers?

I believe the above question should be broken up.  We should
first ask if there can be an agreed list of generic network
events that we want transport to be aware of.  And then we
can look at the list and find out which one can be most likely
"told" to transport.  Lastly, we should find the most
appropriate mechanism to do that given the current Internet
architecture.  A WG can be formed to achieve that.  The above
framework document can then be used as one of the documents
describing one mechanism being investigated.

I think that may be a more appropriate WG to be formed instead
of a TRIGTRAN WG.  I will not go to the IETF, so please count my
vote as a NO to the formation of a TRIGTRAN WG, if that question
will actually be asked.

Or is the above problem still a research issue at this moment?

>	- can these triggers be generated by subnetwork technologies?
>	- can we agree on a list of reasonable responses?
>	- who would use TRIGTRAN notifications? (OMA, SIP, etc.)?
>	- who would implement a reasonable TRIGTRAN specification?
>
>- Next Steps leading to a TRIGTRAN working group		40 minutes
>	Volunteers
>	Documents
>	Timeline
>	Land Mines
>----


							K. Poon.
_______________________________________________
Trigtran mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/trigtran