Subject: RE: Applicability Statement: Extensions to RSVP....

From: "John Renwick" <[email-masked]>
Date: Wed, 4 Aug 1999 16:06:52 -0400

Daniel,

> 
> A new draft has been submitted entitled "Applicability 
> Statement for Extensions to RSVP for LSP-Tunnels," 
> by D. Awduche, A. Hannan, and X. Xiao. 
> (draft-awduche-mpls-rsvp-tunnel-applicability-00.txt)
> 

There's a common assumption that routers (LSRs) that intercept and 
process RSVP messages will see either RSVP or RSVP-Tunnel, but not both.  
This is because where LSRs are processing RSVP-Tunnel protocol, RSVP 
coming from outside is tunneled and therefore invisible to them.  If 
it were not so, the LSR would have to use the presence or absence of 
LABEL and LABEL-REQUEST objects to distinguish between the two.

The applicability statement seems to be a good place to spell this out 
and otherwise talk about the relationship and possible coexistence of 
these two protocols.  If you agree, would you be willing to add this?

--
John Renwick                     mailto:[email-masked]
IronBridge Networks              Voice: (612) 825-5229
3009 Holmes Avenue South         FAX:   (707) 897-7928
Minneapolis, MN 55408		   http://www.ibnets.com

---

From: [email-masked] (Daniel Awduche)
Date: Fri, 6 Aug 1999 11:37:13 -0400 (EDT)

John,

Thanks for the comments.

Wouldn't it suffice to simply assert/emphasize the security
requirement that protection should be provided against unauthorized
instantiation of LSPs and normal RSVP sessions.

Regards,
/Dan

---

From: "John Renwick" <[email-masked]>
Date: Fri, 6 Aug 1999 14:09:22 -0400

Dan,
> instantiation of LSPs and normal RSVP sessions.

Security should be addressed, but I was more interested in guiding 
the implementor on how the two forms of RSVP are expected to coexist 
(or not).  Is an implementation of RSVP expected to handle both?  
I believe the answer is no, because everybody expects intserv RSVP 
to be tunneled through LSRs that speak RSVP-Tunnel, rather than to
be seen but ignored by them.  If this is true, it should be explained.

John

---

From: Eric Gray <[email-masked]>
Date: Fri, 06 Aug 1999 14:49:20 -0400

Dan,

> be seen but ignored by them.  If this is true, it should be explained.

I agree with John that this should be made clear somewhere
and the applicability statement is at least as good a place
as any other.

As I understand it, there are several approaches to making
the two protocols work together at edges.  Which ones are
applicable under which circumstances?  What capabilities
are required at devices where the two types of signaling
converge?  Is every implementation of RSVP-TUNNELS required
to support all of these capabilities?

These are questions which - IMHO - have remained unanswered
too long already.

Uhhh, speaking of unanswered questions - any comments on my
comments made earlier?

--

---

From: [email-masked] (Daniel Awduche)
Date: Fri, 6 Aug 1999 20:28:24 -0400 (EDT)

Implementation guidelines would certainly be useful, but don't
you agree that such guidelines belong in a separate document?

Cheers,
/Dan

John Renwick said:
> (or not).  
> Is an implementation of RSVP expected to handle both?

---

From: Alan Hannan <[email-masked]>
Date: Sun, 8 Aug 1999 22:51:04 -0700

> 	Some comments and/or clarification requests
> for the list (editorial comments sent separately):
> 
> o   First Paragraph, section 1.0, age 2 - When you say
>     'all label switch router vendors', are you saying
>     that support of the 'MPLS traffic engineering
>     application' is necessarily a qualifying feature
>     of an 'LSR vendor'?  If so, I think this may be a
>     bit of an overstatement since it seems to me that
>     there might be uses for some LSR capability in a
>     box that would typically not be used in a portion
>     of the network that might benefit from having a 
>     traffic engineering capability.  If this is not 
>     what you intend, then perhaps 'multiple label
>     switch router vendors' is a better choice of
>     words?

  Good clarification.  Of course Traffic Engineering
  and CBR of BW is not required for LSRs.

  How about then if the language is changed from:

...
   found in [2]. There is, therefore, a requirement for an open, non-
   proprietary, standards based signaling and label distribution
   protocol for the MPLS traffic engineering application that will be
   available from all label switching router vendors, allowing such
   devices to interoperate.

  to:

...
   found in [2]. There is, therefore, a requirement for an open, non-
   proprietary, standards based signaling and label distribution
   protocol for the MPLS traffic engineering application that will be
   available from all label switching router vendors supporting traffic
   engineering, allowing such devices to interoperate.

  ?

> o   Second paragraph, could you at least list the
>     reference numbers for the 'several related pro-
>     posals'?  One reason for asking this is that, in
>     the fourth paragraph, you refer to distinctions 
>     between RSVP and RSVP-TUNNELS and include the
>     intended use of RSVP for micro-flows; the RSVP
>     working group is addressing aggregation of RSVP
>     micro-flows as an orthogonal issue, and I was
>     wondering if you're including this work in your
>     reference to 'several related proposals submitted 
>     to the IETF MPLS working group.'  If so, perhaps
>     this should be modified to include other working
>     groups?

  I'd love to see some example text from you.  This would
  help us to do as you suggest.

> o   I'm not really clear on the difference between
>     the two separate distinguishing aspects.  They 
>     both seem to center on the difference between 
>     flows and aggregate flows.  If this is the 
>     distinguishing aspect, then it seems to be a 
>     temporary distinction since the RSVP working 
>     group is working to address this issue more 
>     generally.

  The first focuses on the reservations being made
  by ROUTERS not HOSTS.

  The second focuses on the different type of 
  reservation, which is FEC-ish in nature, so
  much different than the original RSVP intention
  of host-host communication.

  The first difference highlights WHO, the second,
  WHAT.

  While they are somewhat similar, I beleve the 
  illustrative benefit outweighs any confusion
  it creates.

  As the RSVP working group is working on that, 
  we can adapt this as their work comes to 
  fruition.

> o   Section 3.0 - are you saying that RSVP-TUNNELS
>     would be used only for measurement and control
>     traffic?

  No.

  The term "RSVP-TUNNELS" relates to the symbiotic
  nature of the RSVP reservation and the LSP which
  is conjoined with the RSVP BW TE reservation.

  So, the RSVP-TUNNELS is the LSP which has the
  RSVP reservation, and a certain FEC is assigned
  to that RSVP.
  
  The FEC could control traffic [as in, constrain
  the path] or it could be used to just measure the
  traffic.

  Note also, although I do not believe this 
  appropriate for the document, that the RSVP
  bandwidth settings to the LSPs can be used by
  the LSRs to implement various QOS/DS behaviour, 
  in conjunction with other variables such as 
  Label ID, Experimental Bits, etc...

> o   Section 4.0 - I believe this section fails to
>     take into account the evolutionary nature of
>     increasing complexity in deployments.  Instead
>     of starting with a simple topology and adding
>     complexity as the result of careful planning,
>     many actual deployments I've encountered were
>     more like this:
> 
>     o   start with simple deployment,
> 
>     o   plan for gradual addition of new services
> 
>     o   make the amazing discovery that
> 
>         o   service demand turns out NOT to be a
>             predictable smoothly rising curve 
> 
>         o   incentives for buying/selling added
>             services tend toward step-function
>             'output' behavior (no hysteresis -
>             everybody's doing it or nobody is)
> 
>         o   control of the deployment process is
>             insufficient to overcome these issues
>             (best laid plans, etc.)
> 
>     o   scramble into a 'damage control' mode
>         where a great deal of effort and process
>         is inserted to slow down and regain control
>         of the mounting complexity of the deployment
> 
>     AND (occasionally)
> 
>     o   scrap and start over, followed by public
>         embarrassment, reorganization, lay-offs,
>         firings and demotions.

  Thanks for the amusing perspective.  I'm not sure
  we haven't all been through this.

  We went round and round on this.  Xipeng and I wanted
  to put a lot of detail into the deployment explanations,
  sharing a lot of what we've learned.

  However, what we've learned is not necessarily applicable
  for everyone else.
  
  I think that the initial clause:

	"When deploying RSVP-Tunnel..."

  covers us here, because each time one's engineering
  feedback loop causes one to modify the system, one will
  deploy RSVP-Tunnel LSPs.

  So, as it stands, I think it is still valuable, and additional
  information does not lend much more use.

> o   Section 5 - isn't protocol overhead associated
>     with requiring a full RSVP implementation (state
>     information and flow classification capability)
>     not also a concern - particularly in core LSRs
>     which may not need all of the features supported
>     by a full RSVP implementation?

  Yes.  We also neglected to mention tha the router requires
  power.  Also, the LSR may generate heat, which needs to
  be vented somehow.

  Sorry for the sarcasm.  I don't see how this 'protocol
  overhead' should be a problem for a router/LSR/switch
  vendor.

  We [well, not me, but 'they'] chose to use RSVP as a 
  foundation for the TE signalling protocol.  This seems
  to require that one embrace the RSVP protocol.

  I do not agree with you that this is a concern significant
  enough to be noted.  It is self-evident.

> o   Section 6 - Security is not exactly my strength,
>     but should we include the fact that this approach
>     inherits security considerations relating to label
>     switching as well?

  I agree with you that this inherits all security issues of
  the underlying protocols.  I think we cover that by use
  of the word "new", in:

	"This document does not introduce new security issues..."

  -alan

> You wrote:
> > Meanwhile, a copy of the draft is available from:
> > 
> > http://www.awduche.com/papers/papers99/draft-awduche-mpls-rsvp-tunnel-applicability-00.txt
> > 
> > Regards,
> > /Dan
Content-Description: Card for Eric Gray

---

From: Carol Iturralde <[email-masked]>
Date: Mon, 09 Aug 1999 09:25:19 -0400

> > process RSVP messages will see either RSVP or RSVP-Tunnel, but not both.

Why is this assumption being made?

> > LABEL and LABEL-REQUEST objects to distinguish between the two.

RSVP Path messages for LSP tunnels use a different session type.
Just as IPv4 and IPv6 session types can be supported simulatneously,
an LSP tunnel session can be supported by the same router which
supports other session types.

---

From: Eric Gray <[email-masked]>
Date: Mon, 09 Aug 1999 11:53:45 -0400

Alan,

	Thanks for the detailed response.  Please see below.

>    engineering, allowing such devices to interoperate.

This would be okay, though I was thinking more along the
lines of:

   found in [2]. There is, therefore, a requirement for an open, non-
   proprietary, standards based signaling and label distribution
   protocol for the MPLS traffic engineering application that may be
   available from all label switching router vendors, allowing such
   devices to interoperate.

>   help us to do as you suggest.

Actually, I'd be happy to contribute text to clarify this,
but - if I knew what to write - I would not be asking for
clarification.

>   we can adapt this as their work comes to

More than fair enough.  Thanks.

>   Label ID, Experimental Bits, etc...

Let me see if I understand what you're saying.  Are you
saying that - in addition to using RSVP-TUNNEL LSPs to
direct traffic flows - you might also setup one or more
LSPs (presumably along paths that traffic would normally
follow) just to determine how much traffic is following
the paths specified by the RSVP reservation(s)?

If so, I have looked at the specification and I have to
admit that how to do this did not jump right out where I 
could easily see it.

>   information does not lend much more use.

Okay.

>   enough to be noted.  It is self-evident.

I wish.  It would be good if the applicability statement
for RSVP-TUNNELS made so clear a statement as to say that
"RSVP-TUNNELS requires embracing the RSVP protocol".  So
many people seem to think that it only means "embracing"
some subset of RSVP protocol.

I would think that it is the business of an applicability
statement to be clear about such things.

>         "This document does not introduce new security issues..."

Yes and no.  The draft specifically mentions considerations
relating to underlying RSVP.  The draft then makes an oblique 
reference to security considerations that should possibly have
been mentioned in the MPLS architecture, were specifically
addressed in LDP and were not addressed at all in RSVP-TUNNELS.
The security consideration common among all MPLS 'signaling' 
protocols is basically how to avoid processing and accepting
LSP setup attempts from unauthorized sources.

BTW, RSVP-TUNNELS COMPLETELY lacks 'Security Considerations' - I 
wonder that the authors have not been put on notice by the IESG
that the draft is unacceptable as is.  Perhaps they have.

As I see it, RSVP-TUNNELS has split-level security issues; it
seems possible for a non-RSVP-TUNNEL implementation to pass a
RSVP request to a RSVP-TUNNEL implementation as follows:

   Host ----> RSVP-1 ----> RSVP-TUNNEL-2 ----> TE network

Host may be trusted by RSVP-1 for normal RSVP setup but needs
also to be trusted by RSVP-TUNNEL-2 if it is to be allowed to
setup an RSVP-TUNNEL.  But perhaps RSVP-TUNNEL-2 is configured
to trust RSVP-1 and blindly accepts LSP setup attempts from
Host as a result.

Is this possible?  If so, what should be said to the operator
configuring this network about how to prevent misuse of their
services?  If it is not possible, why not?

This is why I do not think it is sufficient to simply say "no
new security issues".  If the security issues were dealt with
in the RSVP-TUNNEL specification, then the applicability draft
should simply point this out.

---

From: Alan Hannan <[email-masked]>
Date: Mon, 9 Aug 1999 09:17:33 -0700

>    available from all label switching router vendors, allowing such

  The difference in semantics doesn't jump out at me; can you help
  me understand it?

> but - if I knew what to write - I would not be asking for

  We'll see what we can do....

> the paths specified by the RSVP reservation(s)?

  Yes.

> admit that how to do this did not jump right out where I 

  Remember that the OPERATIONAL BANDWIDTH and the 
  ADMINISTRATIVE BANDWIDTH do not necessarily have 
  anything to do with each other.

  In a 'native IP' topology with no traffic engineering,
  traffic flows betwen A and Z but is difficult to 
  discretely measuer.

  If one constructs an RSVP-TUNNEL LSP from A to Z with
  an arbitrary bandwidth, say, 10kbps, this LSP would
  then be available for sampling the operational bandwidth.

  There exists an inherent feedback loop between the
  operationally sampled and administratively set bandwidth.

  This is the method by which this occurs.

> > >     by a full RSVP implementation?
....
> statement to be clear about such things.

  I'd like some other opinions on this.  Your point is valid
  but I do not see that the applicability statement needs
  to define the RSVP-TUNNEL spec clearly...  Let's see
  what others say.

> should simply point this out. 

  I'd appreciate some comments from others on this issue as well.

  I'm out for 1 week so Dan and Xipeng will have to pick up...

  -alan

---

From: Eric Gray <[email-masked]>
Date: Mon, 09 Aug 1999 13:00:37 -0400

Alan,

	Maybe this will catch you before you leave?

>   The difference in semantics doesn't jump out at me; can you help

Sure.  

I replaced 'that will be available' with 'that may be available'.

You retained 'will' and inserted the qualification 'supporting
traffic engineering'.  There are other ways to support traffic
engineering, even using LSRs, so I think the qualification you
inserted is insufficient.

>   This is the method by which this occurs.

Thanks for this clarification.

---

From: "John Renwick" <[email-masked]>
Date: Mon, 9 Aug 1999 16:13:46 -0400

No, I don't agree.  I'm looking for a statement about network
architecture as it relates to the two forms of RSVP.  Let's try
to write something that clarifies the usage of these protocols,
then decide where it goes.

There seem to be three possibilities for LSRs:

  1. The network is constructed so that all intserv RSVP messages
     are tunneled through an LSR that processes RSVP-Tunnel messages.
     If the LSR ever sees an RSVP message without a LABEL or a
     LABEL_REQUEST object, it's an error.  Note that VPN support
     leads to this kind of operation: all external IP traffic
     is tunneled so that interior LSRs don't have to be VPN-aware.

  2. A LSR processes both intserv RSVP and RSVP-Tunnel messages.  
     Those that contain LABEL or LABEL_REQUEST objects are treated 
     as MPLS signaling traffic, while those that do not are processed 
     as intserv reservation control messages.

  3. A LSR sees both intserv RSVP and RSVP-Tunnel messages.  It 
     ignores (forwards or silently drops) those that do not contain 
     LABEL or LABEL_REQUEST objects, and processes those that do as 
     MPLS signaling.

A fourth possibility is that all intserv RSVP traffic is dropped at
the edge, but this is really just a flavor of #1 above.

Either the applicability draft or the architecture draft should
enumerate these situations, and if any one is clearly not intended 
by this working group, it should say so.  Where it goes is less 
important than *that* it goes, as long as it's on the standards track.
  
John

---

From: [email-masked] (Daniel Awduche)
Date: Tue, 10 Aug 1999 22:33:16 -0400 (EDT)

John Renwick said:
> No, I don't agree.  

Your comments are well taken. Let's just say that we'll agree to
disagree.  In the meantime, I'll respond to your concerns below, then
sign off.

> I'm looking for a statement about network
> architecture as it relates to the two forms of RSVP.  

Architecturally, the signaling protocol is relevant only to the extent
that it performs some necessary functions within an architectural
framework. In the context of this discussion, the functions of
interest are the establishment and maintenance of parameterized LSPs.

Concerning a "statement about network architecture" you're likely to
get as many such statements as there are entities constructing
networks. Therefore, I suggest you talk to your customers (or
potential customers) to see if they wish to do other things with your
RSVP implementation, besides instantiation of LSPs, and then develop
your code accordingly.

Referring to your comments below, the possibilities suggested are
perhaps configuration options that you should consider providing if
you're developing a general purpose RSVP stack to exploit various
market opportunities.

Lastly, while concuring that a set of guidelines for implementers of
RSVP software is necessary and timely, I disagree, however, that the
applicability statement for RSVP-Tunnel is the appropriate avenue to
postulate such guidelines.

Regards,
/Dan

> Let's try
>   2. A LSR processes both intserv RSVP and RSVP-Tunnel messages. =20
>      Those that contain LABEL or LABEL_REQUEST objects are treated=20
>      as MPLS signaling traffic, while those that do not are processed=20
>   3. A LSR sees both intserv RSVP and RSVP-Tunnel messages.  It=20
>      ignores (forwards or silently drops) those that do not contain=20
>      LABEL or LABEL_REQUEST objects, and processes those that do as=20
>      MPLS signaling.
> 
> enumerate these situations, and if any one is clearly not intended=20
> by this working group, it should say so.  Where it goes is less=20
>  =20
> >=20
> >=20
> >=20
> > >=20
> > > (or not). =20
> > > Is an implementation of RSVP expected to handle both?=20
> > > be seen but ignored by them. =20
> > > If this is true, it should be explained.
> > >=20
> > > John
> > >=20
> > > --
> > >=20
> > >=20
> >=20

---

From: George Swallow <[email-masked]>
Date: Thu, 26 Aug 1999 13:51:07 -0400

Alan -

|> This is why I do not think it is sufficient to simply say "no
|> new security issues".  If the security issues were dealt with
|> in the RSVP-TUNNEL specification, then the applicability draft
|> should simply point this out. 
|
|  I'd appreciate some comments from others on this issue as well.
|
|  I'm out for 1 week so Dan and Xipeng will have to pick up...
|
|  -alan

I think this should be addressed in the RSVP tunnels draft itself.

I'll add some text.  

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: George Swallow <[email-masked]>
Date: Thu, 26 Aug 1999 14:04:03 -0400

Dan -

|Lastly, while concuring that a set of guidelines for implementers of
|RSVP software is necessary and timely, I disagree, however, that the
|applicability statement for RSVP-Tunnel is the appropriate avenue to
|postulate such guidelines.

I would suggest that we add some text to say that this document
concerns the use of RSVP to set up unicast LSP tunnels.  It is noted
that not all of the features of RFC2205 are required in order to
support LSP tunnels.  What other RSVP features are supported by an
implementation which supports LSP tunnels is beyond the scope of this
document.

...George

---

From: [email-masked] (Daniel Awduche)
Date: Fri, 27 Aug 1999 00:57:38 -0400 (EDT)

George,

OK. Here's what I've inserted... 

--

This applicability statement concerns only the use of RSVP to set up
unicast LSP-tunnels.  It is noted that not all of the features
described in RFC2205 are required to support the instantiation and
maintenance of LSP-tunnels. Aspects related to the support of other
features and capabilities of RSVP by an implementation that also
supports LSP-tunnels are beyond the scope of this document. However,
support of such additional features and capabilities should not
introduce new security vulnerabilities in environments that only use
RSVP to set up LSP-tunnels.

Cheers,
/Dan

---

From: [email-masked] (Daniel Awduche)
Date: Fri, 27 Aug 1999 01:33:10 -0400 (EDT)

Eric Gray said:
[ ] 
> I was thinking more along the
> lines of:
> 

OK. I've replaced 'will' with 'may'. 

> > >     this should be modified to include other working

The following are some of the 'related proposals' alluded to in the
referenced paragraph (now all expired):

D. Gan, R. Guerin, S. Kamat, T. Li, E. Rosen "Setting up Reservations
on Explicit Paths using RSVP" draft-guerin-expl-path-rsvp-01.txt

B. Davie, Y. Rekhter, E. Rosen, A. Viswanathan, V.  Srinivasan, S.
Blake, "Use of Label Switching With RSVP" draft-ietf-mpls-rsvp-00.txt

Does the above comments and prior responses by others address all your
concerns?

Cheers,
/Dan