I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-mpls-upstream-label-04.txt
Reviewer: Brian Carpenter
Review Date: 2008-04-23
IETF LC End Date: 2008-04-25
IESG Telechat date: (if known)

Summary: In good shape, but some interop concerns

Comments: 

At the end of section 4.1:

   When two LSRs Ru
   and Rd are adjacent on an LSP for FEC F (with Ru being the upstream
   neighbor and Rd the downstream neighbor), either Ru distributes an
   upstream-assigned label binding for F to Rd, or else Rd distributes a
   downstream-assigned label binding to Ru, but NOT both.  How these
   LSRs will determine which of the two is to be used is outside the
   scope of this document.

I'm a little concerned that this last sentence means that the spec 
doesn't guarantee interoperability - it seems to require a proprietary
extension to resolve it. Shouldn't there at least be a default (most
likely that downstream wins)?

6. Distributing Upstream-Assigned Labels

   Upstream-assigned label bindings MUST NOT be used unless it is known
   that the downstream LSR supports them. How this is known is outside
   the scope of this document.

Similar concern, but in this case it seems clear that the default solution
should be a configuration option.

In section 7:

   There must be a
   mechanism for Ru to inform Rd that a particular tunnel from Ru to Rd
   will be used by Ru for transmitting MPLS packets with upstream-
   assigned MPLS labels. The description of such a mechanism is outside
   the scope of this document. 

Similar concern. This is often dynamic, so it can't be a configuration option.
I don't see how to avoid defining a way to signal this during tunnel setup, 
to guarantee interoperability.

8. Context Label on LANs

   The procedure described below applies to LSRs using IPv4 and does not
   apply to LSRs only using IPv6. A solution for IPv6 LSRs is outside
   the scope of this document.

I trust there is another document coming along for that...

   For a labeled packet with an ether type of 'upstream label
   assignment' the top label is used as the context. The context label
   value is assigned by the upstream LSR and advertised to the
   downstream LSRs.  Mechanisms for advertising the context label are
   outside the scope of this document.

Another interoperability hole.

At the end of section 9:

   This
   implies that <Rd1..Rdn> MUST all be able to support an Upstream
   Neighbor Label Space for Ru and Ru MUST be able to determine this.
   The mechanisms for determining this are specific to the application
   that is using upstream-assigned labels and is outside the scope of
   this document.

Given the range of possible applications of MPLS, is this a reasonable 
burden to place on every single one of them?

Finally - is there anything to be said about the interaction between
this and multicast? (This reviewer knows nothing about multicast over
MPLS.)