Subject: [Gen-art] Gen-ART LC review of draft-ietf-mpls-upstream-label-04.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Apr 2008 08:55:46 +1200

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 28 Apr 2008 10:41:38 -0700 (PDT)

Hi Bert,

Thanks for the comments. Please see below prefixed by <RA>:

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)?

<RA> How about replacing the last sentence above with the following text
to address your concern:

"Whether upstream-assigned or downstream-assigned labels are to be
used for a particular FEC depends on the application using the LSP.
Any application  which requires  the  use of  upstream-assigned
labels MUST specify that explicitly, or else it is to be assumed that
downstream-assigned labels are used. An application on an LSR uses a
label distribution protocol to indicate to its peer LSRs whether a
particular label binding distributed by the LSR uses upstream-assigned
or downstream-assigned label. Details of such procedures are outside the
scope of this document. In some cases, the decision as to
which is used for a particular application may be made by a
configuration option."

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.

<RA> The  application  using  the  LSP  might  require upstream-assigned
labels,  independent of  any configuration.  Hence the current text
seems fine.

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.

<RA> How about replacing the last sentence with:

"Such a mechanism will be provided by the label distribution protocol between
Ru and Rd and will likely require extensions to existing label distribution
protocols. The description of such a mechanism is outside the scope of this
document."

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.

<RA> How about replacing the last sentence with:

"Mechanisms for advertising the context label will be provided by the
label distribution protocol between the upstream and downstream LSRs.
The description of such a mechanism is outside the scope of this
document."

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?

<RA> Applications  are  to  use  MPLS downstream-assigned labels unless
otherwise specified. Hence only those apps which need upstream-assigned
labels are so burdened. I hope this is clear from the new text proposed
above in section 4.1.

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

<RA> This is out of scope.

rahul

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Apr 2008 15:55:28 +1200

Thanks Rahul, fixes along those lines should settle my concerns.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 May 2008 09:37:13 +1200

Hi Rahul, your -05 version looks good to me. Thanks.

Regards
   Brian Carpenter
   University of Auckland