Subject: Optional Adspec objects

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

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

---

From: Bob Braden <[email-masked]>
Date: Thu, 27 Apr 2000 20:28:57 -0700 (PDT)

*> 
  *> > 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

I don't think that works.  Then the ADSPEC that arrives at the
receiver purports to provide E-E data ("general characteristics")
on the entire path, but it doesn't.

  *> 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?

It is conservative not to send an optional object when its meaning
is doubtful.

Bob Braden

  *> 
  *> -- David
  *>