Re: GIST updated from todays IESG call

Hi Jerry and all,

Gerald Ash wrote:
> 1. IMO after 8 years of hard work on NSIS, the WG deserves more of an
> explanation for downgrading GIST to experimental than “the IESG was
> deadlocked”.  What is the *technical* explanation for why the IESG
> DISCUSS’s could not be resolved?  After several years of IESG review,

IMHO it's not the DISCUSSes that cannot be resolved. It's just
that the majority of IESG members have changed several times over the
long period, the WG chair has changed and major proponents of the NSIS
approach have left the IESG. Therefore, IESG people seem to have pulled
in different directions, esp. if you consider the RAO discussion.
We couldn't get it right from the beginning since some people said:
"Oh, please use RAO for interception" and others said "don't use it,
it's broken". For some people, RAO is an already deployed (but poorly
defined and badly implemented) means and more efficient than any other
alternative, for others it's not usable in a general scope and will
cause deployment problems. Any alternative, like the one specified
now, seems to be disliked also, because it's not very efficient to
process in the fast path. Gee, a *constructive* criticism or even
*help* from the IESG would be really appreciated.

> the main DISCUSS issue still appears to be how to detect GIST packets:
> RAO is unacceptable (although it did pass an earlier IESG review);
> port/magick is a “non starter”.  There is no proposed resolution offered
> in any of the DISCUSS comments.  Is there no acceptable way (to the
> IESG) to detect GIST packets?  We are not privy to the discussion that
> must have taken place.

> Request: Perhaps an IESG member could write a “majority opinion” to
> explain to the NSIS WG why this DISCUSS issue (and any others) could not
> be resolved.

I would go further: I think the IESG should really come up with a
*constructive* proposal how to resolve the issue. As I said: the WG
has done everything to get it right, but obviously the IESG has changed
too quickly before we could get it right. :-)
Furthermore, I want to mention that the path-coupled signaling MRM is
only *one* method. GIST is flexible enough to use others.

> 2. A couple of IESG comments cast doubt on the need/motivation for
> NSIS.  The NSIS BOF was held at IETF-50 (March 2001).  Several comments
> made at the BOF (documented at
> http://www.ietf.org/proceedings/01mar/index.html, search “nsis”)
> identify the perceived need for improvement in signaling protocols.  Bob
> Braden published an I-D proposing the 2-layer NSIS architecture at
> http://www.watersprings.org/pub/id/draft-braden-2level-signal-arch-01.txt
> (his CSTP became GIST).  An analysis of existing signaling protocols was
> published in RFC 4094 http://www.ietf.org/rfc/rfc4094.txt.   Surely much
> has changed over 8 years and problems may have been fixed and needs
> vanished thus nullifying the original motivation?
> 
> Request: Perhaps people with a long view could comment on the evolution
> of problems/needs over this 8 year period.

I still think that we need a flexible and new signaling solution and
that RSVP is not really well suited for many signaling applications
other than RSVP-TE.
GIST supports mobility, provides Session-ID and Peer-IDs, various
signaling routing methods, denial of service protection, flexible use of
different transports, and security features. I guess it's more the lack
of willingness to implement another signaling protocol into router
software.

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