Subject: resv_confirm in the resvtear msg and tspec in the patherr msg

From: "Hong Liao" <[email-masked]>
Date: Wed, 14 Nov 2001 16:59:57 -0500

Hi,

Can anyone answer my following two questions?

According to the spec rfc 2205, the resvtear msg has the following format:

1.  ResvTear Message> ::= <Common Header> [<INTEGRITY>]

                                         <SESSION> <RSVP_HOP>

                                         [ <SCOPE> ] <STYLE>

                                         <flow descriptor list>

             <flow descriptor list> ::= (see earlier definition)

Is it possible to have resv_confirm in the resvtear msg, for my understand
for the spec, it should not have resv_confirm in the resvtear msg.  I
observed one vendor's router send out the resvtear msg with resv_confirm.
Is it wrong to put this field in this msg or not?  or it is fine to have
this field in the msg, the neighbor should just ignore this filed or what?

2.  patherror format:

<PathErr message> ::= <Common Header> [ <INTEGRITY> ]

                                      <SESSION> <ERROR_SPEC>

                                      [ <POLICY_DATA> ...]

                                     [ <sender descriptor> ]

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

                                    [ <ADSPEC> ]

As you can see above, the sender descriptor is optional field, but if it is
present, it should have SENDER_TSPEC, is it correct if there is no
<SENDER_TSPEC> in patherr msg?   I observed one vendor's router send out
the patherr msg with <sender descriptor>, but there is only
<SENDER_TEMPLATE>, but no <SENDER_TSPEC>.

Can anyone tell me the scenario above is ok or not?

Thanks,

Julia

---

From: David Charlap <[email-masked]>
Date: Thu, 15 Nov 2001 11:29:10 -0500

Hong Liao wrote:
> Is it possible to have resv_confirm in the resvtear msg, for my
> understand for the spec, it should not have resv_confirm in the
> resvtear msg.  I observed one vendor's router send out the resvtear
> msg with resv_confirm.  Is it wrong to put this field in this msg
> or not?  or it is fine to have this field in the msg, the neighbor
> should just ignore this filed or what?

It's irrelevant to a ResvTear message.

I would just ignore it.

What would you hope to accomplish by rejecting the ResvTear message? 
Keep in mind that the downstream router is not going to be refreshing
this Resv state anymore.  The state will get torn even if you reject the
ResvTear message - it will simply timeout a few minutes later.

> As you can see above, the sender descriptor is optional field, but
> if it is present, it should have SENDER_TSPEC, is it correct if
> there is no <SENDER_TSPEC> in patherr msg?   I observed one
> vendor's router send out the patherr msg with <sender descriptor>,
> but there is only <SENDER_TEMPLATE>, but no <SENDER_TSPEC>.

It is a required object according to the RFC.

IMO, generating PathErr without a TSPEC is a bug.  It is possible that
the content of the TSPEC was the reason for the error, but this
information will get lost if the TSPEC is not sent back with the error.

Have you contacted this vendor to inform them of their bug?  They may
have confused PathErr with PathTear (which is not required to have a
TSPEC).

-- David