The MPLS WG Archive

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

George Swallow wrote:
> 
> This message begins a last call on
> 
>   draft-ietf-mpls-diff-ext-08.txt
> 
> The last call closes March 16, midnite GMT.

I've several problems with it.  I apologize for not mentioning them
until now, but I had not read it until now.



In section 5.3, it says:

	If a DIFFSERV object is not present in the Path message, the
	LSR SHOULD interpret this as a request for an E-LSP using the
	Preconfigured EXP<-->PHB Mapping.

This is bad.  This means that a non-DiffServ message will be interpreted
differently if received by a DS-capable router vs. a non-DS-capable
router.

If the DIFFSERV object is missing, the message should be processed as it
would by a router that has not implemented the diff-ext draft at all.

I realize that there is an "override option", but this looks to me like
a hack.  This override option behavior should be the only behavior,
because it is impossible to signal a non-DS LSP through a DS-capable
router without it.

------------

The second problem involves the use of this draft in conjunction with
the latest changes to RSVP-TE (version -08).  Version -08 eleimates the
COS service type from the TSPEC and FLOWSPEC objects.

The DS draft requires that COS-type objects be used in order to signal
an L-LSP without bandwidth reservations.  With the current revisions of
these two drafts, this type of LSP can not be signalled at all.  It
effectively makes it impossible to use RSVP-TE to signal a best-effort
LSP (either E-LSP or L-LSP)

Either the COS-type TSpec must be put back in RSVP-TE, or the DS draft
must be updated to provide a means for singalling a best-effort LSP.

-------------

A third problem involves the fact that the SENDER_TSPEC is now optional
in a Path message.  This means that routers conforming to this spec will
be generating messages that non-DS-capable routers will be forced to
reject.  The RSVP-TE draft still states that SENDER_TSPEC is a mandatory
object.

There is no mention of whether a FLOWSPEC is optional in Resv messages. 
If the COS C-Type is eliminated, then FLOWSPEC must become optional, if
a best-effort LSP is possible, since presence of an IntServ FLOWSPEC
will indicate a bandwidth reservation.

This will create a similar incompatibility as with the absence of
SENDER_TSPEC in Path messages.

It seems to me that routers implementing this draft will be unable to
interoperate with routers that do not implement it.  IMO, this is
unacceptible.

-- David