The MPLS WG Archive

[Lou Berger <lberger@labn.net>]

At 04:45 PM 4/13/00 -0400, Markus Jork wrote:
>There was a minor change from draft-ietf-mpls-rsvp-lsp-tunnel-04
>to draft-ietf-mpls-rsvp-lsp-tunnel-05. The section about the
>CoS Tspec/Flowspec maximum packet size (M) parameter now says:
>"When the object is contained in Path
>messages, this parameter is updated at each hop with the lesser
>of the received value and the MTU of the outgoing interface."

Marcus,

The old wording was broken.  The current wording is what was 
intended.  This is also the reason no Adspec is need when using the 
Class-of-Service SENDER_TSPEC.  Yes, it is different than Int-Serv 
handling.  It uses a different c-type for a reason, it's not int-serv.  We 
made the choice to use one object rather than two.  We considered it to be 
"simpler".  Clearly you disagree.

[BTW David is incorrect in his mail, M will either carry the smaller of the 
path MTU or the largest packet size that the sender advertises in the first 
SENDER_TSPEC, i.e. is interested in sending.]

>This is clearly the wrong thing to do and unnecessary. It conflicts
>with the traditional rsvp model where the sender_tspec characterizes
>the sender's traffic and the adspec is used to gather information
>along the path. Now requiring that a tspec has to be updated along
>the path with link specific information is not a good idea, especially
>when we don't gain any advantage by doing so. The adspec already
>has the path mtu information and there is no point in collecting
>the same information in the tspec where it doesn't belong.
>And doing this because it is more convenient than parsing
>an intserv adspec is a rather weak argument, too.
>
>Markus

Again, Adspec isn't needed with the Class-of-Service SENDER_TSPEC.  (It is 
optional per RFC2205.)

Lou