Subject: cos tspec in RSVP-TE

From: Markus Jork <[email-masked]>
Date: Thu, 13 Apr 2000 16:45:48 -0400

There was a minor change from draft-ietf-mpls-rsvp-lsp-tunnel-04
to draft-ietf-mpls-rsvp-lsp-tunnel-05. The section about the
CoS Tspec/Flowspec maximum packet size (M) parameter now says:
"When the object is contained in Path
messages, this parameter is updated at each hop with the lesser
of the received value and the MTU of the outgoing interface."

This is clearly the wrong thing to do and unnecessary. It conflicts
with the traditional rsvp model where the sender_tspec characterizes
the sender's traffic and the adspec is used to gather information
along the path. Now requiring that a tspec has to be updated along
the path with link specific information is not a good idea, especially
when we don't gain any advantage by doing so. The adspec already
has the path mtu information and there is no point in collecting
the same information in the tspec where it doesn't belong.
And doing this because it is more convenient than parsing
an intserv adspec is a rather weak argument, too.

Markus

---

From: David Charlap <[email-masked]>
Date: Thu, 13 Apr 2000 19:15:18 -0400

> an intserv adspec is a rather weak argument, too.

Personally, I agree with you here.  I think the current draft breaks
with the spirit of RSVP.  I think it would be best to simply require the
ADSPEC (as straight RSVP does for router-to-router Path messages).  The
egress node, seeing the CoS TSPEC will then know to ignore all
parameters other than "M".

By making the TSPEC behave as an ADSPEC, you effectively eliminate the
TSPEC.  The egress node no longer knows what MTU the ingress node is
requesting.  It only knows the network's capabilities - which may be
greater than the amount required.

I do realize that MTU isn't bandwidth here, but I think the egress node
should get both the requested value as well as the ADSPEC value.  On
some routers, resources may be wasted if an MTU greater than required is
signalled.

I would also add as a side comment that there doesn't seem to be any
purpose to signalling the MTU in the CoS FLOWSPEC if the sender's
requirements are not propagated all the way the recipient.  If you only
want to signal "whatever the network's capable of", you can do that
without specifying anything.

-- David

---

From: Lou Berger <[email-masked]>
Date: Thu, 13 Apr 2000 20:33:35 -0400

>of the received value and the MTU of the outgoing interface."

Marcus,

The old wording was broken.  The current wording is what was 
intended.  This is also the reason no Adspec is need when using the 
Class-of-Service SENDER_TSPEC.  Yes, it is different than Int-Serv 
handling.  It uses a different c-type for a reason, it's not int-serv.  We 
made the choice to use one object rather than two.  We considered it to be 
"simpler".  Clearly you disagree.

[BTW David is incorrect in his mail, M will either carry the smaller of the 
path MTU or the largest packet size that the sender advertises in the first 
SENDER_TSPEC, i.e. is interested in sending.]

>an intserv adspec is a rather weak argument, too.

Again, Adspec isn't needed with the Class-of-Service SENDER_TSPEC.  (It is 
optional per RFC2205.)

Lou

---

From: David Charlap <[email-masked]>
Date: Thu, 13 Apr 2000 20:56:47 -0400

Lou Berger wrote:
> 
> Again, Adspec isn't needed with the Class-of-Service SENDER_TSPEC.
> (It is optional per RFC2205.)

Is it?

I thought Adspec was only optional for the ingress node (or source host
in non-MPLS RSVP), and that routers received a Path without an Adspec
were required to provide one to the next hop.

Do you mean that it's legal for a transit router to emit a Path message
without an Adspec object?  (Assuming it received a Path without one, of
course.)

-- David

---

From: Lou Berger <[email-masked]>
Date: Fri, 14 Apr 2000 06:57:14 -0400

>without an Adspec object?  (Assuming it received a Path without one, of

 From rfc2205:

RFC 2205                          RSVP                    September 1997

          The format of a Path message is as follows:

            <Path Message> ::= <Common Header> [ <INTEGRITY> ]

                                      <SESSION> <RSVP_HOP>

                                      <TIME_VALUES>

                                     [ <POLICY_DATA> ... ]

                                     [ <sender descriptor> ]

            <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>

                                     [ <ADSPEC> ]

Obviously, per RFC2210, ADSPEC is needed for int-serv.

Lou