Subject: [Tsvwg] Re: [Trigtran] TRIGTRAN BoF at IETF 56

From: Kacheong Poon <[email-masked]>
Date: Wed, 5 Mar 2003 21:32:57 -0600 (CST)

Included message from "Spencer Dawkins" <[email-masked]>:

>----
>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 [email-masked]).
>
>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 [email-masked],
>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.
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 6 Mar 2003 08:54:43 -0800 (PST)

Just a couple of points on Kacheong's note:

Spencer

> by the current Internet architecture?

No, this is actually a topic requested by some people who have
asked "what about links that aren't access links?" and similar
questions. It's just explaining why we excluded some topologies
from consideration.

> to the end points.  Signalling message seems to be a more

You may very well be correct, that we might think of a more
helpful name (although I note, tongue-in-cheek, that Signalling
for Transport/SIGTRAN seems to be previously occuppied - sorry,
Lyndon!)

> And using signals ("triggers") to do that can be one

This is my understanding also.

> on other mechanisms is not the appropriate thing to do.

I'm not sure that I've done a good job of making something
clear, so let me try here:

The framework draft Carl and I put together is (at most) one way
the problem might be addressed. I'm very clear in my mind that
it's not baseline for a working group draft, with as little
discussion as we've had on some of the approaches. 

If $TRIGTRAN (or a more suitable name) is chartered, I'd expect
the charter to include a more rigorous requirements document,
and I'd be asking for other frameworks (maybe not polling, but
I'm sure there's something! perhaps defining a standardized
mechanism for link-up, and end-to-end messaging beyond link-down
and link-up? but I'm getting ahead of where the discussion has
been, at least to date).

So, to be clearer than I have been in the past, Carl and I
aren't tied to a particular working group name, set of
requirements, or set of protocol mechanisms, at this time.
Please send text!

Thanks for your feedback, and for your suggestions on a detailed
way forward.

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg