The MPLS WG Archive

[Jeremy Lawrence <jlawrenc@cisco.com>]

At 11:04 07/21/2000 -0400, George Swallow wrote:
>There's now a set of drafts that are ready for publication, save one
>nagging detail.  There are references to the Framework Document which
>remains incomplete.  Given that the Architecture document has captured
>and expanded on the useful ideas in the Framework document, the IESG
>has agreed to proceed as follows.
[...]

This reminds me of a discrepancy between draft-ietf-mpls-arch-06.txt 
and draft-ietf-mpls-framework-05.txt, which becomes more important
if the framework document is to dropped as a reference.

Specifically, there are several inaccuracies in
draft-ietf-mpls-arch-06.txt, in "3.26.3.2. Interoperation: VC Merge,
VP Merge, and Non-Merge", which were corrected in the equivalent
section of the framework document, but not the architecture document.

Correct section 3.26.3.2 text would read as follows (this is from the
framework document, section 4.2.2, with some typos corrected). If
it is too late for these to go into draft-ietf-mpls-arch-06.txt
before it goes to Proposed Standard then that's ok: in that case,
consider this as the first comment to be addressed in the rev up to
Draft Standard. (It's not urgent, as the details of VP merging 
have not been pursued lately.)

------
3.26.3.2. Interoperation: VC Merge, VP Merge, and Non-Merge

    The interoperation of the various forms of merging over ATM is
    most easily described by first describing the interoperation of VC
    merge with non-merge.

    In the case where VC merge and non-merge nodes are interconnected
    the forwarding of cells is based in all cases on a VC (ie, the
    concatenation of the VPI and VCI). For each node, if an upstream
    neighbor is doing VC merge then that upstream neighbor requires
    only a single outgoing VPI/VCI for a particular FEC (this is
    analogous to the requirement for a single label in the case of
    operation over frame media). If the upstream neighbor is not doing
    merge, then it will require a single outgoing VPI/VCI per FEC for
    itself (assuming that it can be an ingress node), plus enough
    outgoing VPI/VCIs to map to incoming VPI/VCIs to pass to its
    upstream neighbors. The number required will be determined by
    allowing the upstream nodes to request additional VPI/VCIs from
    their downstream neighbors.

    A similar method is possible to support nodes which perform VP
    merge. In this case the VP merge node, rather than requesting a
    single VPI/VCI or a number of VPI/VCIs from its downstream
    neighbor, instead may request a single VP (identified by a VPI).
    Furthermore, suppose that a non-VP-merge node is downstream from
    two different VP merge nodes. This node may need to request one
    VPI/VCI (for traffic originating from itself) plus two VPs (one
    for each upstream node).

    An alternative method is possible, which requires no support of VP
    switching and VP labels on nodes which do not support VP merge. In
    this method, the VP merge node does not request VPs from the
    downstream node. It does request a number of VPI/VCIs, one per
    source node in the group of nodes which use VP merge.
    
    In order to support all of VP merge, VC merge, and non-merge, it
    is therefore necessary to allow upstream nodes to request a
    zero or more VC identifiers (consisting of a VPI/VCI). In addition,
    it is useful to allow upstream nodes to request zero or more
    VPs (identified by VPIs). VP merge nodes would therefore request
    one VP, or in the event where this is not supported, the VP merge
    node(s) would request several VCs. VC merge nodes would request
    only a single VPI/VCI per destination (since they can merge all
    upstream traffic into a single VC). Non-VP-merge nodes would pass
    on any requests that they get from above, plus request a VPI/VCI
    for traffic that they originate (if they can be ingress nodes).
    However, non-VP-merge nodes which can only do VC forwarding (and
    not VP forwarding) will need to know which VCIs are used within
    each VP in order to install the correct VCs in its forwarding
    table. This limitation is likely to apply to most on non-ATM LSRs;
    most ATM NICs can terminate VP connections only as numerous
    individual VC connections. A detailed description of how this
    could work can be found in [ATMVP]. Alternatively, the non-VP-merge
    nodes could issue only VC identifiers, as described above.
------

Jeremy Lawrence