Subject: RE: Sender TSpec on PathTear

From: Markus Jork <[email-masked]>
Date: Mon, 20 Mar 2000 11:12:58 -0500

Hi Adrian,

On Monday, March 20, 2000 7:32 AM, Adrian Farrel  wrote:
> All,
> 
> RFC 2205 states that Sender TSpec is mandatory on a PathTear
> if a Sender Descriptor is included.
> 
>     <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
>                            <SESSION> <RSVP_HOP>
>                            [ <sender descriptor> ]
> 
>     <sender descriptor> ::= (see earlier definition)
> 
> Where the earlier definition of sender Descriptor is found in
> the definition of Path Message and is...
> 
>     <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
>                             [ <ADSPEC> ]
> 
> 
> draft-ietf-mpls-rsvp-lsp-tunnel-05 does not make any change to 
> this requirement, but does add [RECORD_ROUTE] as an optional
> field in Sender Descriptor.
> 
> It seems to me that SENDER_TSPEC, ADSPEC and RECORD_ROUTE do
> not add anything to PathTear.

Note that you cannot have a RECORD_ROUTE object in a PathTear message.
draft-ietf-mpls-rsvp-lsp-tunnel-05 does say that RECORD_ROUTE
is an optional part of a Sender Descriptor. But it also states that
a RECORD_ROUTE object may only be present in Path or Resv
messages (at the beginning of section 3 in the draft).

> Can anyone comment on whether or not it would be better to 
> define PathTear as
> 
>     <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
>                            <SESSION> <RSVP_HOP>
>                            [<SENDER_TEMPLATE>]
> 

I also don't see a use for the tspec object (or adspec) in a PathTear
message. But it won't do any harm, either. If RFC 2205 ever gets
updated, this is something to keep in mind. But for now we are just
stuck with it, I guess.

And while we are on the topic of message formats: there seems
to be a minor inconsistency between RFC 2205 and
draft-ietf-mpls-rsvp-lsp-tunnel-05.
My interpretation of RFC 2205 is that duplicate objects (e.g. two
SESSION objects) in a single message are to be treated as an error
which in turn means such messages should/could be discarded. This
is not spelled out directly but it's my reading of the spec.
On the other hand, the new objects introduced for MPLS have some
explicit language that says: this object should appear only once,
but if not just look at the first occurence and ignore the others.

Not a big deal but it makes you wonder why to introduce these
subtleties that a parser needs to deal with.

Markus

---

From: Ping Pan <[email-masked]>
Date: Mon, 20 Mar 2000 11:25:34 -0500

Markus Jork wrote:
> > ...

I don't think that tspec is harmful. Actually, tspec may be useful in
case of merged reservations (SE and WF). In some implementation, if the
routers only keep the final merged bandwidth allocation, then they'd
better rely on the tspec in PATHTEAR to update their resources after
teardown.

- Ping