The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

Hong Liao wrote:
> 
> 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?

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.

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

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