Subject: Re: Optional Adspec objects

From: Bob Braden <[email-masked]>
Date: Fri, 14 Apr 2000 18:53:14 GMT

*> 
  *> A discussion on the MPLS list (which has been resolved) leads me to ask
  *> another question.  Since this question is RSVP-related and not
  *> MPLS-related, I'm posting it here instead of there.
  *> 
  *> in RFC 2205, the BNF lists the Adspec as optional.  However RFC 2210
  *> says that it is required (in section 2.1).
  *> 
  *> I have understood this to mean that an Adspec is optional only for
  *> hosts.  A router receiving a Path without an Adspec must provide the
  *> missing Adspec for the next-hop router.
  *> 
  *> On the other hand, neither RFC states this explicitly.
  *> 
  *> So my question is:  If a router receives a Path without an Adspec, what
  *> should the switch do?  Should it generate Path messages with or without
  *> Adspecs?  And if it should provide them, should it provide information
  *> for any service other than the general/default parameters?
  *> 
  *> -- David
  *> 

I agree that there is a (small) RSVP protocol spec issue here.  The Adspec
was originally made optional before our Int-Serv cousins invented
general path parameters.  The RSVP WG thought that the Adspec would be
omitted for any service that did not require advertising, like
Controlled Load. But you give a protocol designer a sometimes-unused
field, and he (and it was a "he" in this case) will invent new uses for
it.

So we made the Adspec optional, then we forgot about the implications of
general path parameters and the statement in 2210. Maybe it should become
required when 2205 goes to Draft; maybe not. 

On the other hand, the ambiguity really should not matter.
If a Path message is received without an Adspec, the logical thing
would seem to be to forward it without an Adspec  (except the
RSVP daemon in the sender host might supply a default Adspec when
the application does not specify one.)

"Be liberal in what you receive and conservative in what you send".

Does this answer your question?

Bob Braden

---

From: David Charlap <[email-masked]>
Date: Fri, 14 Apr 2000 17:38:59 -0400

> On the other hand, the ambiguity really should not matter.  If a Path
> message is received without an Adspec, the logical thing would seem to
> be to forward it without an Adspec  (except the RSVP daemon in the
> sender host might supply a default Adspec when the application does
> not specify one.)

This is what I needed to know.

To me, it seems equally logical to always provide an Adspec, even when
one os not received.  Of course, if you include GS or CL service blocks
in it, you will be sending possibly-incorrect information about the
sender's requirements.  But I don't think it can hurt if an Adspec with
only default/general characteristics is created.

But not including one is definitely easier.  If it is legal, that is
what I'd rather do.

> "Be liberal in what you receive and conservative in what you send".

Ah, but this depends on what it means to be conservative in what's
sent.  Is it conservative to send an optional object when it is not
required?

-- David