Subject: Re: IANA Considerations for RSVP
From: Curtis Villamizar <[email-masked]>
To: Bala Rajagopalan <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Mon, 27 Jan 2003 15:04:11 -0500

spamassassin -r
d
ajagopalan writes:
> Dimitri:
> 
> I don't recall the particular Yokohoma consensus
> you mention, although what you say could very well
> have happened. All I do remember is the total lack
> of interest in the audience about most of the drafts
> discussed. 
> 
> My gripe is basically about the lack of a process in
> the IETF to rigorously and constructively evaluate 
> on-going work outside. The liaisons
> obviously haven't worked very well, and the efforts
> by various people to bring in contributions on OIF
> and ASON work have been met with cynicism. This is
> the reason why there's a scramble at the last minute
> to "right" things. 
> 
> Going forward, I hope the IETF makes it mandatory
> to have outside work examined in the relevant WGs with
> the same seriousness as regular WG items (or assign
> evaluation teams, like design teams). This would bring
> overall sanity and be beneficial for all groups.
> 
> regards,
> 
> 
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Pl.
> Ocean Port, NJ 07757
> USA
> Ph: +1-732-923-4237
> Email: [email-masked]

Any organization or representative may sumbit an internet draft and it
may be given consideration by the WG.  It carries no more weight than
any other individual WG submission.

If the WG is not interested, that is the end of it.

Curtis

Delivery-date: Mon, 27 Jan 2003 12:34:51 -0800
From: Bala Rajagopalan <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: IANA Considerations for RSVP 
Date: Mon, 27 Jan 2003 15:29:46 -0500

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]

> > Going forward, I hope the IETF makes it mandatory
> > to have outside work examined in the relevant WGs with
> > the same seriousness as regular WG items (or assign
> > evaluation teams, like design teams). This would bring
> > overall sanity and be beneficial for all groups.
> > 
> 
> Any organization or representative may sumbit an internet draft and it
> may be given consideration by the WG.  It carries no more weight than
> any other individual WG submission.
> 
> If the WG is not interested, that is the end of it.
> 
> Curtis
>

This is precisely the problem. The above mode of operation is fine
when considering work to be done within an IETF WG. But it
results in the sort of grumbling we heard recently when external 
orgs do independent work. There needs to be a process to
look at external work more rigorously (or, ignore "uninteresting" 
work completely and not worry about IETF protocol changes elsewhere).

Bala

Delivery-date: Mon, 27 Jan 2003 07:33:18 -0800
Date: Sun, 26 Jan 2003 20:23:00 -0800 (PST)
From: Bob Braden <[email-masked]>
To: [email-masked]
Subject: Re: [Rsvp] Re: IANA Considerations for RSVP
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

David,

I would like to mention that I thoroughly support all you have been
saying in this thread -- and you have been saying it forcefully and
well.

Bob Braden

Delivery-date: Mon, 27 Jan 2003 07:33:10 -0800
Date: Sun, 26 Jan 2003 20:17:26 -0800 (PST)
From: Bob Braden <[email-masked]>
To: [email-masked]
Subject: Re: [Rsvp] Re: IANA Considerations for RSVP
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

  *> 
  *> On Thu, Jan 23, 2003 11:06:53AM -0500, Brian Hassink allegedly wrote:
  *> > Didn't the IETF set the precedent by extending RSVP from an IntServ
  *> > protocol to an MPLS protocol?
  *> 
  *> Check the documentation.  RSVP is not an intserv protocol.  It's
  *> (potentially) used by intserv.  It's also used for other things.
  *> _______________________________________________

Scott,

Weeellll, RSVP *was* designed as the signaling protocol for int-serv.
Since we believe that generality and extensibility are Good Things,
we made it general and extensible.  (Again, perhaps a mistake, in
retrospect ... ;-( )

Bob

Delivery-date: Mon, 27 Jan 2003 07:33:02 -0800
Date: Sun, 26 Jan 2003 20:10:38 -0800 (PST)
From: Bob Braden <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [Rsvp] RE: IANA Considerations for RSVP
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

  *> David
  *> 
  *> You wrote:
  *> 
  *> > In other words, these groups seem to want to forcibly change 
  *> > RSVP into a protocol that more closely resembles some other 
  *> > protocol that they're more intimately familiar with.
  *> 
  *> My recollection of history brings me to a little paraphrasing of
  *> your statement:
  *> 
  *> - In other words, the IETF seemed to want to forcibly change 
  *> - transport networking into a thing that more closely resembles 

Sorry, I am unfamiliar with the term "transport networking".  Could you
explain it please?

Thanks,

Bob Braden

  *> - some other network that they're more intimately familiar with.
  *> 
  *> If you agree, let's than put the pots and the kettles where they
  *> belong and join forces on a constructive way forward. That is
  *> in our common interest.
  *> 
  *> Leen Mak.
  *> 
  *>  
  *> _______________________________________________
  *> Rsvp mailing list
  *> [email-masked]
  *> http://mailman.isi.edu/mailman/listinfo/rsvp
  *> 

Delivery-date: Mon, 27 Jan 2003 07:32:54 -0800
Date: Sun, 26 Jan 2003 20:45:04 -0800 (PST)
From: Bob Braden <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [Rsvp] RE: IANA Considerations for RSVP
Cc: [email-masked], [email-masked], [email-masked]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

  *> 
  *> Going forward, I hope the IETF makes it mandatory
  *> to have outside work examined in the relevant WGs with
  *> the same seriousness as regular WG items (or assign
  *> evaluation teams, like design teams). This would bring
  *> overall sanity and be beneficial for all groups.
  *> 

This is one good choice -- the other is to clearly fence off the
non-IETF extensions with a surgeon general's warning.

Bob Braden

  *> regards,
  *> 
  *> 
  *> Bala Rajagopalan
  *> Tellium, Inc.
  *> 2 Crescent Pl.
  *> Ocean Port, NJ 07757
  *> USA
  *> Ph: +1-732-923-4237
  *> Email: [email-masked]
  *> 
  *> 
  *> > -----Original Message-----
  *> > From: [email-masked]
  *> > [mailto:[email-masked]]
  *> > Sent: Friday, January 24, 2003 2:48 AM
  *> > To: Bala Rajagopalan
  *> > Cc: 'David Charlap'; Brian Hassink; Bob Braden; [email-masked];
  *> > [email-masked]; [email-masked]; [email-masked]; [email-masked];
  *> > [email-masked]; [email-masked]; [email-masked]
  *> > Subject: Re: IANA Considerations for RSVP
  *> > 
  *> > 
  *> > bala,
  *> > 
  *> > your assertion "none of the IETF WGs (specifically, CCAMP)
  *> > have shown any interest in discussing the (informational)
  *> > drafts about ASON or OIF at any length." is not true
  *> > if you were really participating to the ccamp wg meeting
  *> > in yokohama you would have heard that the consensus was
  *> > (as requested by the chair) to send a ason functional 
  *> > spec to the ccamp wg in order for the latter to define
  *> > the needed extensions - the proposal was to achieve 
  *> > a first cut of these extensions in november '02 but
  *> > nothing happened everything goes to "informational"
  *> > 
  *> > the reason why suddenly things gets tunneled until
  *> > reaching the current situation are still unclear for
  *> > me (one of the explanation i have is the clear rambo
  *> > competition played by the oif in backing up these 
  *> > extensions instead of letting the corresponding 
  *> > responsibility to the appropriate body i.e. the ietf)
  *> > 
  *> > thanks,
  *> > - dimitri.
  *> > 
  *> > Bala Rajagopalan wrote:
  *> > > 
  *> > > Hello,
  *> > > 
  *> > > First, the IETF has been instrumental in putting
  *> > > IP/MPLS protoocols for use in the optical control plane.
  *> > > You can't now complain that RSVP is being indiscriminately
  *> > > used for purposes other than intended. To quote
  *> > > a cliche, you can't have the cake intact and modify it
  *> > > too.
  *> > > 
  *> > > Second, none of the IETF WGs (specifically, CCAMP)
  *> > > have shown any interest in discussing the (informational)
  *> > > drafts about ASON or OIF at any length. Serious
  *> > > consideration by the WGs should lead to an examination
  *> > > of the solutions proposed and a liaison to ITU-T or OIF
  *> > > or whichever body about tweaks that are out
  *> > > of whack with the protocol architecture.
  *> > > Instead, what we usually end up with are WG
  *> > > Rambos who simply shoot down the entire model of
  *> > > ITU-T or OIF and move on.
  *> > > 
  *> > > Finally, it's not so easy to steer away from RSVP altogether
  *> > > (even if it makes sense to do so)
  *> > > due to the installed code base of dominant vendors.
  *> > > 
  *> > > In summary, there is a lot of pressure to use RSVP outside
  *> > > of IETF, and the IETF should systematically review the
  *> > > outside work to ensure technical sanity.
  *> > > 
  *> > > Regards,
  *> > > 
  *> > > Bala Rajagopalan
  *> > > Tellium, Inc.
  *> > > 2 Crescent Pl.
  *> > > Ocean Port, NJ 07757
  *> > > USA
  *> > > Ph: +1-732-923-4237
  *> > > Email: [email-masked]
  *> > > 
  *> > > > -----Original Message-----
  *> > > > From: David Charlap [mailto:[email-masked]]
  *> > > > Sent: Thursday, January 23, 2003 11:15 AM
  *> > > > To: Brian Hassink
  *> > > > Cc: Bob Braden; [email-masked]; [email-masked]; [email-masked];
  *> > > > [email-masked]; [email-masked]; [email-masked]; 
  *> > [email-masked];
  *> > > > [email-masked]
  *> > > > Subject: Re: IANA Considerations for RSVP
  *> > > >
  *> > > >
  *> > > > Brian Hassink wrote:
  *> > > > > Didn't the IETF set the precedent by extending RSVP from an
  *> > > > IntServ protocol to an MPLS protocol?
  *> > > >
  *> > > > There's a big difference.  MPLS and IntServ are both IETF
  *> > > > groups.  (And
  *> > > > RSVP has/had its own working group anyway).  Also, most of
  *> > > > the key RSVP
  *> > > > people were involved in the development of RSVP-TE.
  *> > > >
  *> > > > This is very different from what I'm describing - where
  *> > > > people who have
  *> > > > no prior RSVP experience decide that they can start changing
  *> > > > it without
  *> > > > understing it, and without even notifying the IETF groups
  *> > > > that did all
  *> > > > of the development work.
  *> > > >
  *> > > > I'mnot saying that RSVP should never be extended.  I'm saying
  *> > > > that those
  *> > > > groups that are writing extensions should be consulting with
  *> > > > those who
  *> > > > have been developing and maintaining it (in the RSVP and MPLS
  *> > > > groups) in
  *> > > > order to ensure that:
  *> > > >       - Their goal can't be achieved without extending 
  *> > the language
  *> > > >       - That their extension doesn't overlap a similar extension
  *> > > >         from somebody else.
  *> > > >       - That their extension doesn't significantly change 
  *> > the overall
  *> > > >         semantics of RSVP.
  *> > > >       - That their extension is sufficiently flexible so 
  *> > that other
  *> > > >         groups can build off of it instead of 
  *> > re-inventing the wheel
  *> > > >         with yet another incompatible extension.
  *> > > >
  *> > > > Not only isn't this happening, but there appears to be no
  *> > > > desire to see
  *> > > > this happen.
  *> > > >
  *> > > > -- David
  *> > > >
  *> > 
  *> > -- 
  *> > Papadimitriou Dimitri 
  *> > E-mail : [email-masked] 
  *> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
  *> > E-mail : [email-masked]
  *> > Public : http://psg.com/~dpapadimitriou/
  *> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
  *> > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
  *> > 
  *> _______________________________________________
  *> Rsvp mailing list
  *> [email-masked]
  *> http://mailman.isi.edu/mailman/listinfo/rsvp
  *> 

Delivery-date: Mon, 27 Jan 2003 07:32:46 -0800
Date: Sun, 26 Jan 2003 20:39:07 -0800 (PST)
From: Bob Braden <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Rsvp] RE: IANA Considerations for RSVP

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Friends,

In trying to sort out how we should have handled RSVP_TE and all its
offspring, it is instructive to read RFC 2814 that describes the
Subnet Bandwidth Manager (SBM).  Like RSVP-TE and its offspring,
the SBM was an RSVP-like protocol for signaling at the link layer.
It is carefully documented as a distinct protocol, alhtough in
fact there are RSVP extensions for the SBM.  It leaves RSVP as
a network- (i.e., Internet-)layer protocol, as it was originally
designed.

I believe using the SBM approach for RSVP-TE would have avoided some of
the problems we are seeing today.  To imply, as I often see done, that
RSVP-TE is "just RSVP with a few extensions" was and is dishonest.  Its
semantics are fundamentally different in important ways, even if the
syntax is the same.  There is more to protocols than bit and byte
formats.

Do we need to have this discussion of 3 large mailing lists?

Bob Braden

Delivery-date: Mon, 27 Jan 2003 07:32:38 -0800
Date: Sun, 26 Jan 2003 20:20:51 -0800 (PST)
From: Bob Braden <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [Rsvp] Re: IANA Considerations for RSVP
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

  *> 
  *> David,
  *> 
  *>     The intent to build a new protocol, rather than bastardize an existing
  *> one has gotten a very large number of people burned in recent times.

Could you cite some specific examples of this?  The one that comes to
mind is LDP, I suppose.  I am not sure anyone was burned by LDP, were
they?

Bob Braden

Delivery-date: Mon, 27 Jan 2003 07:32:29 -0800
Date: Sun, 26 Jan 2003 20:14:55 -0800 (PST)
From: Bob Braden <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Rsvp] [Fwd: Re: IANA Considerations for RSVP]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

  *> 
  *> <zhi>Last time I checked, the IETF didn't change the protocols, 
  *> individuals did through contributions.  The extensions requested for 
  *> Call/Connection control were submitted by an individual.  The fact the 
  *> ITU weighed in requesting approval of the changes is a separate issue.</zhi>
  *> 
  *> So if this was an individual contribution, then it wouldn't be tagged
  *> "ITU-T_SPIFFY_SESSION"?

This statement by Zhi leaves my head spinning.   One of us has a
very confused notion of reality.

Bob Braden

Delivery-date: Sat, 25 Jan 2003 03:09:45 -0800
Date: Sat, 25 Jan 2003 11:58:44 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Document Action: LDP and RSVP Extensions for Optical UNI      Signalingto Informational (fwd)

kireeti, all,

would it be possible to ask to the author to add 
a backward compatibility section in this document 
and this with respect to the gmpls rsvp-te proposed
standard and related

thanks,
- dimitri.

Kireeti Kompella wrote:
> 
> FYI
> 
> ---------- Forwarded message ----------
> Date: Thu, 23 Jan 2003 16:23:42 -0500
> From: The IESG <[email-masked]>
> To: IETF-Announce:  ;
> Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>
> Subject: Document Action: LDP and RSVP Extensions for Optical UNI
>     Signaling to Informational
> 
> The IESG has approved the Internet-Draft 'LDP and RSVP Extensions for
> Optical UNI Signaling' <draft-bala-uni-ldp-rsvp-extensions-04.txt> as
> an Informational RFC.  This has been reviewed in the IETF but is not the
> product of an IETF Working Group.
> 
> The IESG contact person is Scott Bradner.

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Fri, 24 Jan 2003 08:47:28 -0800
Date: Fri, 24 Jan 2003 09:46:27 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Bala Rajagopalan <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP

Bala,
Excellent suggestion.
Steve

Bala Rajagopalan wrote:
> 
> Dimitri:
> 
> I don't recall the particular Yokohoma consensus
> you mention, although what you say could very well
> have happened. All I do remember is the total lack
> of interest in the audience about most of the drafts
> discussed.
> 
> My gripe is basically about the lack of a process in
> the IETF to rigorously and constructively evaluate
> on-going work outside. The liaisons
> obviously haven't worked very well, and the efforts
> by various people to bring in contributions on OIF
> and ASON work have been met with cynicism. This is
> the reason why there's a scramble at the last minute
> to "right" things.
> 
> Going forward, I hope the IETF makes it mandatory
> to have outside work examined in the relevant WGs with
> the same seriousness as regular WG items (or assign
> evaluation teams, like design teams). This would bring
> overall sanity and be beneficial for all groups.
> 
> regards,
> 
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Pl.
> Ocean Port, NJ 07757
> USA
> Ph: +1-732-923-4237
> Email: [email-masked]
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]
> > Sent: Friday, January 24, 2003 2:48 AM
> > To: Bala Rajagopalan
> > Cc: 'David Charlap'; Brian Hassink; Bob Braden; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: IANA Considerations for RSVP
> >
> >
> > bala,
> >
> > your assertion "none of the IETF WGs (specifically, CCAMP)
> > have shown any interest in discussing the (informational)
> > drafts about ASON or OIF at any length." is not true
> > if you were really participating to the ccamp wg meeting
> > in yokohama you would have heard that the consensus was
> > (as requested by the chair) to send a ason functional
> > spec to the ccamp wg in order for the latter to define
> > the needed extensions - the proposal was to achieve
> > a first cut of these extensions in november '02 but
> > nothing happened everything goes to "informational"
> >
> > the reason why suddenly things gets tunneled until
> > reaching the current situation are still unclear for
> > me (one of the explanation i have is the clear rambo
> > competition played by the oif in backing up these
> > extensions instead of letting the corresponding
> > responsibility to the appropriate body i.e. the ietf)
> >
> > thanks,
> > - dimitri.
> >
> > Bala Rajagopalan wrote:
> > >
> > > Hello,
> > >
> > > First, the IETF has been instrumental in putting
> > > IP/MPLS protoocols for use in the optical control plane.
> > > You can't now complain that RSVP is being indiscriminately
> > > used for purposes other than intended. To quote
> > > a cliche, you can't have the cake intact and modify it
> > > too.
> > >
> > > Second, none of the IETF WGs (specifically, CCAMP)
> > > have shown any interest in discussing the (informational)
> > > drafts about ASON or OIF at any length. Serious
> > > consideration by the WGs should lead to an examination
> > > of the solutions proposed and a liaison to ITU-T or OIF
> > > or whichever body about tweaks that are out
> > > of whack with the protocol architecture.
> > > Instead, what we usually end up with are WG
> > > Rambos who simply shoot down the entire model of
> > > ITU-T or OIF and move on.
> > >
> > > Finally, it's not so easy to steer away from RSVP altogether
> > > (even if it makes sense to do so)
> > > due to the installed code base of dominant vendors.
> > >
> > > In summary, there is a lot of pressure to use RSVP outside
> > > of IETF, and the IETF should systematically review the
> > > outside work to ensure technical sanity.
> > >
> > > Regards,
> > >
> > > Bala Rajagopalan
> > > Tellium, Inc.
> > > 2 Crescent Pl.
> > > Ocean Port, NJ 07757
> > > USA
> > > Ph: +1-732-923-4237
> > > Email: [email-masked]
> > >
> > > > -----Original Message-----
> > > > From: David Charlap [mailto:[email-masked]]
> > > > Sent: Thursday, January 23, 2003 11:15 AM
> > > > To: Brian Hassink
> > > > Cc: Bob Braden; [email-masked]; [email-masked]; [email-masked];
> > > > [email-masked]; [email-masked]; [email-masked];
> > [email-masked];
> > > > [email-masked]
> > > > Subject: Re: IANA Considerations for RSVP
> > > >
> > > >
> > > > Brian Hassink wrote:
> > > > > Didn't the IETF set the precedent by extending RSVP from an
> > > > IntServ protocol to an MPLS protocol?
> > > >
> > > > There's a big difference.  MPLS and IntServ are both IETF
> > > > groups.  (And
> > > > RSVP has/had its own working group anyway).  Also, most of
> > > > the key RSVP
> > > > people were involved in the development of RSVP-TE.
> > > >
> > > > This is very different from what I'm describing - where
> > > > people who have
> > > > no prior RSVP experience decide that they can start changing
> > > > it without
> > > > understing it, and without even notifying the IETF groups
> > > > that did all
> > > > of the development work.
> > > >
> > > > I'mnot saying that RSVP should never be extended.  I'm saying
> > > > that those
> > > > groups that are writing extensions should be consulting with
> > > > those who
> > > > have been developing and maintaining it (in the RSVP and MPLS
> > > > groups) in
> > > > order to ensure that:
> > > >       - Their goal can't be achieved without extending
> > the language
> > > >       - That their extension doesn't overlap a similar extension
> > > >         from somebody else.
> > > >       - That their extension doesn't significantly change
> > the overall
> > > >         semantics of RSVP.
> > > >       - That their extension is sufficiently flexible so
> > that other
> > > >         groups can build off of it instead of
> > re-inventing the wheel
> > > >         with yet another incompatible extension.
> > > >
> > > > Not only isn't this happening, but there appears to be no
> > > > desire to see
> > > > this happen.
> > > >
> > > > -- David
> > > >
> >
> > --
> > Papadimitriou Dimitri
> > E-mail : [email-masked]
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : [email-masked]
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> >

Delivery-date: Fri, 24 Jan 2003 08:27:44 -0800
From: Jeff Parker <[email-masked]>
To: "'Bala Rajagopalan'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: IANA Considerations for RSVP
Date: Fri, 24 Jan 2003 11:24:11 -0500

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

> Going forward, I hope the IETF makes it mandatory
> to have outside work examined in the relevant WGs with
> the same seriousness as regular WG items (or assign
> evaluation teams, like design teams). 
>
> Bala Rajagopalan
 
Given that much of the work done at the IETF is
done by volunteers, this bar may not be as high
as it seems.  I see Last Calls on WG items in a
number of groups that elicit little or no comment.  

It is certainly worth the effort to try to make
cooperation between IETF and other bodies easier.
But unfunded mandates are difficult to staff.  

- jeff parker

Delivery-date: Fri, 24 Jan 2003 08:08:47 -0800
From: Bala Rajagopalan <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Bala Rajagopalan <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: IANA Considerations for RSVP
Date: Fri, 24 Jan 2003 10:47:16 -0500

Dimitri:

I don't recall the particular Yokohoma consensus
you mention, although what you say could very well
have happened. All I do remember is the total lack
of interest in the audience about most of the drafts
discussed. 

My gripe is basically about the lack of a process in
the IETF to rigorously and constructively evaluate 
on-going work outside. The liaisons
obviously haven't worked very well, and the efforts
by various people to bring in contributions on OIF
and ASON work have been met with cynicism. This is
the reason why there's a scramble at the last minute
to "right" things. 

Going forward, I hope the IETF makes it mandatory
to have outside work examined in the relevant WGs with
the same seriousness as regular WG items (or assign
evaluation teams, like design teams). This would bring
overall sanity and be beneficial for all groups.

regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Pl.
Ocean Port, NJ 07757
USA
Ph: +1-732-923-4237
Email: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Friday, January 24, 2003 2:48 AM
> To: Bala Rajagopalan
> Cc: 'David Charlap'; Brian Hassink; Bob Braden; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: IANA Considerations for RSVP
> 
> 
> bala,
> 
> your assertion "none of the IETF WGs (specifically, CCAMP)
> have shown any interest in discussing the (informational)
> drafts about ASON or OIF at any length." is not true
> if you were really participating to the ccamp wg meeting
> in yokohama you would have heard that the consensus was
> (as requested by the chair) to send a ason functional 
> spec to the ccamp wg in order for the latter to define
> the needed extensions - the proposal was to achieve 
> a first cut of these extensions in november '02 but
> nothing happened everything goes to "informational"
> 
> the reason why suddenly things gets tunneled until
> reaching the current situation are still unclear for
> me (one of the explanation i have is the clear rambo
> competition played by the oif in backing up these 
> extensions instead of letting the corresponding 
> responsibility to the appropriate body i.e. the ietf)
> 
> thanks,
> - dimitri.
> 
> Bala Rajagopalan wrote:
> > 
> > Hello,
> > 
> > First, the IETF has been instrumental in putting
> > IP/MPLS protoocols for use in the optical control plane.
> > You can't now complain that RSVP is being indiscriminately
> > used for purposes other than intended. To quote
> > a cliche, you can't have the cake intact and modify it
> > too.
> > 
> > Second, none of the IETF WGs (specifically, CCAMP)
> > have shown any interest in discussing the (informational)
> > drafts about ASON or OIF at any length. Serious
> > consideration by the WGs should lead to an examination
> > of the solutions proposed and a liaison to ITU-T or OIF
> > or whichever body about tweaks that are out
> > of whack with the protocol architecture.
> > Instead, what we usually end up with are WG
> > Rambos who simply shoot down the entire model of
> > ITU-T or OIF and move on.
> > 
> > Finally, it's not so easy to steer away from RSVP altogether
> > (even if it makes sense to do so)
> > due to the installed code base of dominant vendors.
> > 
> > In summary, there is a lot of pressure to use RSVP outside
> > of IETF, and the IETF should systematically review the
> > outside work to ensure technical sanity.
> > 
> > Regards,
> > 
> > Bala Rajagopalan
> > Tellium, Inc.
> > 2 Crescent Pl.
> > Ocean Port, NJ 07757
> > USA
> > Ph: +1-732-923-4237
> > Email: [email-masked]
> > 
> > > -----Original Message-----
> > > From: David Charlap [mailto:[email-masked]]
> > > Sent: Thursday, January 23, 2003 11:15 AM
> > > To: Brian Hassink
> > > Cc: Bob Braden; [email-masked]; [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]; [email-masked]; 
> [email-masked];
> > > [email-masked]
> > > Subject: Re: IANA Considerations for RSVP
> > >
> > >
> > > Brian Hassink wrote:
> > > > Didn't the IETF set the precedent by extending RSVP from an
> > > IntServ protocol to an MPLS protocol?
> > >
> > > There's a big difference.  MPLS and IntServ are both IETF
> > > groups.  (And
> > > RSVP has/had its own working group anyway).  Also, most of
> > > the key RSVP
> > > people were involved in the development of RSVP-TE.
> > >
> > > This is very different from what I'm describing - where
> > > people who have
> > > no prior RSVP experience decide that they can start changing
> > > it without
> > > understing it, and without even notifying the IETF groups
> > > that did all
> > > of the development work.
> > >
> > > I'mnot saying that RSVP should never be extended.  I'm saying
> > > that those
> > > groups that are writing extensions should be consulting with
> > > those who
> > > have been developing and maintaining it (in the RSVP and MPLS
> > > groups) in
> > > order to ensure that:
> > >       - Their goal can't be achieved without extending 
> the language
> > >       - That their extension doesn't overlap a similar extension
> > >         from somebody else.
> > >       - That their extension doesn't significantly change 
> the overall
> > >         semantics of RSVP.
> > >       - That their extension is sufficiently flexible so 
> that other
> > >         groups can build off of it instead of 
> re-inventing the wheel
> > >         with yet another incompatible extension.
> > >
> > > Not only isn't this happening, but there appears to be no
> > > desire to see
> > > this happen.
> > >
> > > -- David
> > >
> 
> -- 
> Papadimitriou Dimitri 
> E-mail : [email-masked] 
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> 

Delivery-date: Thu, 23 Jan 2003 23:51:21 -0800
Date: Fri, 24 Jan 2003 08:48:11 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: Bala Rajagopalan <[email-masked]>
Cc: "'David Charlap'" <[email-masked]>, Brian Hassink <[email-masked]>, Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP

bala,

your assertion "none of the IETF WGs (specifically, CCAMP)
have shown any interest in discussing the (informational)
drafts about ASON or OIF at any length." is not true
if you were really participating to the ccamp wg meeting
in yokohama you would have heard that the consensus was
(as requested by the chair) to send a ason functional 
spec to the ccamp wg in order for the latter to define
the needed extensions - the proposal was to achieve 
a first cut of these extensions in november '02 but
nothing happened everything goes to "informational"

the reason why suddenly things gets tunneled until
reaching the current situation are still unclear for
me (one of the explanation i have is the clear rambo
competition played by the oif in backing up these 
extensions instead of letting the corresponding 
responsibility to the appropriate body i.e. the ietf)

thanks,
- dimitri.

Bala Rajagopalan wrote:
> 
> Hello,
> 
> First, the IETF has been instrumental in putting
> IP/MPLS protoocols for use in the optical control plane.
> You can't now complain that RSVP is being indiscriminately
> used for purposes other than intended. To quote
> a cliche, you can't have the cake intact and modify it
> too.
> 
> Second, none of the IETF WGs (specifically, CCAMP)
> have shown any interest in discussing the (informational)
> drafts about ASON or OIF at any length. Serious
> consideration by the WGs should lead to an examination
> of the solutions proposed and a liaison to ITU-T or OIF
> or whichever body about tweaks that are out
> of whack with the protocol architecture.
> Instead, what we usually end up with are WG
> Rambos who simply shoot down the entire model of
> ITU-T or OIF and move on.
> 
> Finally, it's not so easy to steer away from RSVP altogether
> (even if it makes sense to do so)
> due to the installed code base of dominant vendors.
> 
> In summary, there is a lot of pressure to use RSVP outside
> of IETF, and the IETF should systematically review the
> outside work to ensure technical sanity.
> 
> Regards,
> 
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Pl.
> Ocean Port, NJ 07757
> USA
> Ph: +1-732-923-4237
> Email: [email-masked]
> 
> > -----Original Message-----
> > From: David Charlap [mailto:[email-masked]]
> > Sent: Thursday, January 23, 2003 11:15 AM
> > To: Brian Hassink
> > Cc: Bob Braden; [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]; [email-masked];
> > [email-masked]
> > Subject: Re: IANA Considerations for RSVP
> >
> >
> > Brian Hassink wrote:
> > > Didn't the IETF set the precedent by extending RSVP from an
> > IntServ protocol to an MPLS protocol?
> >
> > There's a big difference.  MPLS and IntServ are both IETF
> > groups.  (And
> > RSVP has/had its own working group anyway).  Also, most of
> > the key RSVP
> > people were involved in the development of RSVP-TE.
> >
> > This is very different from what I'm describing - where
> > people who have
> > no prior RSVP experience decide that they can start changing
> > it without
> > understing it, and without even notifying the IETF groups
> > that did all
> > of the development work.
> >
> > I'mnot saying that RSVP should never be extended.  I'm saying
> > that those
> > groups that are writing extensions should be consulting with
> > those who
> > have been developing and maintaining it (in the RSVP and MPLS
> > groups) in
> > order to ensure that:
> >       - Their goal can't be achieved without extending the language
> >       - That their extension doesn't overlap a similar extension
> >         from somebody else.
> >       - That their extension doesn't significantly change the overall
> >         semantics of RSVP.
> >       - That their extension is sufficiently flexible so that other
> >         groups can build off of it instead of re-inventing the wheel
> >         with yet another incompatible extension.
> >
> > Not only isn't this happening, but there appears to be no
> > desire to see
> > this happen.
> >
> > -- David
> >

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Thu, 23 Jan 2003 17:13:58 -0800
From: John Drake <[email-masked]>
To: 'Scott W Brim' <[email-masked]>, Stephen Trowbridge <[email-masked]>
Cc: David Charlap <[email-masked]>, Brian Hassink <[email-masked]>, Bob Braden <[email-masked]>,  [email-masked], [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: IANA Considerations for RSVP
Date: Thu, 23 Jan 2003 17:12:46 -0800

Scott,

You saved me some typing.

John

> -----Original Message-----
> From: Scott W Brim [mailto:[email-masked]]
> Sent: Thursday, January 23, 2003 4:27 PM
> To: Stephen Trowbridge
> Cc: John Drake; David Charlap; Brian Hassink; Bob Braden; 
> [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: IANA Considerations for RSVP
> 
> 
> On Thu, Jan 23, 2003 04:24:31PM -0700, Stephen Trowbridge 
> allegedly wrote:
> > John,
> > Hmmm... a bit IETF centric.
> > Because some portion of a problem space touches or uses an 
> IETF protocol,
> > then clearly the entire problem must belong to IETF.
> 
> The entire problem of signing off on extensions to the protocol does
> belong to the IETF, if you want them to be used outside of some local
> network.  That's for architectural consistency.
> 
> > Consider that the ASON architecture encompasses transport 
> networks where
> > what we call the transport plane (IETF calls the data plane) is not
> > necessarily IP. What if the addresses are NSAP addresses 
> instead of IP
> > addresses? What if some or all of the signaling links employ PNNI
> > as a signaling protocol instead of RSVP-TE or CR-LDP? Does it still
> > all belong to IETF? These are problems that cannot be solved without
> > good cooperation between the standards organizations that 
> are involved.
> 
> The IETF is responsible for defining the mechanisms by which those
> non-IP addresses can be carried in the IP-based protocol.
> 
> > In terms of the existance of a communication channel and 
> procedures for
> > collaborating between IETF and ITU-T, this exists but 
> perhaps, in spite
> > of receiving these liaisons, you have not taken the trouble 
> to become
> > familiar with it. Identical text describing the 
> collaboration process is
> > published as RFC 3356 in IETF and as A.Sup3 in ITU-T. We 
> are following
> > the documented process, and this suggests a different 
> answer than your
> > emails to the question of which side of this communication 
> channel is
> > not holding up their end.
> 
> I agree the communication channels could be used better.  I also think
> that the best way to communicate is probably NOT those channels, but
> rather to bring in parallel technical contributions in each group, to
> make sure they are in sync.  Take the ideas through the 
> procedures that
> participants actually care about.
> 
> swb
> 

Delivery-date: Thu, 23 Jan 2003 16:28:01 -0800
Date: Thu, 23 Jan 2003 19:26:55 -0500
From: Scott W Brim <[email-masked]>
To: Stephen Trowbridge <[email-masked]>
Cc: John Drake <[email-masked]>, David Charlap <[email-masked]>, Brian Hassink <[email-masked]>, Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP
Mail-Followup-To: Scott W Brim <[email-masked]>, Stephen Trowbridge <[email-masked]>, John Drake <[email-masked]>, David Charlap <[email-masked]>, Brian Hassink <[email-masked]>, Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

On Thu, Jan 23, 2003 04:24:31PM -0700, Stephen Trowbridge allegedly wrote:
> John,
> Hmmm... a bit IETF centric.
> Because some portion of a problem space touches or uses an IETF protocol,
> then clearly the entire problem must belong to IETF.

The entire problem of signing off on extensions to the protocol does
belong to the IETF, if you want them to be used outside of some local
network.  That's for architectural consistency.

> Consider that the ASON architecture encompasses transport networks where
> what we call the transport plane (IETF calls the data plane) is not
> necessarily IP. What if the addresses are NSAP addresses instead of IP
> addresses? What if some or all of the signaling links employ PNNI
> as a signaling protocol instead of RSVP-TE or CR-LDP? Does it still
> all belong to IETF? These are problems that cannot be solved without
> good cooperation between the standards organizations that are involved.

The IETF is responsible for defining the mechanisms by which those
non-IP addresses can be carried in the IP-based protocol.

> In terms of the existance of a communication channel and procedures for
> collaborating between IETF and ITU-T, this exists but perhaps, in spite
> of receiving these liaisons, you have not taken the trouble to become
> familiar with it. Identical text describing the collaboration process is
> published as RFC 3356 in IETF and as A.Sup3 in ITU-T. We are following
> the documented process, and this suggests a different answer than your
> emails to the question of which side of this communication channel is
> not holding up their end.

I agree the communication channels could be used better.  I also think
that the best way to communicate is probably NOT those channels, but
rather to bring in parallel technical contributions in each group, to
make sure they are in sync.  Take the ideas through the procedures that
participants actually care about.

swb

Delivery-date: Thu, 23 Jan 2003 16:25:35 -0800
From: Bala Rajagopalan <[email-masked]>
To: 'David Charlap' <[email-masked]>, Brian Hassink <[email-masked]>
Cc: Bob Braden <[email-masked]>, [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked]
Subject: RE: IANA Considerations for RSVP
Date: Thu, 23 Jan 2003 12:03:26 -0500

Hello,

First, the IETF has been instrumental in putting
IP/MPLS protoocols for use in the optical control plane.
You can't now complain that RSVP is being indiscriminately
used for purposes other than intended. To quote
a cliche, you can't have the cake intact and modify it
too.

Second, none of the IETF WGs (specifically, CCAMP)
have shown any interest in discussing the (informational)
drafts about ASON or OIF at any length. Serious
consideration by the WGs should lead to an examination
of the solutions proposed and a liaison to ITU-T or OIF
or whichever body about tweaks that are out
of whack with the protocol architecture.
Instead, what we usually end up with are WG
Rambos who simply shoot down the entire model of
ITU-T or OIF and move on.

Finally, it's not so easy to steer away from RSVP altogether
(even if it makes sense to do so)
due to the installed code base of dominant vendors.

In summary, there is a lot of pressure to use RSVP outside
of IETF, and the IETF should systematically review the
outside work to ensure technical sanity.

Regards,
 
Bala Rajagopalan
Tellium, Inc.
2 Crescent Pl.
Ocean Port, NJ 07757
USA
Ph: +1-732-923-4237
Email: [email-masked]

> -----Original Message-----
> From: David Charlap [mailto:[email-masked]]
> Sent: Thursday, January 23, 2003 11:15 AM
> To: Brian Hassink
> Cc: Bob Braden; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: IANA Considerations for RSVP
> 
> 
> Brian Hassink wrote:
> > Didn't the IETF set the precedent by extending RSVP from an 
> IntServ protocol to an MPLS protocol?
> 
> There's a big difference.  MPLS and IntServ are both IETF 
> groups.  (And 
> RSVP has/had its own working group anyway).  Also, most of 
> the key RSVP 
> people were involved in the development of RSVP-TE.
> 
> This is very different from what I'm describing - where 
> people who have 
> no prior RSVP experience decide that they can start changing 
> it without 
> understing it, and without even notifying the IETF groups 
> that did all 
> of the development work.
> 
> I'mnot saying that RSVP should never be extended.  I'm saying 
> that those 
> groups that are writing extensions should be consulting with 
> those who 
> have been developing and maintaining it (in the RSVP and MPLS 
> groups) in 
> order to ensure that:
> 	- Their goal can't be achieved without extending the language
> 	- That their extension doesn't overlap a similar extension
> 	  from somebody else.
> 	- That their extension doesn't significantly change the overall
> 	  semantics of RSVP.
> 	- That their extension is sufficiently flexible so that other
> 	  groups can build off of it instead of re-inventing the wheel
> 	  with yet another incompatible extension.
> 
> Not only isn't this happening, but there appears to be no 
> desire to see 
> this happen.
> 
> -- David
> 

Delivery-date: Thu, 23 Jan 2003 15:51:08 -0800
Date: Thu, 23 Jan 2003 12:42:34 -0500
From: Eric Gray <[email-masked]>
To: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
CC: David Charlap <[email-masked]>, Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Zhi,

    Yours may be an equally unfair characterization.  In general, the reaction
in the IETF to any intended RFC submitted as a 'fait accompli' is similar to
what you are seeing here - regardless of whether it came from an individual
or an organization representative.

"Lin, Zhi-Wei (Zhi)" wrote:

> Hi David,
>
> This seems like an unfair characterization. All requests are submitted by individuals. In terms of changing these protocols...
>

...

Delivery-date: Thu, 23 Jan 2003 15:49:57 -0800
Date: Thu, 23 Jan 2003 12:27:38 -0500
From: Eric Gray <[email-masked]>
To: David Charlap <[email-masked]>
CC: Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

    The intent to build a new protocol, rather than bastardize an existing
one has gotten a very large number of people burned in recent times. I
can't say as I blame external organizations - who, in almost every case,
have mostly only seen the flames from prior efforts coloring the sky -
from opting to modify an existing protocol.

    We shouldn't chastise people for making what they feel are the best
choices based on the evidence in front of them.  We should instead try
to determine what they are missing, or otherwise help them to modify
those choices.  :-)

--
Eric Gray

David Charlap wrote:

> Bob Braden wrote:
> >
> > There is a growing unease about IANA assignments of RSVP parameters --
> > object numbers, CTypes, message types, and error numbers -- for new
> > uses of RSVP.  Many of these IANA requests, but not all, originate
> > outside the IETF in other standards bodies.  Many of the people from
> > outside the IETF were not part of the RSVP working group and so did not
> > absorb the technical rationale behind RSVP; in fact, they are sometimes
> > barely clued into IETF procedures at all.
>
> I've noticed the same thing.  It seems that many non-IETF groups want to
> use RSVP, and all believe that they must create extensions to the
> protocol for their features, often without first bothering to check if
> there are already obects defined by IETF standards that already serve
> their purposes.  And even in those cases where new objects may be
> required, the proposed objects are often defined as having semantics
> that differ greatly from the way RSVP usually operates.
>
> In other words, these groups seem to want to forcibly change RSVP into a
> protocol that more closely resembles some other protocol that they're
> more intimately familiar with.
>
> Personally, I don't like this.  These groups should step back and decide
> if RSVP is really what they need.  If they require a different protocol,
> then they should use a different protocol - they should not glom onto
> RSVP just because it's popular in MPLS and then try to change it into
> what they really want.  This is especially true in those situations
> where their proposed changes would produce a fundamentally incompatible
> protocol.
>
> Unfortunately, I don't know what can be done about this.  These groups
> seem hell-bent on hacking up RSVP without first learning it's design
> philosophy.  If they don't get assignments from IANA, they'll probably
> just make their own assignments without any coordinating facility, and
> we'll wind up with several mutually incompatible protocols that all want
> to call themselves "RSVP".
>
> -- David

Delivery-date: Thu, 23 Jan 2003 15:46:39 -0800
content-class: urn:content-classes:message
Subject: RE: IANA Considerations for RSVP
Date: Thu, 23 Jan 2003 11:06:53 -0500
From: "Brian Hassink" <[email-masked]>
To: "David Charlap" <[email-masked]>, "Bob Braden" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Didn't the IETF set the precedent by extending RSVP from an IntServ =
protocol to an MPLS protocol?

CR-LDP exists as a purpose built alternative, but vendor politics =
resulted in the above precedent.

Just my opinion.

Cheers,
Brian

-----Original Message-----
From: David Charlap [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 10:56 AM
To: Bob Braden
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: IANA Considerations for RSVP

Bob Braden wrote:
>=20
> There is a growing unease about IANA assignments of RSVP parameters --
> object numbers, CTypes, message types, and error numbers -- for new
> uses of RSVP.  Many of these IANA requests, but not all, originate
> outside the IETF in other standards bodies.  Many of the people from
> outside the IETF were not part of the RSVP working group and so did =
not
> absorb the technical rationale behind RSVP; in fact, they are =
sometimes
> barely clued into IETF procedures at all.

I've noticed the same thing.  It seems that many non-IETF groups want to =

use RSVP, and all believe that they must create extensions to the=20
protocol for their features, often without first bothering to check if=20
there are already obects defined by IETF standards that already serve=20
their purposes.  And even in those cases where new objects may be=20
required, the proposed objects are often defined as having semantics=20
that differ greatly from the way RSVP usually operates.

In other words, these groups seem to want to forcibly change RSVP into a =

protocol that more closely resembles some other protocol that they're=20
more intimately familiar with.

Personally, I don't like this.  These groups should step back and decide =

if RSVP is really what they need.  If they require a different protocol, =

then they should use a different protocol - they should not glom onto=20
RSVP just because it's popular in MPLS and then try to change it into=20
what they really want.  This is especially true in those situations=20
where their proposed changes would produce a fundamentally incompatible=20
protocol.

Unfortunately, I don't know what can be done about this.  These groups=20
seem hell-bent on hacking up RSVP without first learning it's design=20
philosophy.  If they don't get assignments from IANA, they'll probably=20
just make their own assignments without any coordinating facility, and=20
we'll wind up with several mutually incompatible protocols that all want =

to call themselves "RSVP".

-- David

Delivery-date: Thu, 23 Jan 2003 15:26:19 -0800
Date: Thu, 23 Jan 2003 16:24:31 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: David Charlap <[email-masked]>, Brian Hassink <[email-masked]>, Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP

John,
Hmmm... a bit IETF centric.
Because some portion of a problem space touches or uses an IETF protocol,
then clearly the entire problem must belong to IETF.
Consider that the ASON architecture encompasses transport networks where
what we call the transport plane (IETF calls the data plane) is not
necessarily IP. What if the addresses are NSAP addresses instead of IP
addresses? What if some or all of the signaling links employ PNNI
as a signaling protocol instead of RSVP-TE or CR-LDP? Does it still
all belong to IETF? These are problems that cannot be solved without
good cooperation between the standards organizations that are involved.

In terms of the existance of a communication channel and procedures for
collaborating between IETF and ITU-T, this exists but perhaps, in spite
of receiving these liaisons, you have not taken the trouble to become
familiar with it. Identical text describing the collaboration process is
published as RFC 3356 in IETF and as A.Sup3 in ITU-T. We are following
the documented process, and this suggests a different answer than your
emails to the question of which side of this communication channel is
not holding up their end.
Steve

John Drake wrote:
> 
> Stephen,
> 
> I appreciate all the work you've done keep the IETF informed about what the
> ITU is doing.  All I can say is that it doesn't seem to have worked.  Rather
> than continuing to give us status reports on what the ITU is doing, I think
> it would make more sense to do the work in the appropriate IETF working
> groups.
> 
> That was what I thought was the intent of the Feb 19th Liason: "We wish that
> as we continue our review of these protocols you will be able to provide us
> with recommendations on how to close these and future issues."  However, a
> channel of communication has not been established: how should
> recommendations and issues be communicated?  Who makes these, and who
> communicates them?  How does a two-way (or n-way) dialog take place?
> 
> If, on the other hand, these documents were brought into an IETF WG, the
> procedures and channels of communication exist and are well-known.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, January 23, 2003 9:21 AM
> To: David Charlap
> Cc: Brian Hassink; Bob Braden; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: IANA Considerations for RSVP
> 
> David,
> To read these emails, it sounds as though you think that the people who
> are doing this are brand new to the technology and never even considered
> working with IETF to try to solve the problem. Perhaps you haven't followed
> the ccamp work so closely, but here is some history:
> - On October 21, 2001, ITU-T Study Group 15 sent IETF ccamp a liaison
> statement
>   regarding our new documents with requirements and architecture for
>   switched (not necessarily IP) transport networks. This included a
> protocol-
>   neutral model for call and connection management (signaling). In copies
>   of the ITU-T documents were made available to non-ITU-T members via an
>   ftp site. The liaison was placed on the IESG web site and was presented
>   in the ccamp meeting in Salt Lake City in December. At that same meeting,
>   Maarten Vissers gave a technical presentation in the sub-IP area meeting
>   regarding the ITU-T work in this area.
> - On February 19, 2002, ITU-T sent IETF ccamp a liaison statement regarding
>   the gaps that had been identified between the ITU-T requirements (sent
>   earlier) and what seemed to be implemented by the GMPLS protocols.
> Specifically,
>   1. Call & Connection separation, e.g., a call provides the service
>      relationship, which may support connection operations as part of a
> call.
>   2. Additional error codes/values, for example, for connection rejection
>      (invalid connection ID).
>   3. Restart mechanisms: Depending on the introduction by the ITU of
> additional
>      control plane resiliency requirements, enhancements of the protocol
>      (RSVP-TE, CR-LDP) "graceful restart" mechanisms may be required.
>   4. Protocol enhancements in CR-LDP for support of crankback capability
> from
>      intermediate nodes.
>   This liaison was presented in the Minneapolis IETF meeting during the
> ccamp
>   working group and posted on the IESG web site. The liaison requested
>   assistance in closing these gaps and invited input from IETF on our work
>   in ITU-T.
> - At the April/May 2002 meeting of ITU-T Study Group 15 meeting,
> contributions
>   were considered to close these gaps, resulting in text for draft
> Recommendations
>   G.7713.2 (our rsvp-te document) and G.7713.3 (our cr-ldp document). Again,
>   we sent a liaison (dated May 10, 2002) to ask for comments on our draft
>   Recommendations (made available on the ftp site), to request alignment,
> and
>   to ask for IANA code point assignments. To quote from that liaison:
> "Please consider including the proposed solutions provided in G.7713.2 and
> G.7713.3
> to update the existing GMPLS signaling work in support of ASON requirements.
> We hope that you can help expedite the assignment of appropriate additional
> error codes/values by IANA.  These are needed for both RSVP-TE and CR-LDP."
>   This liaison was presented at the Yokohama IETF ccamp meeting.
> 
>   To refer to one point raised earlier in the thread, there are other cases
>   where IANA has assigned codepoints for work outside of IETF, including
>   other CCITT/ITU-T work, IEEE, IEC, etc. This request had been made last
>   May, with no response.
> - Some final work was done on our drafts at a Rapporteur meeting in October,
>   with one result being another liaison (dated October 11, 2002) making
>   another plea for comments and help getting the codepoints assigned. This
>   liaison was presented at the Atlanta IETF ccamp meeting, and still no
>   response or IANA action.
> 
> To hear now that someone thinks that the ASON work in ITU-T is some kind
> of secret end-run around IETF, and not involved with or related to the
> work being done internally in IETF is absurd. At every stage of the work,
> IETF was kept informed of the work and invited to participate. At the
> invitation for help to address the additional ITU-T requirements, there
> was no response. As ITU-T progressed this work and invited further comments
> and alignment of the base GMPLS protocols, again no response. And to the
> final pleas for comments and codepoint assignments, no response.
> 
> I contrast this with our interaction with the ATM forum on the same topic.
> Certain operators in ITU-T are interested in using the PNNI protocol for
> this application (rather than rsvp-te or cr-ldp). The ATM forum has
> responded with a formal liaison into the current ITU-T Study Group 15
> meeting where they have given us a diffmarked copy with extremely
> helpful and constructive suggestions about how to align our G.7713.1
> document with their work.
> 
> After some private communication with the Area directors, we received some
> advice that one tool that might be used to finally get the IANA codepoint
> assignment complete would be to publish what we were doing in ITU-T as
> informational RFCs. This is the stage we are at today, and given the
> history I describe above, I do not think anybody can say that we are
> at this point because any of us did not do everything possible to
> do this work (a) in IETF, with the initial communication of requirements;
> or (b) in cooperation between ITU-T and IETF, once this work had
> progressed in ITU-T.
> 
> But this is all water under the bridge. We are at the point of trying
> to get some codepoints assigned for ITU-T documents we are trying to
> complete. Nobody should say "no" at this point because they think we
> didn't try to work this IN or WITH IETF first. It should be clear to
> all that this is not the case.
> Regards,
> Steve Trowbridge
> (vice-chairman, ITU-T Study Group 15)
> 
> David Charlap wrote:
> >
> > Brian Hassink wrote:
> > > Didn't the IETF set the precedent by extending RSVP from an IntServ
> protocol to an MPLS protocol?
> >
> > There's a big difference.  MPLS and IntServ are both IETF groups.  (And
> > RSVP has/had its own working group anyway).  Also, most of the key RSVP
> > people were involved in the development of RSVP-TE.
> >
> > This is very different from what I'm describing - where people who have
> > no prior RSVP experience decide that they can start changing it without
> > understing it, and without even notifying the IETF groups that did all
> > of the development work.
> >
> > I'mnot saying that RSVP should never be extended.  I'm saying that those
> > groups that are writing extensions should be consulting with those who
> > have been developing and maintaining it (in the RSVP and MPLS groups) in
> > order to ensure that:
> >         - Their goal can't be achieved without extending the language
> >         - That their extension doesn't overlap a similar extension
> >           from somebody else.
> >         - That their extension doesn't significantly change the overall
> >           semantics of RSVP.
> >         - That their extension is sufficiently flexible so that other
> >           groups can build off of it instead of re-inventing the wheel
> >           with yet another incompatible extension.
> >
> > Not only isn't this happening, but there appears to be no desire to see
> > this happen.
> >
> > -- David

Delivery-date: Thu, 23 Jan 2003 15:23:19 -0800
From: Bob Braden <[email-masked]>
Date: Wed, 22 Jan 2003 21:40:12 GMT
To: [email-masked]
Subject: IANA Considerations for RSVP
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

There is a growing unease about IANA assignments of RSVP parameters --
object numbers, CTypes, message types, and error numbers -- for new
uses of RSVP.  Many of these IANA requests, but not all, originate
outside the IETF in other standards bodies.  Many of the people from
outside the IETF were not part of the RSVP working group and so did not
absorb the technical rationale behind RSVP; in fact, they are sometimes
barely clued into IETF procedures at all.

As a sample, here is a part of a recent message from Kireeti Kompella,
co-chair of the CCAMP working group:

	"The problem I am trying to address is that folks are changing the
	RSVP spec with *Informational* documents that bypass much of the
	checks we have.  For example, the "GMPLS RSVP-TE for ASON"
	draft-lin-ccamp-gmpls-ason-rsvpte-04.txt defines new objects for
	the purpose of "call and connection separation".  I don't see any
	reason for such separation; even in the ITU (where this comes from),
	there is not a clear consensus that this is needed.  However, this
	document breezed through the IETF "process".

	Furthermore, it is an *Informational* document.  If this really was
	useful, and someone were to extend this, their document would have to
	be Informational by normative reference transitivity.  The worst part
	of this is that the base protocols (RSVP, RSVP-TE and RSVP-TE for
	GMPLS) were IETF protocols -- and then this piece has been usurped by
	the ITU (where the standards track documents will be defined).

	What I would like to see is the bulk of each space (messages, objects,
	class types, etc) being Standards Action, with some space for FCFS
	and Private Use."

This raises a bunch of technical and procedural questions; I will address
some of the latter below.

Several points should be made.

1. I volunteered several years ago to serve as the "designated expert" for
	RSVP registrations (RFC 2434), so every RSVP reservation request
	is referred to me.
		(Given the amount of recent aggrevation, this may not
		have been too wise a move for me.)

2. Just before the RSVP WG went dormant, its cochairs put together an
	IANA Considerations document and published it as an I-D.  I
	believe that it went through a formal WG last call; at least,
	the WG was given an opporunity to comment on, or object to,
	it.  It did not become an RFC, but it is available on the RSVP
	web site.  (I recently moved it to a more prominent spot in
	www.isi.edu/rsvp/pub.html).

	As the designated expert, I follow the rules in that draft.
	
3. The IANA Considerations draft should be published as an RFC,
	perhaps after updating.  Here are some issues that might affect
	this update.

	(A) How to handle requests for RSVP assignments for
		extensions developed outside IETF?

	    Here is my suggestion:
 
		For all assignments of numbers for extensions defined
		in non-IETF standards bodies, the IANA should use
		assignment names (e.g., object names) that are prefixed
		with the name of the responsible standards body.  For
		example, the "SPIFFY_SESSION" object would become
		"ATM_FORUM_SPIFFY_SESSION" or "ITU-T_SPIFFY_SESSION",
		etc., object.

	(B) What policies should be imposed?

		The document currently divides the assignment space into
		two subspaces, for "IETF Consensus" and "FCFS".  RFC
		2434 lists various other possibilities; do we need any?

		Precisely what do we mean by IETF consensus?  Does this
		require a standards-track document?  (We thought it did.)

		We assumed that non-IETF requests would necessarily go to
		FCFS, but is it really FCFS + expert opinion?  In other
		words, how much oversight should we try to exert for
		non-IETF RSVP extensions?  I have seen some highly
		questionable extensions.  They tend to be micro-engineering,
		with no sense of a larger design.

	(C) What are the appropriate documentation requirements?

		Must there be an Internet Draft? An RFC?  We have
		tended towards the RFC, but the result is less than
		satisfactory.  These extensions are typically
		documented in some 373- page document published (or
		more often hidden) by the other standards body.  The
		I-D/RFC that is written for registration presents only
		a superficial summary of the data structures to be
		defined, with no context of explanation,  and a
		reference to the real 373 page document.

Bob Braden
Former co-chair of the RSVP WG
Current designated expert for RSVP assignments by IANA

----- End Included Message -----

Delivery-date: Thu, 23 Jan 2003 13:46:23 -0800
Date: Thu, 23 Jan 2003 13:44:14 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: <[email-masked]>
Subject: Document Action: LDP and RSVP Extensions for Optical UNI     Signaling to Informational (fwd)

FYI

---------- Forwarded message ----------
Date: Thu, 23 Jan 2003 16:23:42 -0500
From: The IESG <[email-masked]>
To: IETF-Announce:  ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>
Subject: Document Action: LDP and RSVP Extensions for Optical UNI
    Signaling to Informational

The IESG has approved the Internet-Draft 'LDP and RSVP Extensions for
Optical UNI Signaling' <draft-bala-uni-ldp-rsvp-extensions-04.txt> as
an Informational RFC.  This has been reviewed in the IETF but is not the
product of an IETF Working Group.

The IESG contact person is Scott Bradner.

Delivery-date: Thu, 23 Jan 2003 12:29:03 -0800
From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, "Lin, Zhi-Wei (Zhi)" <[email-masked]>
Cc: Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: IANA Considerations for RSVP
Date: Thu, 23 Jan 2003 15:28:12 -0500

Hi Kireeti,

I didn't mean to imply what you said. I apologize if I offended you. Just that the site was not very well publicized by the IESG. I only became aware of it after someone pointed me to it. 

Zhi

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 3:22 PM
To: Lin, Zhi-Wei (Zhi)
Cc: Bob Braden; [email-masked]; [email-masked]; [email-masked]
Subject: RE: IANA Considerations for RSVP

Hi Zhi,

On Thu, 23 Jan 2003, Lin, Zhi-Wei (Zhi) wrote:

> Please visit the IESG page, go to I-D tracker, and search under the
> document...

I just did.  Oh, well.

> I guess some IETF WG chairs don't pay attention to this...

And you're implying?  My imcompetence, or the fact that this is not
the product of a WG?

But you're right, this has been approved by the IETF.  More accurately,
as the email to IETF announce says, by the IESG.

Kireeti.

Delivery-date: Thu, 23 Jan 2003 12:22:55 -0800
Date: Thu, 23 Jan 2003 12:22:08 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
cc: Bob Braden <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: IANA Considerations for RSVP

Hi Zhi,

On Thu, 23 Jan 2003, Lin, Zhi-Wei (Zhi) wrote:

> Please visit the IESG page, go to I-D tracker, and search under the
> document...

I just did.  Oh, well.

> I guess some IETF WG chairs don't pay attention to this...

And you're implying?  My imcompetence, or the fact that this is not
the product of a WG?

But you're right, this has been approved by the IETF.  More accurately,
as the email to IETF announce says, by the IESG.

Kireeti.

Delivery-date: Thu, 23 Jan 2003 12:19:08 -0800
Date: Thu, 23 Jan 2003 15:17:58 -0500
From: David Charlap <[email-masked]>
Organization: Marconi, Vienna VA
To: [email-masked]
CC: Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP

Eric Gray wrote:
> 
>     The intent to build a new protocol, rather than bastardize an existing
> one has gotten a very large number of people burned in recent times. I
> can't say as I blame external organizations - who, in almost every case,
> have mostly only seen the flames from prior efforts coloring the sky -
> from opting to modify an existing protocol.
> 
>     We shouldn't chastise people for making what they feel are the best
> choices based on the evidence in front of them.  We should instead try
> to determine what they are missing, or otherwise help them to modify
> those choices.  :-)

You miss my point.

I'm not saying that groups should always build new protocols. 
Sometimes, there are perfectly good reasons to extend an existing 
protocol (like GMPLS extended RSVP-TE).

But when this is done, it should be done in conjunction with those 
responsible for the original protocol.

A third-party (like IEEE, ITU, ATM Forum, ISO, etc.) should never grab 
an IETF protocol and make changes to it without involving the 
appropriate IETF group.  (And I am not accusing any organization - these 
are just examples of the third parties I'm referring to.  I am not 
talking about different groups within the IETF.)

This goes the other way around as well.  Just as IEEE would object to 
the IETF unilaterally defining an extension to FireWire (IEEE-1392) 
protocol, the IETF should similarly object to some outside organization 
unilaterally defining an extension to IP, or RSVP, etc.

Now, I am not saying that every single third-party extension has done 
this.  I am well aware of the fact that some groups do work with the 
IETF on their extensions.  This is good.  This is the way it should be. 
  But there are other groups that do not.  If your (now speaking to 
everybody reading this message) group's extension was developed in 
conjungtion with the IETF, then my criticism is not directed at you, and 
you should not take offense at my opinion.

-- David

Delivery-date: Thu, 23 Jan 2003 11:32:28 -0800
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>, David Charlap <[email-masked]>
Cc: Brian Hassink <[email-masked]>, Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: IANA Considerations for RSVP
Date: Thu, 23 Jan 2003 11:31:30 -0800

Stephen,

I appreciate all the work you've done keep the IETF informed about what the
ITU is doing.  All I can say is that it doesn't seem to have worked.  Rather
than continuing to give us status reports on what the ITU is doing, I think
it would make more sense to do the work in the appropriate IETF working
groups.

That was what I thought was the intent of the Feb 19th Liason: "We wish that
as we continue our review of these protocols you will be able to provide us
with recommendations on how to close these and future issues."  However, a
channel of communication has not been established: how should
recommendations and issues be communicated?  Who makes these, and who
communicates them?  How does a two-way (or n-way) dialog take place?

If, on the other hand, these documents were brought into an IETF WG, the
procedures and channels of communication exist and are well-known.

Thanks,

John

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 9:21 AM
To: David Charlap
Cc: Brian Hassink; Bob Braden; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: IANA Considerations for RSVP

David,
To read these emails, it sounds as though you think that the people who
are doing this are brand new to the technology and never even considered
working with IETF to try to solve the problem. Perhaps you haven't followed
the ccamp work so closely, but here is some history:
- On October 21, 2001, ITU-T Study Group 15 sent IETF ccamp a liaison
statement
  regarding our new documents with requirements and architecture for
  switched (not necessarily IP) transport networks. This included a
protocol-
  neutral model for call and connection management (signaling). In copies
  of the ITU-T documents were made available to non-ITU-T members via an
  ftp site. The liaison was placed on the IESG web site and was presented
  in the ccamp meeting in Salt Lake City in December. At that same meeting,
  Maarten Vissers gave a technical presentation in the sub-IP area meeting
  regarding the ITU-T work in this area.
- On February 19, 2002, ITU-T sent IETF ccamp a liaison statement regarding
  the gaps that had been identified between the ITU-T requirements (sent
  earlier) and what seemed to be implemented by the GMPLS protocols.
Specifically,
  1. Call & Connection separation, e.g., a call provides the service
     relationship, which may support connection operations as part of a
call. 
  2. Additional error codes/values, for example, for connection rejection
     (invalid connection ID). 
  3. Restart mechanisms: Depending on the introduction by the ITU of
additional
     control plane resiliency requirements, enhancements of the protocol
     (RSVP-TE, CR-LDP) "graceful restart" mechanisms may be required. 
  4. Protocol enhancements in CR-LDP for support of crankback capability
from
     intermediate nodes. 
  This liaison was presented in the Minneapolis IETF meeting during the
ccamp
  working group and posted on the IESG web site. The liaison requested
  assistance in closing these gaps and invited input from IETF on our work
  in ITU-T.
- At the April/May 2002 meeting of ITU-T Study Group 15 meeting,
contributions
  were considered to close these gaps, resulting in text for draft
Recommendations
  G.7713.2 (our rsvp-te document) and G.7713.3 (our cr-ldp document). Again,
  we sent a liaison (dated May 10, 2002) to ask for comments on our draft
  Recommendations (made available on the ftp site), to request alignment,
and
  to ask for IANA code point assignments. To quote from that liaison:
"Please consider including the proposed solutions provided in G.7713.2 and
G.7713.3
to update the existing GMPLS signaling work in support of ASON requirements.
We hope that you can help expedite the assignment of appropriate additional
error codes/values by IANA.  These are needed for both RSVP-TE and CR-LDP."
  This liaison was presented at the Yokohama IETF ccamp meeting.

  To refer to one point raised earlier in the thread, there are other cases
  where IANA has assigned codepoints for work outside of IETF, including
  other CCITT/ITU-T work, IEEE, IEC, etc. This request had been made last
  May, with no response.
- Some final work was done on our drafts at a Rapporteur meeting in October,
  with one result being another liaison (dated October 11, 2002) making
  another plea for comments and help getting the codepoints assigned. This
  liaison was presented at the Atlanta IETF ccamp meeting, and still no
  response or IANA action.

To hear now that someone thinks that the ASON work in ITU-T is some kind
of secret end-run around IETF, and not involved with or related to the
work being done internally in IETF is absurd. At every stage of the work,
IETF was kept informed of the work and invited to participate. At the
invitation for help to address the additional ITU-T requirements, there
was no response. As ITU-T progressed this work and invited further comments
and alignment of the base GMPLS protocols, again no response. And to the
final pleas for comments and codepoint assignments, no response.

I contrast this with our interaction with the ATM forum on the same topic.
Certain operators in ITU-T are interested in using the PNNI protocol for
this application (rather than rsvp-te or cr-ldp). The ATM forum has
responded with a formal liaison into the current ITU-T Study Group 15
meeting where they have given us a diffmarked copy with extremely
helpful and constructive suggestions about how to align our G.7713.1
document with their work.

After some private communication with the Area directors, we received some
advice that one tool that might be used to finally get the IANA codepoint
assignment complete would be to publish what we were doing in ITU-T as
informational RFCs. This is the stage we are at today, and given the
history I describe above, I do not think anybody can say that we are
at this point because any of us did not do everything possible to
do this work (a) in IETF, with the initial communication of requirements;
or (b) in cooperation between ITU-T and IETF, once this work had
progressed in ITU-T.

But this is all water under the bridge. We are at the point of trying
to get some codepoints assigned for ITU-T documents we are trying to
complete. Nobody should say "no" at this point because they think we
didn't try to work this IN or WITH IETF first. It should be clear to
all that this is not the case.
Regards,
Steve Trowbridge
(vice-chairman, ITU-T Study Group 15)

David Charlap wrote:
> 
> Brian Hassink wrote:
> > Didn't the IETF set the precedent by extending RSVP from an IntServ
protocol to an MPLS protocol?
> 
> There's a big difference.  MPLS and IntServ are both IETF groups.  (And
> RSVP has/had its own working group anyway).  Also, most of the key RSVP
> people were involved in the development of RSVP-TE.
> 
> This is very different from what I'm describing - where people who have
> no prior RSVP experience decide that they can start changing it without
> understing it, and without even notifying the IETF groups that did all
> of the development work.
> 
> I'mnot saying that RSVP should never be extended.  I'm saying that those
> groups that are writing extensions should be consulting with those who
> have been developing and maintaining it (in the RSVP and MPLS groups) in
> order to ensure that:
>         - Their goal can't be achieved without extending the language
>         - That their extension doesn't overlap a similar extension
>           from somebody else.
>         - That their extension doesn't significantly change the overall
>           semantics of RSVP.
>         - That their extension is sufficiently flexible so that other
>           groups can build off of it instead of re-inventing the wheel
>           with yet another incompatible extension.
> 
> Not only isn't this happening, but there appears to be no desire to see
> this happen.
> 
> -- David

Delivery-date: Thu, 23 Jan 2003 11:21:21 -0800
Date: Thu, 23 Jan 2003 14:20:22 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Kireeti Kompella <[email-masked]>
CC: "Lin, Zhi-Wei (Zhi)" <[email-masked]>, David Charlap <[email-masked]>, Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP

Kireeti,

> > The GMPLS RSVP-TE, which is done in IETF, makes major modifications to
> > RFC3209 and RFC2205 version of RSVP. The rest of the changes been
> > requested are three new objects, new error codes to support these
> > objects. This can hardly be characterized as forcibly changing RSVP or
> > major change in direction...
> 
> Do you consider deprecating ResvErr and ResvTear not "forcibly changing
> RSVP or major change in direction"?
> 

Well, it's my turn to beg to differ :) If you read the document && understand it
&& don't take any prejudice, then it may be more like specifying rules for using
a protocol for an application with some hard requirements.

Regards,

Yangguang

Delivery-date: Thu, 23 Jan 2003 11:08:32 -0800
From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, David Charlap <[email-masked]>
Cc: Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: IANA Considerations for RSVP
Date: Thu, 23 Jan 2003 14:08:09 -0500

Hi Kireeti,

Please visit the IESG page, go to I-D tracker, and search under the document...

If you don't know this site, here it is: https://datatracker.ietf.org/public/pidtracker.cgi

Under filename, search for "draft-lin"

Then hit the "Detail" button under the "In State: RFC Editor Queue" header.

I guess some IETF WG chairs don't pay attention to this...

Zhi

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 1:59 PM
To: David Charlap
Cc: Bob Braden; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: IANA Considerations for RSVP

> I must have struck a nerve here, because yours is the second response
> I've gotten from somebody who thinks I'm referring to their specific
> IETF-approved RSVP extension, even though I specifically said I'm
> referring to extensions developed without IETF involvement.

If you are under the impression that
draft-lin-ccamp-gmpls-ason-rsvpte-04.txt is "IETF approved", I don't
blame you.  But in fact, it is not (yet).  And even if it does get
approval, it is as an *Informational* document.

But you have struck a nerve with some (and a chord with me :-))

Kireeti.

Delivery-date: Thu, 23 Jan 2003 11:05:17 -0800
From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, "Lin, Zhi-Wei (Zhi)" <[email-masked]>
Cc: David Charlap <[email-masked]>, Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: IANA Considerations for RSVP
Date: Thu, 23 Jan 2003 14:04:20 -0500

Hi Kireeti,

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 1:53 PM
To: Lin, Zhi-Wei (Zhi)
Cc: David Charlap; Bob Braden; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: IANA Considerations for RSVP

Hi Zhi,

On Thu, 23 Jan 2003, Lin, Zhi-Wei (Zhi) wrote:

> Hi David,
>
> This seems like an unfair characterization. All requests are submitted
> by individuals. In terms of changing these protocols...

I beg to differ.  The publication request of the original RSVP-TE spec was
made *by the MPLS WG*.  The publication request of the GMPLS RSVP spec was
makde *by the CCAMP WG*.  Furthermore, the issue is not who submits the
document; it is the degree of scrutiny it gets.  *Standards Track* docs
go through a much stricter review than informational ones.

<zhi>Right. the set of ASON documents are all targeted for informational RFC, though and not standards track. It was recommended that such document should be submitted to assist IANA with codepoint assignment, and that's what was done...

In terms of degree of scrutiny, please see Steve's email on the history of trying to get feedback...this was really "like pulling teeth"...</zhi>

> The GMPLS RSVP-TE, which is done in IETF, makes major modifications to
> RFC3209 and RFC2205 version of RSVP. The rest of the changes been
> requested are three new objects, new error codes to support these
> objects. This can hardly be characterized as forcibly changing RSVP or
> major change in direction...

Do you consider deprecating ResvErr and ResvTear not "forcibly changing
RSVP or major change in direction"?

<zhi>I don't understand...where do you see that these are deprecated??? What is said in my document is that these messages we don't create because all teardowns are explicit. But when these are received, then we will take appropriate actions (see document).

Do you consider that if we don't transmit a message then this is in violation of the protocol? We're transmitting all messages in accordance with RFC2205/3209/GMPLS-RSVP-TE...There are approximately 20 message types, but GMPLS RSVP-TE only use a sub-set that's important to its function (e.g., DREQ and DREP are not mandatory for GMPLS RSVP-TE)...
</zhi>

Kireeti.

Delivery-date: Thu, 23 Jan 2003 11:00:05 -0800
Date: Thu, 23 Jan 2003 10:59:04 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: David Charlap <[email-masked]>
cc: Bob Braden <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: IANA Considerations for RSVP

> I must have struck a nerve here, because yours is the second response
> I've gotten from somebody who thinks I'm referring to their specific
> IETF-approved RSVP extension, even though I specifically said I'm
> referring to extensions developed without IETF involvement.

If you are under the impression that
draft-lin-ccamp-gmpls-ason-rsvpte-04.txt is "IETF approved", I don't
blame you.  But in fact, it is not (yet).  And even if it does get
approval, it is as an *Informational* document.

But you have struck a nerve with some (and a chord with me :-))

Kireeti.

Delivery-date: Thu, 23 Jan 2003 10:53:29 -0800
Date: Thu, 23 Jan 2003 10:52:30 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
cc: David Charlap <[email-masked]>, Bob Braden <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: IANA Considerations for RSVP

Hi Zhi,

On Thu, 23 Jan 2003, Lin, Zhi-Wei (Zhi) wrote:

> Hi David,
>
> This seems like an unfair characterization. All requests are submitted
> by individuals. In terms of changing these protocols...

I beg to differ.  The publication request of the original RSVP-TE spec was
made *by the MPLS WG*.  The publication request of the GMPLS RSVP spec was
makde *by the CCAMP WG*.  Furthermore, the issue is not who submits the
document; it is the degree of scrutiny it gets.  *Standards Track* docs
go through a much stricter review than informational ones.

> The GMPLS RSVP-TE, which is done in IETF, makes major modifications to
> RFC3209 and RFC2205 version of RSVP. The rest of the changes been
> requested are three new objects, new error codes to support these
> objects. This can hardly be characterized as forcibly changing RSVP or
> major change in direction...

Do you consider deprecating ResvErr and ResvTear not "forcibly changing
RSVP or major change in direction"?

Kireeti.

Delivery-date: Thu, 23 Jan 2003 10:43:31 -0800
Date: Thu, 23 Jan 2003 10:42:40 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: David Charlap <[email-masked]>
cc: Bob Braden <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: IANA Considerations for RSVP

Hi David,

On Thu, 23 Jan 2003, David Charlap wrote:

> This is very different from what I'm describing - where people who have
> no prior RSVP experience decide that they can start changing it without
> understing it, and without even notifying the IETF groups that did all
> of the development work.

Just notifying is insufficient.  A detailed review, the ability to make
comments and changes, going through the IETF process (such as it is)
is MANDATORY for protocol changes.  Moreover, making the spec standards
track means that new specs can cite it *normatively*.

<clipped>

> Not only isn't this happening, but there appears to be no desire to see
> this happen.

Well, it's like pulling teeth.  But we're on the first step -- you can
thank Bob for that!

Kireeti.

Delivery-date: Thu, 23 Jan 2003 10:39:10 -0800
Date: Thu, 23 Jan 2003 10:37:30 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: David Charlap <[email-masked]>
cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: IANA Considerations for RSVP

Hi David,

On Thu, 23 Jan 2003, David Charlap wrote:

> Bob Braden wrote:
> >
> > There is a growing unease about IANA assignments of RSVP parameters --
> > object numbers, CTypes, message types, and error numbers -- for new
> > uses of RSVP.  Many of these IANA requests, but not all, originate
> > outside the IETF in other standards bodies.  Many of the people from
> > outside the IETF were not part of the RSVP working group and so did not
> > absorb the technical rationale behind RSVP; in fact, they are sometimes
> > barely clued into IETF procedures at all.
>
> I've noticed the same thing.  It seems that many non-IETF groups want to
> use RSVP, and all believe that they must create extensions to the
> protocol for their features, often without first bothering to check if
> there are already obects defined by IETF standards that already serve
> their purposes.  And even in those cases where new objects may be
> required, the proposed objects are often defined as having semantics
> that differ greatly from the way RSVP usually operates.

Glad to hear you say that!

> In other words, these groups seem to want to forcibly change RSVP into a
> protocol that more closely resembles some other protocol that they're
> more intimately familiar with.

No comment :)

> Unfortunately, I don't know what can be done about this.

It's not that hard.  As Bob said, redo the IANA Considerations
(and not just for RSVP) to require *well* documented specs that
go through tighter screening in the appropriate WGs.

Kireeti.

Delivery-date: Thu, 23 Jan 2003 09:52:54 -0800
From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
To: [email-masked], "Lin, Zhi-Wei (Zhi)" <[email-masked]>
Cc: David Charlap <[email-masked]>, Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: IANA Considerations for RSVP
Date: Thu, 23 Jan 2003 12:52:17 -0500

Hi Eric,

Please see Steve's email on the history. After reading that, I hope you would change your mind about the "fait accompli" remark...

Thanks
Zhi

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 12:43 PM
To: Lin, Zhi-Wei (Zhi)
Cc: David Charlap; Bob Braden; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: IANA Considerations for RSVP

Zhi,

    Yours may be an equally unfair characterization.  In general, the reaction
in the IETF to any intended RFC submitted as a 'fait accompli' is similar to
what you are seeing here - regardless of whether it came from an individual
or an organization representative.

"Lin, Zhi-Wei (Zhi)" wrote:

> Hi David,
>
> This seems like an unfair characterization. All requests are submitted by individuals. In terms of changing these protocols...
>

...

Delivery-date: Thu, 23 Jan 2003 09:21:53 -0800
Date: Thu, 23 Jan 2003 10:21:15 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: David Charlap <[email-masked]>
CC: Brian Hassink <[email-masked]>, Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP

David,
To read these emails, it sounds as though you think that the people who
are doing this are brand new to the technology and never even considered
working with IETF to try to solve the problem. Perhaps you haven't followed
the ccamp work so closely, but here is some history:
- On October 21, 2001, ITU-T Study Group 15 sent IETF ccamp a liaison statement
  regarding our new documents with requirements and architecture for
  switched (not necessarily IP) transport networks. This included a protocol-
  neutral model for call and connection management (signaling). In copies
  of the ITU-T documents were made available to non-ITU-T members via an
  ftp site. The liaison was placed on the IESG web site and was presented
  in the ccamp meeting in Salt Lake City in December. At that same meeting,
  Maarten Vissers gave a technical presentation in the sub-IP area meeting
  regarding the ITU-T work in this area.
- On February 19, 2002, ITU-T sent IETF ccamp a liaison statement regarding
  the gaps that had been identified between the ITU-T requirements (sent
  earlier) and what seemed to be implemented by the GMPLS protocols. Specifically,
  1. Call & Connection separation, e.g., a call provides the service
     relationship, which may support connection operations as part of a call. 
  2. Additional error codes/values, for example, for connection rejection
     (invalid connection ID). 
  3. Restart mechanisms: Depending on the introduction by the ITU of additional
     control plane resiliency requirements, enhancements of the protocol
     (RSVP-TE, CR-LDP) "graceful restart" mechanisms may be required. 
  4. Protocol enhancements in CR-LDP for support of crankback capability from
     intermediate nodes. 
  This liaison was presented in the Minneapolis IETF meeting during the ccamp
  working group and posted on the IESG web site. The liaison requested
  assistance in closing these gaps and invited input from IETF on our work
  in ITU-T.
- At the April/May 2002 meeting of ITU-T Study Group 15 meeting, contributions
  were considered to close these gaps, resulting in text for draft Recommendations
  G.7713.2 (our rsvp-te document) and G.7713.3 (our cr-ldp document). Again,
  we sent a liaison (dated May 10, 2002) to ask for comments on our draft
  Recommendations (made available on the ftp site), to request alignment, and
  to ask for IANA code point assignments. To quote from that liaison:
"Please consider including the proposed solutions provided in G.7713.2 and G.7713.3
to update the existing GMPLS signaling work in support of ASON requirements.
We hope that you can help expedite the assignment of appropriate additional
error codes/values by IANA.  These are needed for both RSVP-TE and CR-LDP."
  This liaison was presented at the Yokohama IETF ccamp meeting.

  To refer to one point raised earlier in the thread, there are other cases
  where IANA has assigned codepoints for work outside of IETF, including
  other CCITT/ITU-T work, IEEE, IEC, etc. This request had been made last
  May, with no response.
- Some final work was done on our drafts at a Rapporteur meeting in October,
  with one result being another liaison (dated October 11, 2002) making
  another plea for comments and help getting the codepoints assigned. This
  liaison was presented at the Atlanta IETF ccamp meeting, and still no
  response or IANA action.

To hear now that someone thinks that the ASON work in ITU-T is some kind
of secret end-run around IETF, and not involved with or related to the
work being done internally in IETF is absurd. At every stage of the work,
IETF was kept informed of the work and invited to participate. At the
invitation for help to address the additional ITU-T requirements, there
was no response. As ITU-T progressed this work and invited further comments
and alignment of the base GMPLS protocols, again no response. And to the
final pleas for comments and codepoint assignments, no response.

I contrast this with our interaction with the ATM forum on the same topic.
Certain operators in ITU-T are interested in using the PNNI protocol for
this application (rather than rsvp-te or cr-ldp). The ATM forum has
responded with a formal liaison into the current ITU-T Study Group 15
meeting where they have given us a diffmarked copy with extremely
helpful and constructive suggestions about how to align our G.7713.1
document with their work.

After some private communication with the Area directors, we received some
advice that one tool that might be used to finally get the IANA codepoint
assignment complete would be to publish what we were doing in ITU-T as
informational RFCs. This is the stage we are at today, and given the
history I describe above, I do not think anybody can say that we are
at this point because any of us did not do everything possible to
do this work (a) in IETF, with the initial communication of requirements;
or (b) in cooperation between ITU-T and IETF, once this work had
progressed in ITU-T.

But this is all water under the bridge. We are at the point of trying
to get some codepoints assigned for ITU-T documents we are trying to
complete. Nobody should say "no" at this point because they think we
didn't try to work this IN or WITH IETF first. It should be clear to
all that this is not the case.
Regards,
Steve Trowbridge
(vice-chairman, ITU-T Study Group 15)

David Charlap wrote:
> 
> Brian Hassink wrote:
> > Didn't the IETF set the precedent by extending RSVP from an IntServ protocol to an MPLS protocol?
> 
> There's a big difference.  MPLS and IntServ are both IETF groups.  (And
> RSVP has/had its own working group anyway).  Also, most of the key RSVP
> people were involved in the development of RSVP-TE.
> 
> This is very different from what I'm describing - where people who have
> no prior RSVP experience decide that they can start changing it without
> understing it, and without even notifying the IETF groups that did all
> of the development work.
> 
> I'mnot saying that RSVP should never be extended.  I'm saying that those
> groups that are writing extensions should be consulting with those who
> have been developing and maintaining it (in the RSVP and MPLS groups) in
> order to ensure that:
>         - Their goal can't be achieved without extending the language
>         - That their extension doesn't overlap a similar extension
>           from somebody else.
>         - That their extension doesn't significantly change the overall
>           semantics of RSVP.
>         - That their extension is sufficiently flexible so that other
>           groups can build off of it instead of re-inventing the wheel
>           with yet another incompatible extension.
> 
> Not only isn't this happening, but there appears to be no desire to see
> this happen.
> 
> -- David

Delivery-date: Thu, 23 Jan 2003 09:16:45 -0800
Date: Thu, 23 Jan 2003 12:15:21 -0500
From: Scott W Brim <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP
Mail-Followup-To: Scott W Brim <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Sorry, accidentally narrowed the list.

Date: Thu, 23 Jan 2003 12:08:11 -0500
From: Scott W Brim <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP

On Wed, Jan 22, 2003 09:40:12PM +0000, Bob Braden allegedly wrote:
> 3. The IANA Considerations draft should be published as an RFC,
> 	perhaps after updating.  Here are some issues that might affect
> 	this update.

All good ideas, but they still don't lead to integration.  In ATM you
find a (personal opinion) hodgepodge of overlapping capabilities in the
signaling IEs because of the lack of strict control and insistence on
coordinated engineering.  Keep the idea of a separate name space in the
back pocket and try for better.  Incrementally, perhaps have just one
more name class, "non-IETF" and insist on a statement that the group
proposing the new extension document how it interacts with existing
ones.  But, if you're going to do that, you could insist on that
documentation and not have the different categories.  Whatever you think
we can pull off.

> 		Must there be an Internet Draft? An RFC?  We have
> 		tended towards the RFC, but the result is less than
> 		satisfactory.  These extensions are typically
> 		documented in some 373- page document published (or
> 		more often hidden) by the other standards body.  The
> 		I-D/RFC that is written for registration presents only
> 		a superficial summary of the data structures to be
> 		defined, with no context of explanation,  and a
> 		reference to the real 373 page document.

There must be an RFC, even if status is informational.  documentation
must be in space that's visible to users of RSVP, and that means
publicly visible, not restricted to members of bodies who are requesting
the extensions.  

.Scott

Delivery-date: Thu, 23 Jan 2003 09:10:51 -0800
Date: Thu, 23 Jan 2003 12:09:35 -0500
From: Scott W Brim <[email-masked]>
To: Brian Hassink <[email-masked]>
Cc: David Charlap <[email-masked]>, Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP
Mail-Followup-To: Scott W Brim <[email-masked]>, Brian Hassink <[email-masked]>, David Charlap <[email-masked]>, Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

On Thu, Jan 23, 2003 11:06:53AM -0500, Brian Hassink allegedly wrote:
> Didn't the IETF set the precedent by extending RSVP from an IntServ
> protocol to an MPLS protocol?

Check the documentation.  RSVP is not an intserv protocol.  It's
(potentially) used by intserv.  It's also used for other things.

Delivery-date: Thu, 23 Jan 2003 09:09:01 -0800
Date: Thu, 23 Jan 2003 12:08:11 -0500
From: Scott W Brim <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP
Mail-Followup-To: Scott W Brim <[email-masked]>, [email-masked], [email-masked]

On Wed, Jan 22, 2003 09:40:12PM +0000, Bob Braden allegedly wrote:
> 3. The IANA Considerations draft should be published as an RFC,
> 	perhaps after updating.  Here are some issues that might affect
> 	this update.

All good ideas, but they still don't lead to integration.  In ATM you
find a (personal opinion) hodgepodge of overlapping capabilities in the
signaling IEs because of the lack of strict control and insistence on
coordinated engineering.  Keep the idea of a separate name space in the
back pocket and try for better.  Incrementally, perhaps have just one
more name class, "non-IETF" and insist on a statement that the group
proposing the new extension document how it interacts with existing
ones.  But, if you're going to do that, you could insist on that
documentation and not have the different categories.  Whatever you think
we can pull off.

> 		Must there be an Internet Draft? An RFC?  We have
> 		tended towards the RFC, but the result is less than
> 		satisfactory.  These extensions are typically
> 		documented in some 373- page document published (or
> 		more often hidden) by the other standards body.  The
> 		I-D/RFC that is written for registration presents only
> 		a superficial summary of the data structures to be
> 		defined, with no context of explanation,  and a
> 		reference to the real 373 page document.

There must be an RFC, even if status is informational.  documentation
must be in space that's visible to users of RSVP, and that means
publicly visible, not restricted to members of bodies who are requesting
the extensions.  

..Scott

Delivery-date: Thu, 23 Jan 2003 09:07:12 -0800
Date: Thu, 23 Jan 2003 09:06:17 -0800
From: Jonathan Lang <[email-masked]>
Reply-To: [email-masked]
To: [email-masked],  [email-masked],  [email-masked]
Subject: [Fwd: Re: IANA Considerations for RSVP]

I accidentally omitted Bob, CCAMP, and rsvp list from my original 
response.  Apologize in advance if you receive multiple copies.

Thanks,
Jonathan

-------- Original Message --------
Subject: Re: IANA Considerations for RSVP
Date: Thu, 23 Jan 2003 08:33:14 -0800
From: Jonathan Lang <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked]
References: <[email-masked]>

Bob,

Bob Braden wrote:

 >Hardy friends who have stuck it out on the RSVP mailing list:
 >
 ><snip>
 >	3. The IANA Considerations draft should be published as an RFC,
 >	perhaps after updating.  Here are some issues that might affect
 >	this update.
 >
I concur.  There needs to be an IANA Considerations draft published as
an RFC.

 >
 >	(A) How to handle requests for RSVP assignments for
 >		extensions developed outside IETF?
 >
 >	    Here is my suggestion:
 >
 >		For all assignments of numbers for extensions defined
 >		in non-IETF standards bodies, the IANA should use
 >		assignment names (e.g., object names) that are prefixed
 >		with the name of the responsible standards body.  For
 >		example, the "SPIFFY_SESSION" object would become
 >		"ATM_FORUM_SPIFFY_SESSION" or "ITU-T_SPIFFY_SESSION",
 >		etc., object.
 >
This is fine, but I'm not sure it's enough.  For example, the following
text came from an email posted on the ietf discussion list by Zhi, the
editor of "draft-lin-ccamp-gmpls-ason-rsvpte-04.txt", in response to a
debate about this very issue.

<zhi>Last time I checked, the IETF didn't change the protocols, 
individuals did through contributions.  The extensions requested for 
Call/Connection control were submitted by an individual.  The fact the 
ITU weighed in requesting approval of the changes is a separate issue.</zhi>

So if this was an individual contribution, then it wouldn't be tagged
"ITU-T_SPIFFY_SESSION"?

 >
 >	(B) What policies should be imposed?
 >
 >		The document currently divides the assignment space into
 >		two subspaces, for "IETF Consensus" and "FCFS".  RFC
 >		2434 lists various other possibilities; do we need any?
 >
 >		Precisely what do we mean by IETF consensus?  Does this
 >		require a standards-track document?  (We thought it did.)
 >
 >		We assumed that non-IETF requests would necessarily go to
 >		FCFS, but is it really FCFS + expert opinion?  In other
 >		words, how much oversight should we try to exert for
 >		non-IETF RSVP extensions?  I have seen some highly
 >		questionable extensions.  They tend to be micro-engineering,
 >		with no sense of a larger design.
 >
I would prefer that the majority of the assignments require
standards-track documents.  A few assignments could be left for "IETF
Consensus", which I don't think requires standards track ID.  And then a
few assignements for "experimental".

Thanks,
Jonathan

 >
 >	(C) What are the appropriate documentation requirements?
 >
 >		Must there be an Internet Draft? An RFC?  We have
 >		tended towards the RFC, but the result is less than
 >		satisfactory.  These extensions are typically
 >		documented in some 373- page document published (or
 >		more often hidden) by the other standards body.  The
 >		I-D/RFC that is written for registration presents only
 >		a superficial summary of the data structures to be
 >		defined, with no context of explanation,  and a
 >		reference to the real 373 page document.
 >
 >Bob Braden
 >Former co-chair of the RSVP WG
 >Current designated expert for RSVP assignments by IANA
 >
 >
 >
 >----- End Included Message -----
 >
 >
 >
 >

Delivery-date: Thu, 23 Jan 2003 09:03:02 -0800
From: "Mak, L (Leen)" <[email-masked]>
To: "'David Charlap'" <[email-masked]>, Bob Braden <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>
Subject: RE: IANA Considerations for RSVP
Date: Thu, 23 Jan 2003 18:01:15 +0100

David

You wrote:

> In other words, these groups seem to want to forcibly change 
> RSVP into a protocol that more closely resembles some other 
> protocol that they're more intimately familiar with.

My recollection of history brings me to a little paraphrasing of
your statement:

- In other words, the IETF seemed to want to forcibly change 
- transport networking into a thing that more closely resembles 
- some other network that they're more intimately familiar with.

If you agree, let's than put the pots and the kettles where they
belong and join forces on a constructive way forward. That is
in our common interest.

Leen Mak.

Delivery-date: Thu, 23 Jan 2003 09:02:56 -0800
Date: Thu, 23 Jan 2003 12:01:37 -0500
From: David Charlap <[email-masked]>
Organization: Marconi, Vienna VA
To: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
CC: Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP

Lin, Zhi-Wei (Zhi) wrote:
 >
 > The GMPLS RSVP-TE, which is done in IETF, makes major modifications
 > to RFC3209 and RFC2205 version of RSVP. The rest of the changes been
 > requested are three new objects, new error codes to support these
 > objects. This can hardly be characterized as forcibly changing RSVP
 > or major change in direction...

I am not criticizing the existance of GMPLS or the CCAMP work that's 
being done.  All of the IETF people involved in RSVP are aware of this 
and contribute to it as they feel necessary.

I'm far more concerned with non-IETF groups (like ITU, ATM Forum and 
others) deciding to develop their own incompatible extensions without 
even informing any IETF groups of their actions.

Groups like these should not be extending IETF protocols without 
consulting with the relevant IETF working groups.  Otherwise we end up 
with extensions that duplicate existing IETF functionality, don't 
coexist gracefully, and/or break interoperability.  And if these 
extensions become popular in products, the IETF will be forced to 
include them in the standards in order to prevent future IETF work from 
breaking them.

 > The extensions that's been requested were derived as a result of
 > discussions and efforts involving many IETF people as well (e.g.,
 > please look at the author list of the OIF UNI document). Your comment
 > seems to suggest that the work appear out of nowhere with no
 > participation from the IETF RSVP experts...this is clearly not
 > true...

I am not referring to OIF UNI.  They are doing consulting with relevant 
IETF groups as a part of their work.

I must have struck a nerve here, because yours is the second response 
I've gotten from somebody who thinks I'm referring to their specific 
IETF-approved RSVP extension, even though I specifically said I'm 
referring to extensions developed without IETF involvement.  And I think 
that was Bob's original issue as well - since he explicitly mentioned 
IANA RSVP requests coming from non-IETF sources.

-- David

Delivery-date: Thu, 23 Jan 2003 08:49:22 -0800
From: "Ong, Lyndon" <[email-masked]>
To: "'Lin, Zhi-Wei (Zhi)'" <[email-masked]>, David Charlap <[email-masked]>, Bob Braden <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: IANA Considerations for RSVP
Date: Thu, 23 Jan 2003 08:48:53 -0800

Folks,

Keep in mind also that we are talking about the application of RSVP
to switched transport networks (i.e., SDH), not to IP networks directly.
This is the scope of the ITU specification that would use these
extensions.

Cheers,

Lyndon Ong

Delivery-date: Thu, 23 Jan 2003 08:42:46 -0800
From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
To: David Charlap <[email-masked]>, Brian Hassink <[email-masked]>
Cc: Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], "Wesam Alanqar (E-mail)" <[email-masked]>, "Mark Jones (E-mail)" <[email-masked]>
Subject: RE: IANA Considerations for RSVP
Date: Thu, 23 Jan 2003 11:42:14 -0500

Hi David,

I responded to an earlier message (you probably haven't seen it yet), but I just want to re-iterate some points here, especially the point about not wanting to work together.

I'm not sure whether you've followed the work in CCAMP WG, but I've made the point that the ITU-T has notified and provided status as well as their "draft" documents to IETF consistently and regularly for the last few IEFT CCAMP WG meetings.

As such, your point that you gave below I take it to imply that you either (1) have not followed the recent work in CCAMP, or (2) you choose to selectively ignore the work submitted to CCAMP. 

In either case I don't think this should be blamed on the folks who's (individually) submitted the work to IETF as individuals who are full-fledged members of the IETF community...

Zhi

-----Original Message-----
From: David Charlap [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 11:15 AM
To: Brian Hassink
Cc: Bob Braden; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: IANA Considerations for RSVP

Brian Hassink wrote:
> Didn't the IETF set the precedent by extending RSVP from an IntServ protocol to an MPLS protocol?

There's a big difference.  MPLS and IntServ are both IETF groups.  (And 
RSVP has/had its own working group anyway).  Also, most of the key RSVP 
people were involved in the development of RSVP-TE.

This is very different from what I'm describing - where people who have 
no prior RSVP experience decide that they can start changing it without 
understing it, and without even notifying the IETF groups that did all 
of the development work.

I'mnot saying that RSVP should never be extended.  I'm saying that those 
groups that are writing extensions should be consulting with those who 
have been developing and maintaining it (in the RSVP and MPLS groups) in 
order to ensure that:
	- Their goal can't be achieved without extending the language
	- That their extension doesn't overlap a similar extension
	  from somebody else.
	- That their extension doesn't significantly change the overall
	  semantics of RSVP.
	- That their extension is sufficiently flexible so that other
	  groups can build off of it instead of re-inventing the wheel
	  with yet another incompatible extension.

Not only isn't this happening, but there appears to be no desire to see 
this happen.

-- David

Delivery-date: Thu, 23 Jan 2003 08:32:47 -0800
From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
To: David Charlap <[email-masked]>, Bob Braden <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: IANA Considerations for RSVP
Date: Thu, 23 Jan 2003 11:31:59 -0500

Hi David,

This seems like an unfair characterization. All requests are submitted by individuals. In terms of changing these protocols...

The GMPLS RSVP-TE, which is done in IETF, makes major modifications to RFC3209 and RFC2205 version of RSVP. The rest of the changes been requested are three new objects, new error codes to support these objects. This can hardly be characterized as forcibly changing RSVP or major change in direction...

The extensions that's been requested were derived as a result of discussions and efforts involving many IETF people as well (e.g., please look at the author list of the OIF UNI document). Your comment seems to suggest that the work appear out of nowhere with no participation from the IETF RSVP experts...this is clearly not true...

If you recall, throughout the development of the GMPLS RSVP-TE, the non-RSVP experts (I guess you would lump me in this category as well) provided major comments. As a non-RSVP expert, I tried my best to understand the original goal of RSVP; however, I did not make the initial decision to use RSVP for supporting control plane for transport network. This decision was made collectively by the sub-IP area and thus the GMPLS RSVP was born...

But I think much of this is simply related to the current (lack of) process and procedural issues. These can be dealt with (possibly) at the next meeting, and a clear process should be put in place on how IETF would work with other standards organizations. But this is for the future...

Zhi

-----Original Message-----
From: David Charlap [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 10:56 AM
To: Bob Braden
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: IANA Considerations for RSVP

Bob Braden wrote:
> 
> There is a growing unease about IANA assignments of RSVP parameters --
> object numbers, CTypes, message types, and error numbers -- for new
> uses of RSVP.  Many of these IANA requests, but not all, originate
> outside the IETF in other standards bodies.  Many of the people from
> outside the IETF were not part of the RSVP working group and so did not
> absorb the technical rationale behind RSVP; in fact, they are sometimes
> barely clued into IETF procedures at all.

I've noticed the same thing.  It seems that many non-IETF groups want to 
use RSVP, and all believe that they must create extensions to the 
protocol for their features, often without first bothering to check if 
there are already obects defined by IETF standards that already serve 
their purposes.  And even in those cases where new objects may be 
required, the proposed objects are often defined as having semantics 
that differ greatly from the way RSVP usually operates.

In other words, these groups seem to want to forcibly change RSVP into a 
protocol that more closely resembles some other protocol that they're 
more intimately familiar with.

Personally, I don't like this.  These groups should step back and decide 
if RSVP is really what they need.  If they require a different protocol, 
then they should use a different protocol - they should not glom onto 
RSVP just because it's popular in MPLS and then try to change it into 
what they really want.  This is especially true in those situations 
where their proposed changes would produce a fundamentally incompatible 
protocol.

Unfortunately, I don't know what can be done about this.  These groups 
seem hell-bent on hacking up RSVP without first learning it's design 
philosophy.  If they don't get assignments from IANA, they'll probably 
just make their own assignments without any coordinating facility, and 
we'll wind up with several mutually incompatible protocols that all want 
to call themselves "RSVP".

-- David

Delivery-date: Thu, 23 Jan 2003 08:15:54 -0800
Date: Thu, 23 Jan 2003 11:15:21 -0500
From: David Charlap <[email-masked]>
Organization: Marconi, Vienna VA
To: Brian Hassink <[email-masked]>
CC: Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP

Brian Hassink wrote:
> Didn't the IETF set the precedent by extending RSVP from an IntServ protocol to an MPLS protocol?

There's a big difference.  MPLS and IntServ are both IETF groups.  (And 
RSVP has/had its own working group anyway).  Also, most of the key RSVP 
people were involved in the development of RSVP-TE.

This is very different from what I'm describing - where people who have 
no prior RSVP experience decide that they can start changing it without 
understing it, and without even notifying the IETF groups that did all 
of the development work.

I'mnot saying that RSVP should never be extended.  I'm saying that those 
groups that are writing extensions should be consulting with those who 
have been developing and maintaining it (in the RSVP and MPLS groups) in 
order to ensure that:
	- Their goal can't be achieved without extending the language
	- That their extension doesn't overlap a similar extension
	  from somebody else.
	- That their extension doesn't significantly change the overall
	  semantics of RSVP.
	- That their extension is sufficiently flexible so that other
	  groups can build off of it instead of re-inventing the wheel
	  with yet another incompatible extension.

Not only isn't this happening, but there appears to be no desire to see 
this happen.

-- David

Delivery-date: Thu, 23 Jan 2003 07:58:11 -0800
Date: Thu, 23 Jan 2003 10:55:50 -0500
From: David Charlap <[email-masked]>
Organization: Marconi, Vienna VA
To: Bob Braden <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IANA Considerations for RSVP

Bob Braden wrote:
> 
> There is a growing unease about IANA assignments of RSVP parameters --
> object numbers, CTypes, message types, and error numbers -- for new
> uses of RSVP.  Many of these IANA requests, but not all, originate
> outside the IETF in other standards bodies.  Many of the people from
> outside the IETF were not part of the RSVP working group and so did not
> absorb the technical rationale behind RSVP; in fact, they are sometimes
> barely clued into IETF procedures at all.

I've noticed the same thing.  It seems that many non-IETF groups want to 
use RSVP, and all believe that they must create extensions to the 
protocol for their features, often without first bothering to check if 
there are already obects defined by IETF standards that already serve 
their purposes.  And even in those cases where new objects may be 
required, the proposed objects are often defined as having semantics 
that differ greatly from the way RSVP usually operates.

In other words, these groups seem to want to forcibly change RSVP into a 
protocol that more closely resembles some other protocol that they're 
more intimately familiar with.

Personally, I don't like this.  These groups should step back and decide 
if RSVP is really what they need.  If they require a different protocol, 
then they should use a different protocol - they should not glom onto 
RSVP just because it's popular in MPLS and then try to change it into 
what they really want.  This is especially true in those situations 
where their proposed changes would produce a fundamentally incompatible 
protocol.

Unfortunately, I don't know what can be done about this.  These groups 
seem hell-bent on hacking up RSVP without first learning it's design 
philosophy.  If they don't get assignments from IANA, they'll probably 
just make their own assignments without any coordinating facility, and 
we'll wind up with several mutually incompatible protocols that all want 
to call themselves "RSVP".

-- David

Delivery-date: Tue, 21 Jan 2003 19:51:13 -0800
From: Abhimanyu Das <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Control and data link association..
Date: Tue, 21 Jan 2003 19:48:21 -0800

   I had a question relating to control-link data-link associations in
GMPLS. Is there an apriori association of data channels to specific control
channels on a given node? Suppose two nodes have a single data link between
them, but they have multiple IP control channels betwen them. Is there a
requirement from a protocol perspective at a node, to specify and use only
one particular IP control channel  for the given data link, so that, for
example, all signaling traffic related to that data link must travel over
the specified control channel only? Or is it the case that control packets
for the particular data link could be routed over any of the control
channels between the two nodes, as long as the control packets reach the
neighboring node..

Thanks,
-Abhimanyu 

Delivery-date: Mon, 20 Jan 2003 04:52:27 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-analysis-00.txt
Date: Mon, 20 Jan 2003 07:46:45 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Analysis of Generalized MPLS-based Recovery Mechanisms
                          (including Protection and Restoration)
	Author(s)	: D. Papadimitriou, E. Mannie
	Filename	: draft-ietf-ccamp-gmpls-recovery-analysis-00.txt
	Pages		: 39
	Date		: 2003-1-17
	
This document provides an analysis grid that can be used to
evaluate, compare and contrast the numerous Generalized MPLS
(GMPLS)-based recovery mechanisms currently proposed at the CCAMP
Working Group. A detailed analysis of each of the recovery phases is
provided using the terminology defined in [CCAMP-TERM]. Also, this
document focuses on transport plane survivability and recovery
issues and not on control plane resilience and related aspects.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-recovery-analysis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-recovery-analysis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Sun, 19 Jan 2003 15:31:56 -0800
Date: Sun, 19 Jan 2003 18:29:50 -0500
From: Ron Bonica <[email-masked]>
Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-test-sonet-sdh-00
To: [email-masked]

Folks,

This message ends last call on draft-ietf-ccamp-lmp-test-sonet-sdh-00. (My
appologies for not having sent this message on December 20).

                            Ron

> -----Original Message-----
> From: Ron Bonica [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 9:03 AM
> To: [email-masked]
> Subject: WG Last Call: draft-ietf-ccamp-lmp-test-sonet-sdh-00
>
>
> Folks,
>
> This message begins a Working Group last call on
> draft-ietf-ccamp-lmp-test-sonet-sdh-00. Last call will end two
> weeks from today, on December 20, 2002.
>
> ===========================================
> Ronald P. Bonica       Ph: 703 886 1681
> vBNS Engineering       page: 1 888 268 8021
> Ashburn, Va.
> ===========================================
> "We are not on Earth to guard a museum, but
> to cultivate a flourishing garden of life."
>                 -- Angelo Giuseppe Roncalli

Delivery-date: Wed, 15 Jan 2003 14:31:17 -0800
Date: Wed, 15 Jan 2003 23:29:22 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: Charles Chen <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt

hi see-line...

Charles Chen wrote:
> 
> Hi Dimitri,
> 
> See inline,
> 
> > > The second issue is how the core node identifies whether the
> > > TE link configured, or discovered via LMP, is attached to
> > an edge node. In
> > > other words, does this need any support from LMP?
> >
> > since lmp allows the exchange of switching capability supported
> > at the end-points (see lmp sect. 13.12.1.1), the use of method
> > (described also in gmpls-routing) would deliver you links such
> > that [PSC, LSC] refers to a link between a packet LSR and an OXC,
> > we would then assume that this te link inter-connects an edge
> > with a core node
> >
> 
> Whether a TE link is able to support more than one switching capability or
> not has no relation to whether a node attached to it is a core
> node or edge node. A core node which supports both LSR and OXC on a TE link
> could
> advertise it as both PSC and TDM. 

i think you took this as a "rule" why i have responded
to a potential way to deliver this - i know that this 
may become an issue if multiple switching capabilities 
are supported => what you have to do is to select what
you'd support for your edge node requests (the only 
complexity i see is when the client support more than 
one of these switching capabilities)

> In addition, for any given LSP, all TE
> links
> associated with the LSP must have the same switching capability. 

from a signalling viewpoint it is today clearly indicated
that "Indicates the type of switching that should be performed 
on a particular link. This field is needed for links that 
advertise more than one type of switching capability." i 
don't know how you have inferred the above rule from this  
- also the lsp hierarchy drafts explains how to cross an 
lsp region in all its details (see section 7.1) in a sense
what described in this document is how to emulate overlays
thus the methods proposed there should be fine tunable in
the context you describe here above

> The
> switching
> capability is designed to faciliate the CSPF path selection for a given LSP
> type (TDM, LSR, OXC, etc).

your te link infers its own switching capability from the 
above thus it will become psc capable or whatever the 
edge node supports, it seems you took my example as a rule
 
> Take one example, if an edge device attached to the TDM core network
> supports two
> types of client signals (TDM/SONET and Ethernet over SONET via X.86 or GFP)
> for a "TDM"
> LSP request, then I think the TE link attached to the edge device should
> advertise
> the switching capability of the TE link as TDM, and then use the g-pid to
> represent the client
> signal for a LSP request. It will be incorrect to say that the TE link in
> question is
> PSC, or anything else.

once again you should read the above as an example (refer 
to gmpls-routing for more combinations - i refer you to the
section 4.4.7 of gmpls-routing)

thanks,
- dimitri

Charles Chen wrote:
> 
> Hi Dimitri,
> 
> See inline,
> 
> > > The second issue is how the core node identifies whether the
> > > TE link configured, or discovered via LMP, is attached to
> > an edge node. In
> > > other words, does this need any support from LMP?
> >
> > since lmp allows the exchange of switching capability supported
> > at the end-points (see lmp sect. 13.12.1.1), the use of method
> > (described also in gmpls-routing) would deliver you links such
> > that [PSC, LSC] refers to a link between a packet LSR and an OXC,
> > we would then assume that this te link inter-connects an edge
> > with a core node
> >
> 
> Whether a TE link is able to support more than one switching capability or
> not has no relation to whether a node attached to it is a core
> node or edge node. A core node which supports both LSR and OXC on a TE link
> could
> advertise it as both PSC and TDM. In addition, for any given LSP, all TE
> links
> associated with the LSP must have the same switching capability. The
> switching
> capability is designed to faciliate the CSPF path selection for a given LSP
> type (TDM, LSR, OXC, etc).
> 
> Take one example, if an edge device attached to the TDM core network
> supports two
> types of client signals (TDM/SONET and Ethernet over SONET via X.86 or GFP)
> for a "TDM"
> LSP request, then I think the TE link attached to the edge device should
> advertise
> the switching capability of the TE link as TDM, and then use the g-pid to
> represent the client
> signal for a LSP request. It will be incorrect to say that the TE link in
> question is
> PSC, or anything else.
> 
> Charles
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]
> > Sent: Wednesday, January 15, 2003 1:19 PM
> > To: Charles Chen
> > Cc: [email-masked]'
> > Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt
> >
> >
> > hi charles,
> >
> > see in-line
> >
> > Charles Chen wrote:
> > >
> > > Is there any similar proposal of GMPLS routing support for
> > the overlay
> > > model?
> > > There are a couple of issues that may need to be addressed.
> > One is related
> > > to
> > > how the core node attached to one or more edge node
> > advertises the TE links
> > > between the edge core and the core node. In this case, for
> > example, should
> > > be the Link ID TLV
> > > set to 0.0.0.0 or the same as the Router Address TLV,
> > because there is no
> > > peering router for
> > > the TE link.
> >
> > this would then mean that you would consider such te links
> > as part of the internal core domain instance
> >
> > > The second issue is how the core node identifies whether the
> > > TE link configured, or discovered via LMP, is attached to
> > an edge node. In
> > > other words, does this need any support from LMP?
> >
> > since lmp allows the exchange of switching capability supported
> > at the end-points (see lmp sect. 13.12.1.1), the use of method
> > (described also in gmpls-routing) would deliver you links such
> > that [PSC, LSC] refers to a link between a packet LSR and an OXC,
> > we would then assume that this te link inter-connects an edge
> > with a core node
> >
> > hope this helps,
> > - dimitri.
> >
> > > Charles
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > Sent: Wednesday, January 15, 2003 4:59 AM
> > > > Cc:
> > > > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt
> > > >
> > > >
> > > > A New Internet-Draft is available from the on-line
> > > > Internet-Drafts directories.
> > > > This draft is a work item of the Common Control and
> > > > Measurement Plane Working Group of the IETF.
> > > >
> > > >       Title           : GMPLS RSVP Support for the Overlay Model
> > > >       Author(s)       : G. Swallow et al.
> > > >       Filename        : draft-ietf-ccamp-gmpls-overlay-00.txt
> > > >       Pages           : 10
> > > >       Date            : 2003-1-13
> > > >
> > > > Generalized MPLS defines both routing and signaling
> > protocols for the
> > > > creation of Label Switched Paths (LSPs) in various transport
> > > > technologies.  These protocols can be used to support a number of
> > > > deployment scenarios.  This memo addresses the
> > application of GMPLS
> > > > to the overlay model.
> > > >
> > > > A URL for this Internet-Draft is:
> > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ove
> > > rlay-00.txt
> > >
> > > To remove yourself from the IETF Announcement list, send a
> > message to
> > > ietf-announce-request with the word unsubscribe in the body
> > of the message.
> > >
> > > Internet-Drafts are also available by anonymous FTP. Login
> > with the username
> > > "anonymous" and a password of your e-mail address. After logging in,
> > > type "cd internet-drafts" and then
> > >         "get draft-ietf-ccamp-gmpls-overlay-00.txt".
> > >
> > > A list of Internet-Drafts directories can be found in
> > > http://www.ietf.org/shadow.html
> > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > > Internet-Drafts can also be obtained by e-mail.
> > >
> > > Send a message to:
> > >         [email-masked].
> > > In the body type:
> > >         "FILE
> > /internet-drafts/draft-ietf-ccamp-gmpls-overlay-00.txt".
> > >
> > > NOTE:   The mail server at ietf.org can return the document in
> > >         MIME-encoded form by using the "mpack" utility.  To use this
> > >         feature, insert the command "ENCODING mime" before
> > the "FILE"
> > >         command.  To decode the response(s), you will need
> > "munpack" or
> > >         a MIME-compliant mail reader.  Different
> > MIME-compliant mail readers
> > >         exhibit different behavior, especially when dealing with
> > >         "multipart" MIME messages (i.e. documents which
> > have been split
> > >         up into multiple messages), so check your local
> > documentation on
> > >         how to manipulate these messages.
> > >
> > >
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of the
> > > Internet-Draft.
> >
> > --
> > Papadimitriou Dimitri
> > E-mail : [email-masked]
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : [email-masked]
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> >

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Wed, 15 Jan 2003 13:47:27 -0800
From: Charles Chen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt
Date: Wed, 15 Jan 2003 13:45:42 -0800

Hi Dimitri,

See inline, 

> > The second issue is how the core node identifies whether the
> > TE link configured, or discovered via LMP, is attached to 
> an edge node. In
> > other words, does this need any support from LMP?
> 
> since lmp allows the exchange of switching capability supported
> at the end-points (see lmp sect. 13.12.1.1), the use of method 
> (described also in gmpls-routing) would deliver you links such 
> that [PSC, LSC] refers to a link between a packet LSR and an OXC, 
> we would then assume that this te link inter-connects an edge 
> with a core node
>  

Whether a TE link is able to support more than one switching capability or
not has no relation to whether a node attached to it is a core
node or edge node. A core node which supports both LSR and OXC on a TE link
could 
advertise it as both PSC and TDM. In addition, for any given LSP, all TE
links 
associated with the LSP must have the same switching capability. The
switching
capability is designed to faciliate the CSPF path selection for a given LSP
type (TDM, LSR, OXC, etc). 

Take one example, if an edge device attached to the TDM core network
supports two 
types of client signals (TDM/SONET and Ethernet over SONET via X.86 or GFP)
for a "TDM"
LSP request, then I think the TE link attached to the edge device should
advertise 
the switching capability of the TE link as TDM, and then use the g-pid to
represent the client 
signal for a LSP request. It will be incorrect to say that the TE link in
question is
PSC, or anything else.  

Charles

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, January 15, 2003 1:19 PM
> To: Charles Chen
> Cc: [email-masked]'
> Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt
> 
> 
> hi charles,
> 
> see in-line
> 
> Charles Chen wrote:
> > 
> > Is there any similar proposal of GMPLS routing support for 
> the overlay
> > model?
> > There are a couple of issues that may need to be addressed. 
> One is related
> > to
> > how the core node attached to one or more edge node 
> advertises the TE links
> > between the edge core and the core node. In this case, for 
> example, should
> > be the Link ID TLV
> > set to 0.0.0.0 or the same as the Router Address TLV, 
> because there is no
> > peering router for
> > the TE link.  
> 
> this would then mean that you would consider such te links
> as part of the internal core domain instance
> 
> > The second issue is how the core node identifies whether the
> > TE link configured, or discovered via LMP, is attached to 
> an edge node. In
> > other words, does this need any support from LMP?
> 
> since lmp allows the exchange of switching capability supported
> at the end-points (see lmp sect. 13.12.1.1), the use of method 
> (described also in gmpls-routing) would deliver you links such 
> that [PSC, LSC] refers to a link between a packet LSR and an OXC, 
> we would then assume that this te link inter-connects an edge 
> with a core node
>  
> hope this helps,
> - dimitri.
> 
> > Charles
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Wednesday, January 15, 2003 4:59 AM
> > > Cc:
> > > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt
> > >
> > >
> > > A New Internet-Draft is available from the on-line
> > > Internet-Drafts directories.
> > > This draft is a work item of the Common Control and
> > > Measurement Plane Working Group of the IETF.
> > >
> > >       Title           : GMPLS RSVP Support for the Overlay Model
> > >       Author(s)       : G. Swallow et al.
> > >       Filename        : draft-ietf-ccamp-gmpls-overlay-00.txt
> > >       Pages           : 10
> > >       Date            : 2003-1-13
> > >
> > > Generalized MPLS defines both routing and signaling 
> protocols for the
> > > creation of Label Switched Paths (LSPs) in various transport
> > > technologies.  These protocols can be used to support a number of
> > > deployment scenarios.  This memo addresses the 
> application of GMPLS
> > > to the overlay model.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ove
> > rlay-00.txt
> > 
> > To remove yourself from the IETF Announcement list, send a 
> message to
> > ietf-announce-request with the word unsubscribe in the body 
> of the message.
> > 
> > Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> >         "get draft-ietf-ccamp-gmpls-overlay-00.txt".
> > 
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> >         [email-masked].
> > In the body type:
> >         "FILE 
> /internet-drafts/draft-ietf-ccamp-gmpls-overlay-00.txt".
> > 
> > NOTE:   The mail server at ietf.org can return the document in
> >         MIME-encoded form by using the "mpack" utility.  To use this
> >         feature, insert the command "ENCODING mime" before 
> the "FILE"
> >         command.  To decode the response(s), you will need 
> "munpack" or
> >         a MIME-compliant mail reader.  Different 
> MIME-compliant mail readers
> >         exhibit different behavior, especially when dealing with
> >         "multipart" MIME messages (i.e. documents which 
> have been split
> >         up into multiple messages), so check your local 
> documentation on
> >         how to manipulate these messages.
> > 
> > 
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> 
> -- 
> Papadimitriou Dimitri 
> E-mail : [email-masked] 
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> 

Delivery-date: Wed, 15 Jan 2003 13:21:38 -0800
Date: Wed, 15 Jan 2003 22:19:26 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: Charles Chen <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt

hi charles,

see in-line

Charles Chen wrote:
> 
> Is there any similar proposal of GMPLS routing support for the overlay
> model?
> There are a couple of issues that may need to be addressed. One is related
> to
> how the core node attached to one or more edge node advertises the TE links
> between the edge core and the core node. In this case, for example, should
> be the Link ID TLV
> set to 0.0.0.0 or the same as the Router Address TLV, because there is no
> peering router for
> the TE link.  

this would then mean that you would consider such te links
as part of the internal core domain instance

> The second issue is how the core node identifies whether the
> TE link configured, or discovered via LMP, is attached to an edge node. In
> other words, does this need any support from LMP?

since lmp allows the exchange of switching capability supported
at the end-points (see lmp sect. 13.12.1.1), the use of method 
(described also in gmpls-routing) would deliver you links such 
that [PSC, LSC] refers to a link between a packet LSR and an OXC, 
we would then assume that this te link inter-connects an edge 
with a core node
 
hope this helps,
- dimitri.

> Charles
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Wednesday, January 15, 2003 4:59 AM
> > Cc:
> > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt
> >
> >
> > A New Internet-Draft is available from the on-line
> > Internet-Drafts directories.
> > This draft is a work item of the Common Control and
> > Measurement Plane Working Group of the IETF.
> >
> >       Title           : GMPLS RSVP Support for the Overlay Model
> >       Author(s)       : G. Swallow et al.
> >       Filename        : draft-ietf-ccamp-gmpls-overlay-00.txt
> >       Pages           : 10
> >       Date            : 2003-1-13
> >
> > Generalized MPLS defines both routing and signaling protocols for the
> > creation of Label Switched Paths (LSPs) in various transport
> > technologies.  These protocols can be used to support a number of
> > deployment scenarios.  This memo addresses the application of GMPLS
> > to the overlay model.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ove
> rlay-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-ietf-ccamp-gmpls-overlay-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Wed, 15 Jan 2003 10:42:42 -0800
From: Charles Chen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt
Date: Wed, 15 Jan 2003 10:40:01 -0800

Is there any similar proposal of GMPLS routing support for the overlay
model?
There are a couple of issues that may need to be addressed. One is related
to
how the core node attached to one or more edge node advertises the TE links 
between the edge core and the core node. In this case, for example, should
be the Link ID TLV
set to 0.0.0.0 or the same as the Router Address TLV, because there is no
peering router for
the TE link.  The second issue is how the core node identifies whether the
TE link configured, or discovered via LMP, is attached to an edge node. In
other words, does this need any support from LMP?

Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, January 15, 2003 4:59 AM
> Cc: 
> Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Common Control and 
> Measurement Plane Working Group of the IETF.
> 
> 	Title		: GMPLS RSVP Support for the Overlay Model
> 	Author(s)	: G. Swallow et al.
> 	Filename	: draft-ietf-ccamp-gmpls-overlay-00.txt
> 	Pages		: 10
> 	Date		: 2003-1-13
> 	
> Generalized MPLS defines both routing and signaling protocols for the
> creation of Label Switched Paths (LSPs) in various transport
> technologies.  These protocols can be used to support a number of
> deployment scenarios.  This memo addresses the application of GMPLS
> to the overlay model.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ove
rlay-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-overlay-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Delivery-date: Wed, 15 Jan 2003 05:05:13 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt
Date: Wed, 15 Jan 2003 07:58:58 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: GMPLS RSVP Support for the Overlay Model
	Author(s)	: G. Swallow et al.
	Filename	: draft-ietf-ccamp-gmpls-overlay-00.txt
	Pages		: 10
	Date		: 2003-1-13
	
Generalized MPLS defines both routing and signaling protocols for the
creation of Label Switched Paths (LSPs) in various transport
technologies.  These protocols can be used to support a number of
deployment scenarios.  This memo addresses the application of GMPLS
to the overlay model.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-overlay-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-overlay-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Tue, 14 Jan 2003 07:20:37 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ccamp-gmpls-overlay-00.txt
Date: Tue, 14 Jan 2003 10:12:21 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: GMPLS RSVP Support for the Overlay Model
	Author(s)	: G. Swallow et al.
	Filename	: draft-ccamp-gmpls-overlay-00.txt
	Pages		: 10
	Date		: 2003-1-13
	
Generalized MPLS defines both routing and signaling protocols for the
creation of Label Switched Paths (LSPs) in various transport
technologies.  These protocols can be used to support a number of
deployment scenarios.  This memo addresses the application of GMPLS
to the overlay model.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ccamp-gmpls-overlay-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ccamp-gmpls-overlay-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ccamp-gmpls-overlay-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ccamp-gmpls-overlay-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ccamp-gmpls-overlay-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Fri, 10 Jan 2003 09:04:59 -0800
Date: Fri, 10 Jan 2003 18:02:14 +0100
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: WG Consensus Call: Protection/restoration work

yes to both

Cheers
Gert Grammel

> Hi All,
>
> Please comment on whether each of the following:
>         draft-bala-gmpls-recovery-functional-01.txt "Generalized MPLS
>                 Recovery Functional Specification"
> and
>         draft-papadimitriou-ccamp-gmpls-recovery-analysis-03.txt
>                 "Analysis of Generalized MPLS-based Recovery Mechanisms"
>
>

Delivery-date: Fri, 10 Jan 2003 06:16:18 -0800
Date: Fri, 10 Jan 2003 15:11:09 +0100
From: [email-masked]
Reply-To: [email-masked]
Organization: ALCATEL
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: WG Consensus Call: Protection/restoration work

yes

and

yes

> Hi All,
>
> Please comment on whether each of the following:
>         draft-bala-gmpls-recovery-functional-01.txt "Generalized MPLS
>                 Recovery Functional Specification"
> and
>         draft-papadimitriou-ccamp-gmpls-recovery-analysis-03.txt
>                 "Analysis of Generalized MPLS-based Recovery Mechanisms"
>
>

--
--------
 Dominique Verchere       mailto:[email-masked]
 ALCATEL CIT Research & Innovation  URL: http://www.alcatel.com
 Route de Nozay                   tel: +33.1.69.63.4012
 91461 Marcoussis Cedex, France   fax: +33.1.69.63.1865