Subject: [bmwg] WGLC Review Comments on draft-ietf-bmwg-mpls-forwarding-meth-01

From: Carlos Pignataro <[email-masked]>
Date: Fri, 26 Dec 2008 15:19:39 -0500

Hi Aamer, Rajiv, BMWG,

Please find some comments on draft-ietf-bmwg-mpls-forwarding-meth-01. I
realize that the WGLC for this I-D has ended on Dec-23, but I hope these
review comments can be considered as part of the BMWG LC for the document.

First, I'd like to weigh-in my 2¢ that this is an important document,
and that should be advanced. I strongly support moving this I-D forward.
It may need another iteration(s), if these or other comments are
considered important; but it's IMHO in the right path to pub request.

I think there are some issues though that might require consideration; I
tried to group the comments into "more substantive" and "more editorial"
buckets. I hope these help.

More Substantive:

~~~~~~

4. Test Methodology

   p = number of ports; determined by the maximum unidirectional
   forwarding throughput of the DUT and the load capacity of the media
   between the Test Ports and DUT.

It's not completely clear to me if "p" refers to number of ports, or
number of {A, B} pair of ports. It appears it is the latter. However,
the distinction between "A"-type and "B"-type ports is not made here. A
and B refers to the "Module Side" according to S4.1.7. Is it that "A" is
an Input and "B" is an Output in regards to the test perspective?

   For example, if the DUT's forwarding throughput is 100 frames per
   second (fps), and the media capacity is 50 fps, then p = 2.

Also, the example part (second para) is assuming an equal output
distribution between the "ports"; is it important how that could be
achieved in MPLS Forwarding (e.g., multiple flows, with multiple LSPs,
single LSP and ECMP, port bundling at the datalink)?

   The number of ports used (p) SHOULD be reported
   for both Tx and Rx sides of DUT. Please see Test Setup in section 6.

Are the "Tx and Rx sides" refering to A and B? And if so, can this be
explicitly mentioned? I think this is clear in the actual test cases,
but not in this generic topo description.

~~~~~~

4.1.2. Label Distribution Support

   This document discourages the use of static label to establish the
   MPLS label switched paths, since it is not commonly used in the
   production networks.

Does this requirement need to be "NOT RECOMMENDED"/"SHOULD NOT", so that
there is a need to explain the reasons if it is used?

~~~~~~

4.1.2. Label Distribution Support

   The most commonly used
   protocols are Label Distribution Protocol (LDP) [RFC5036], Resource
   Reservation Protocol-Traffic Engineering (RSVP-TE) [RFC5151] and
   Border Gateway Protocol (BGP) [RFC3107].

I think the reference for RSVP-TE should be RFC3209.

~~~~~~

4.1.3. Frame Sizes

   Each test SHOULD be run with different (layer 2) frame sizes in
   different trials. The recommended sizes for IPv4 are 64, 128, 256,
   512, 1024, 1280 and 1518.

Why are these IPv4 specific? Should this be "The recommended sizes for
ethernet" (meaning all protocols that have packet formats reasonably
similar to IEEE 802.3)? I think it would help to also explicitly
enumerate the packet formats for POS (Packet over SONET) here. If so:
47, 64, 128, 256, 512, 1024, 1280, 1518, 2048, 4096 octets. A nit: note
that there are no units (octets) above in the recommended frame sizes.

   Frame sizes MUST
   be based on the pre-MPLS shim version of the frame.

This confused me, because: the frame sizes are "Layer 2 frame sizes"
(incl. e.g., ethernet header + FCS), and not the payload of the MPLS
packet. Does the "pre-MPLS shim version of the frame" mean include the
payload of the MPLS packet, the L2 overhead, but exclude MPLS LSEs? If
so, it should state it, because the above can be read as "MPLS payload
only" (as there can be no "pre-MPLS shim version of the frame". But if
so, why that requirement? Can that result in frames of size not
supported by the nderlying technology? Should the requirement start from
the L2 frame size, and start from there to see the encapsulated sizes?

~~~~~~

4.1.5.1. Traffic Verification

   Hence, this
   document requires the test tool to verify the MPLS stack depth. An
   even greater level of verification would be to check if the correct
   label was imposed, but that is out of scope for these tests.

This sounds a bit scary.

A nit, why is this a sub-section sub-ordinate of 4.1.5?

~~~~~~

4.1.6. Address Resolution and Dynamic Protocol State

   If the test or media is making use of a dynamic protocol (eg ARP,
   OSPF, LDP), all state for the protocols should be pre-established

                                           ^^^^^^
Is a SHOULD more appropriate? At least it would require to document why
not, if not followed.
Also, an important one (for POS with PPP) would be to wait for MPLSCP to
be Opened, could it be explicitly added here?

~~~~~~

   4. Test Methodology...............................................3
   4.1. Test Considerations..........................................4

This document, and specifically these Sections, define the methodology
for testing MPLS Forwarding for benchmarking. However, there is no
explicit consideration as to the payload of MPLS Frames. This
meta-comment is one of the key comments RE this document: MPLS can carry
a number of payloads; for example LDP defines a prefix FEC that can be
used with IPv4 & IPv6 prefixes, and two Pseudowire FECs that can be used
with a variety of Layer-2 (and other) protocols, with the additional
degree of the CW. RSVP-TE uses the L3PID with an etype to identify the
protocol carried. Imposition and disposition of IP vs. L2 payloads can
have different qualities and characteristics, and there are explicit
forwarding behaviors (e.g., ECMP, and ECMP-avoidance techniques) that
depend on the payload (see BCP128 RFC4928, and RFC4385). There
processing of MPLS-encap'd (incl. push and pop operations) IPv4 vs. IPv6
can have different optimizations.

In summary, because different payloads can in turn bring different
forwardinf behaviors, I think this document/section needs to be more
explicit as to: i. the type of payload carried over MPLS, and ii. the
LSP distribution (i.e., a single LSP and "p" number of ECMPs, or have 1
LSP per "B-side" port, and one prefix reachable per-port only).

It would be also useful to add another subsection regarding "MPLS Label
Value Considerations", explicitly stating that tests need to use label
values outside the reserved range (i.e., labels >= 16), unless
explicitly stated or unless testing the reserved label. I can send some
text.

~~~~~~

5. Reporting Format

        Internet Protocol               IPv4, IPv6, Dual-Stack

To which topology aspect is this referring to? The protocol over which
the label distribution is done? The Address Family of the FECs? Overall?

        MPLS Forwarding Operation       Imposition, Swap,
                                        Disposition

Does this implicitly prevent combination of operations (e.g., swap + push)

        Number of A and B               1A, 2B
        interfaces (see Figure 1)

Figure 1 shows the same number of A and B interfaces ("p").

Also, number and distribution of MPLS LSPs?

~~~~~~

6. MPLS Forwarding Benchmarking Tests

   MPLS is a different forwarding paradigm from IP. Unlike IP packet
   and IP forwarding, an MPLS packet may contain more than one MPLS
   header and may go through one of three forwarding operations -
   imposition, swap and disposition.

Or combination of operations? E.g., FRR repair point doing swap +
imposition (push), or multiple impositions (pus multiple headers) in
VPNv4, PW, etc.

     6. MPLS EXP field Operations (including explicit-null cases)
        ^^^^^^^^

"Traffic Class", per draft-ietf-mpls-cosfield-def-08 :-)

~~~~~~

6. MPLS Forwarding Benchmarking Tests

   Test Setup

     Referring to Figure 1, a single A and B interface SHOULD be used
     (p = 1 SHOULD be used). However, if the forwarding throughput of
     the DUT is more than that of the media rate of a single interface,
     then additional A and B interfaces MUST be enabled so as to exceed
     the DUT's forwarding throughput. In such case, the tool traffic
     should use IP addresses assigned to BpRN1 and BpAN as the IP
     destinations and conform to section 16 of RFC 2544.

I think I might be getting lost in abbreviations. But: The MPLS case is
different in that there are LSPs set up to the FECs. So does this really
mean that "from each input port there should be an LSP to each output
port, and there should be streams sent from the test equipement to each
of DUT's input ports such (by e.g., destination IP address) that they
are pushed into each LSP, and that the per-input port sequence of these
should be one packet to each LSP that would be sent out of each output
port round-robbin"? Another interpretation of the text above is that
there is a single LSP and the source IP address such be such that the
packets would hash into different ECMP output port. I think it refers to
the former, but should be explicit and in terms of LSPs (and not prefixes).
Also, I could not understand what "BpAN" refers to.

~~~~~~

6.1.1. Throughput for MPLS Label Imposition

     The test tool must
     receive MPLS packets on receive ports Bp (from DUT) with the same
     label values that are advertised.

6.1.2. Throughout for MPLS Label Swap

     The test
     tool must receive MPLS packets on receive ports Bp (from DUT). The
     received MPLS packets must contain the same number of MPLS headers
     as those of transmitted MPLS Packets.

S6.1.1 requires verifying the label value, but S6.1.2 does not (only the
label stack depth). If it's required that the tool be able to check the
label value (cf S6.1.1), shouldn't S6.1.2 require the same?

Also, in all cases described, I think there's no possibility of having
more than one LSE (depth of 1) hitting the DUT.

~~~~~~

6.1.3. Throughout for MPLS Label Disposition

   Test Setup

     In addition to setup described in section 6, the test tool must be
     set up to advertise the IP prefix(es) (using a routing protocol as
     per section 1.1) without any MPLS label on the receive ports Bp,
     and learn the IP prefix(es) with the appropriate MPLS labels on
     the transmit ports Ap.

I think that not advertising any MPLS label from Bp but advertising a
non-reserved label from UUT towards Ap can be treated as an abnormal LSP
termination (broken LSP). This case seems to be what's described in
S3.22 of RFC3031, "Lack of Outgoing Label", to which dropping the packet
is a legitimate action.

Instead, for this test case, I think the test tool should advertise an
Implicit-null label (Label == 3) out of Bp, to create a PHP "pop"
operation at UUT (instead of Unlabeled).

~~~~~~

6.1.4. Throughput for MPLS Label Disposition (Aggregate)

     disposition (i.e. MPLS to IP) using "Aggregate" outgoing label.

   Test Setup

     In addition to setup described in section 6, the DUT should be
     provisioned such that it allocates an aggregate outgoing label to
     a prefix (where the prefix may be a 'BGP aggregated prefix' , 'BGP
     VPN connected prefix' or an IGP aggregation that results in an
     aggregate label, etc. and must include the addresses belonging to
     the DUT receive ports Bp).

Can "IPv4|IPv6 Explicit Null" labels be considered as Aggregate Labels
for the purposes of this test? In either case it should be mentioned
whether allowed or not. Could we also add an (informative) citation to
the different aggregation techniques?

~~~~~~

   6.1. Throughput..................................................11
   6.1.1. Throughput for MPLS Label Imposition......................11
   6.1.2. Throughout for MPLS Label Swap............................12
   6.1.3. Throughout for MPLS Label Disposition.....................13

These different tests implictly prevent the characterization of
hierarchical (e.g., tunneling) MPLS scenarios. One of particular
interest is various cases of FRR, with consecutive "Swap + Push"
operations. Is it worth adding a specific case with combination of
operations, or even better a (likely non-normative) section with
guidelines on how (if possible) to combine different test cases? Or is
this outside the document's scope? I think the document should also
scope (in our out) the use of Exp-null labels. For example, in the
number list in Section 6, the test of reserved labels can be taken as
in- or OO- scope.

~~~~~~

6.5. Reset

This test seems to be considerably different (in objective) as the
corresponging case from RFC 2544. S26.6 of RFC 2544 says:

   This test SHOULD only be run using frames addressed to networks
   directly connected to the DUT so that there is no requirement to
   delay until a routing update is received.

However this is not possible in many (most) of the MPLS test cases
(because of Imp/Disp of LSP, etc), plus the explicit requirement of
Dynamic label distribution protocol. Should this be run with static
labels? Or somehow take into account protocol interactions?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

More (some not totally) Editorial:

~~~~~~

Abstract

   This document describes a methodology specific to the benchmarking
   of MPLS forwarding devices, limited to various types of packet-
   forwarding and delay measurements. It builds upon the tenets set
   forth in RFC2544 [RFC2544], RFC1242 [RFC1242] and other IETF

No citations in the Abstract, per
<http://www.ietf.org/ID-Checklist.html#anchor6> 1.B.

~~~~~~

1. Introduction

   contrast the varying implementations and their strong and weak
   points. This document proposes a methodology using common criteria
   for the comparison of various implementations of basic MPLS
   forwarding devices.

It's comparing only the MPLS forwarding capabilities, that might not be
clear in the above.

~~~~~~

4. Test Methodology

   The set of methodologies described in this document will use the
   topologies described in this section. An effort has been made to

   ^^^^^^^^^^
It seems there's only one topolocy defined.

~~~~~~

4. Test Methodology

   Figure 1 illustrates the sample topology in which the DUT is
   connected to the test ports on the test tool.

                               ^^^^^^^^^^^^^^^^

Could you please add an explicit quick note that there could be test
tool or tools in the topology? The test ports can belong to a single or
multiple test tools, right?

~~~~~~

4.1.1. IGP Support

   It is highly RECOMMENDED that all of the interfaces (A1, DA1, DB1,
   A2..) on DUT and test tool support an IGP such as IS-IS, OSPF,

                                        ^
Can you please add "a dynamic IGP" (to expliclty leave out static routing)?

   plane during heavy forwarding workloads. The route distribution
   method used (OSPF, IS-IS, EIGRP, RIP etc.) MUST be reported.
                                             ^

Please add ", if used, ", since it's not a MUST use.

~~~~~~

4.1.2. Label Distribution Support

   The DUT and test tool must support at least one protocol for
   exchanging MPLS labels.
                   ^^^^^^

Excahnging MPLS "label/FEC bindings" (not "labels" nor "label
bindings"). This comment applies to all this section.

~~~~~~

4.1.2. Label Distribution Support

   All of the interfaces connected to the DUT such as A1, DA1, DB1, A2
   etc., SHOULD support LDP, RSVP-TE, and BGP for IPv4 or IPv6
   Forwarding Equivalence Classes (FECs).

The interfaces "DA1, DB1" are not connected to the DUT, but belong to
the DUT.

Note that hte FECs are not IPv4 or IPv6 for LDP, but rather they are
"Prefix FECs", containing either IPv4 or IPv6 AF.

~~~~~~

4.1.4. Time-to-Live (TTL) or Hop Limit

   If TTL/Hop Limit Decrement is a configurable option on the DUT, the
   setting SHOULD be reported.

Does this mean that the a header's TTL might not get decremented as part
of forwarding? Or is this referring to copy (copy-up, copy-down, ttl
hiding) behavior as per RFC 3443? Could it be explained?

~~~~~~

4.1.5. Trial Duration

   Unless otherwise specified, the test portion of each trial SHOULD be
   no less than 30 seconds when static routing is in place, and no less
   than 200 seconds when a dynamic routing protocol and LDP (default
   LDP holddown timer is 180 seconds) are being used.

There's no requirement to leave the LDP holddown timer with default
value, right? If so, should the duration with dynamic routing/label
distribution be a function of the holddown values?

~~~~~~

4.1.5.1. Traffic Verification

   In addition,
   presence or absence of MPLS header, ethertype (0x8847 vs. 0x0800),
   checksum, frame sequencing and correct MPLS TTL decrementing, MUST

A nit: Does this imply that the benchmarking scopes itself to
downstream-assigned labels only (no 0x8848 for "MPLS with
upstream-assigned label")?
A nit: What does "checksum" refers to (FCS at l2)?

~~~~~~

4.1.7. Abbreviations Used

   Please refer to Figure 1, "Port based Remote Network" for a topology
   view of the network.

Could these abbrevuations be moved *before* (or right after) Figure 1?
Also, the title of Fig 1 is not "Port based Remote Network".

   M  := Module Side (could be A or B)

It's not clear what a "Module" is in this context. Does it mean
"Line-Card" / "Slot" ? It does not appear, as it could take "C" as well
in that case.

   RN := Remote Network (can also be thought of as a network that is
   reachable via Mp).

   Y  := number of network. (i.e. the first network reachable via B1
   would be called B1RN1 and the 5th network would be called B1RN5)

Does this imply that, for each test, a given network (should this be
FEC?) is reachable via only one "B" port (and not more)? I think that
this could use a bit more description, because ultimately what's needed
for the test is the LSP distribution (from the networks, or other FEC).

~~~~~~

6. MPLS Forwarding Benchmarking Tests

   Test Procedure (Refer to section 26 of RFC 2544)

     Send traffic from port(s) Ap towards DUT at a constant load
     towards IP prefixes (BpRN1 addresses) advertised by the tool on
     the receive ports, for a fixed time interval.

Is this really "B1..pRN1" (iterating the B-sub-n ports?
Also, the tool should be advertising FEC-label mappings, where FECs
could be prefixes, etc. I think this should be spelled out, since we are
testing LSP forwarding, and should also specify here that each test
needs to explicitly mention if the test tool is advertising the
mid-point or the tail-end of an MPLS LSP (for imp|exp-null special
cases, and aggregate cases).

~~~~~~

   6.1.1. Throughput for MPLS Label Imposition......................11
   6.1.2. Throughout for MPLS Label Swap............................12
   6.1.3. Throughout for MPLS Label Disposition.....................13
   6.1.4. Throughput for MPLS Label Disposition (Aggregate).........14

If the normative reference for MPLS is RFC3031, should these sections
use nomenclature from S3.15 and S3.20 of RFC 3031 (LSP Ingress, LSP
Egress) in addition to Imposition and Disposition (since imp/disp are
not defined there)

~~~~~~

6.1.1. Throughput for MPLS Label Imposition

   Objective

     To obtain the DUT's Throughput (as per RFC 2544) during label
     imposition (i.e. IP to MPLS).

6.1.3. Throughout for MPLS Label Disposition

   Objective

     To obtain the DUT's Throughput (as per RFC 2544) during label
     disposition (i.e. MPLS to IP) using "Untagged" outgoing label.

6.1.4. Throughput for MPLS Label Disposition (Aggregate)

   Objective

     To obtain the DUT's Throughput (as per RFC 2544) during label
     disposition (i.e. MPLS to IP) using "Aggregate" outgoing label.

These descriptions assume (or presume) that the payload to MPLS is
necessarily IP. I think it should be more explicit, as to IPv4, IPv6,
eiather, both, describes how it deals with ECMP in the test case
(including having a single path and no ECMP allowed), and that non-IP
payloads are outside the scope of the testing.

~~~~~~

6.1.1. Throughput for MPLS Label Imposition

   Test Setup

     In addition to setup described in section 6, the test tool should
     advertise the IP prefix(es) i.e. RNx(using a routing protocol as
     per section 1.1) and associated MPLS label (using a label

Is there a specific prefix diestribution needed/required?

   Discussion

     The DUT's MPLS forwarding table must contain a non-reserved MPLS
     label value as the outgoing label for the learned prefix,

Should this say "in its "FEC-to-NHLFE" (FTN) mapping table" instead of
MPLS Forwarding table (S3.12 of RFC3031)?
Could these "Discussions" also include the desired label stack depth?

   Procedure

     Please see Test Procedure in section 6. Additionally, the test
     tool MUST send unlabeled IP packets on transmit ports Ap (with IP
     destination belonging to above IP prefix(es)), and expect to
     receive MPLS packets on receive ports Bp.

A Nit: These sections assume there is a single test tool doing the
transmit on Ap and receive on Bp, can this be mentioned that is
recommended to follow Fig 1 from S6 of RFC2544?

~~~~~~

6.1.2. Throughout for MPLS Label Swap

   Discussion

     The DUT's MPLS forwarding table must contain non-reserved MPLS

Nit: Can this say "the "Incoming Label Map" (ILM) mapping table", per
S3.11 of RFC3031? Same for S6.1.3 and S6.1.4.

~~~~~~

6.1.2. Throughout for MPLS Label Swap

   Procedure

     Please see Test Procedure in section 6. Additionally, the test
     tool must send MPLS packets on its transmit ports Ap (with IP
     destination belonging to advertised IP prefix(es)), and expect to
     receive MPLS packets on its receive ports Bp.

This procedure should also mention the outgoing label of the MPLS
packets that the test tool sends out of ports Ap (i.e., the same ones
received as advertised from the UUT). Same comment for S6.1.3 and S6.1.4.

~~~~~~

6.1.4. Throughput for MPLS Label Disposition (Aggregate)

   Discussion

     The DUT's MPLS forwarding table must contain an aggregate outgoing
     label

This is an aggregate *incoming* label at the DUT, right?

~~~~~~

6.2. Latency Measurement

   This measures the time taken by the DUT to forward the MPLS packet
   during various MPLS switching paths such as IP-to-MPLS or MPLS-to-
   MPLS or MPLS-to-IP involving one or more MPLS headers.

It appears that none of the cases involve > 1 MPLS headers. The push
cases are done based on an IP FEC (and not e.g., a tunnel).

~~~~~~

6.4. System Recovery

   Test Setup

     Follow the Test Setup guidelines established for each of three
     MPLS forwarding operations in section 6.1.1 (for IP-to-MPLS),
     6.1.2 (for MPLS-to-MPLS) and 6.1.3 (for MPLS-to-IP) and procedure
     one by one.

It seems that S6.1.4 is missing from the para above.

   Procedure

     Please refer to RFC2544 and follow the associated procedure for

Can you please add the Section of RFC2544? (S26.5)

~~~~~~

6.5. Reset

   Test Setup

     Follow the Test Setup guidelines established for each of three
     MPLS forwarding operations in section 6.1.1 (for IP-to-MPLS),
     6.1.2 (for MPLS-to-MPLS) and 6.1.3 (for MPLS-to-IP) and procedure
     one by one.

It seems that S6.1.4 is missing from the para above.

   Procedure

     Please refer to RFC2544 section 26.5. Examples of hardware and
     software resets are:

This should be S26.6 (S26.5 is Overload test)

~~~~~~

Thanks,

-- 
--Carlos Pignataro, DSE, CISCO.
_______________________________________________
bmwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bmwg