Subject: WG Last call

From: George Swallow <[email-masked]>
Date: Fri, 02 Mar 2001 17:26:51 -0500

This message begins a last call on 

  draft-ietf-mpls-diff-ext-08.txt 

The last call closes March 16, midnite GMT.

...George

======================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: David Charlap <[email-masked]>
Date: Fri, 02 Mar 2001 19:00:02 -0500

> 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

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 08 Mar 2001 14:07:16 +0100

>The last call closes March 16, midnite GMT.

Hello,

Below is the list of changes over version 07 to facilitate review.

Please remember that this Last Call is not for the whole specification. 
It is focused on the resolution of the comments from the "special 
Diff-Serv WG Last Call" that was issued on <draft-ietf-mpls-diff-ext-07.txt> 
at the request of the Area Directors.

Cheers

Francois

* L-LSPs EXP<-->PHB mapping
=========================
>We plan to incorporate Jim Murphy's suggestion to modify the EXP value
>corresponding to AFn3 L-LSPs. AFn3 would be mapped to EXP=011 (instead of
>010).
>For memory, the rationale is that implementations which support only two
>drop priorities per AF class could determine the drop priority to be
>applied by looking at a single bit. Same idea was used for the DSCP
>encodings for AF.
>
>The EXP value will be changed accordingly in sections 4.2.1 (in the
>example), 4.2.1.1 (in the mapping table), 4.4.1 (in the example), 4.4.1.1
>(in the mapping table).

done as described above

* Incoming PHB Determination with Pipe Model
===========================================
>We received pretty much the same comment from several people (Service
>Providers as well as vendors) on one detailed aspect of the Pipe model:
>output scheduling at egress of a Pipe LSP. 
>"xx-07.txt" specifies that, in the Pipe model, the egress LSR does incoming
>PHB determination based on the "inner header" (ie after the POP). We plan to:
>	- keep such a behavior, but make it an optional variation of the Pipe model
>	- define an alternative behavior where the egress LSR does incoming PHB
>determination based on the "outer header" (ie before the POP). This will be
>the normal egress behavior for the Pipe Model.
>All the other aspects of the Pipe model are unchanged.
>
>The rationale for using "outer header" by default on egress of Pipe is the
>following:
>	- the typical application of the Pipe model is where a Service Provider
>(SP) transports traffic from a customer who uses a different Diff-Serv
>policy to the SP's Diff-Serv policy. Doing scheduling on LSP Egress based
>on the outer header (and assuming no PHP) allows the Service Provider to
>configure scheduling based on its own Diff-Serv policy. Doing scheduling
>based on the inner header forces the Service Provider to be aware of each
>and every customer Diff-Serv policy and forces the SP to configure
>scheduling differently for each customer Diff-Serv policy. The most common
>situation will be that the SP does not want to be even aware of the
>Customer Diff-Serv policy and thus need to use the outer header. 
>(There will be cases where the SP may accept the operational overhead of
>being aware of the customer's Diff-Serv policy and sell "egress scheduling
>based on customer's policy" as a value add; this is why we keep the use of
>inner header as an option. But this will be less common.)
>	- again, use of inner header means that scheduling is based on customer
>Diff-SErv policy, which can be different for each egress port. For router
>platforms using some form of input queueing, this translates in additional
>sophistication since the input queueing must then be made aware of the
>Diff-Serv policy of every customer connected to an egress port (unless
>input queueing is performed on outer header even if egress scheduling is
>based on inner header, but that means performing classification twice: once
>on input and once on output). While this is implementable, it is
>undesirable to mandate such sophistication/cost as part of the mandatory
>Pipe mode.
>	- use of outer header and use of inner header are both allowed in RFC2983
>(from which the Uniform and Pipe models are inherited).
>
>This will result in corresponding text changes in section 2.6.2. 
>

done as described above: 
text changes in 2.6.2 and addition of section 2.6.2.1

added mention of "Short Pipe" when listing all tunneling modes in last
paragraph
of 2.6.3

added mention of "Short Pipe" when listing all tunneling modes in first
paragraph
of 2.6.4

collapsing of the last paragraphs of 2.6.4 into a single paragraph applicable
to all modes.

* Miscellaneaous
================
Updates of references.
Consistent use of "Label Forwarding" instead of "Label Swapping" in section
2 .
...