[mpls] Tree Re-merge in P2MP MPLS-TE

[Seisho Yasukawa <[e-mail]>]

Hi,

One of the remaining unresolved issues in
draft-ietf-mpls-p2mp-sig-requirement is how to handle
a "re-merge" of the P2MP LSP.

A re-merge is defined as the receipt of more than one
signaling message at one LSR for the same LSP where
the messages are intended to establish the LSP to
different (possibly overlapping) sets of egresses.
The issues that arise concern both control plane state
and data plane traffic.

On the upstream side there are two possibilities.
1. The messages refer to the same upstream data plane interface.
2. The messages refer to different upstream data plane interfaces.

On the downstream side there are also two distinct possibilities.
a. There is no overlap of data flows. That is, each incoming signaling
     message results in outgoing signaling message(s) that do not refer
     to common data plane interfaces.
b. There is some "re-merge" of data flows such that outgoing signaling
     messages caused by the separate incoming messages refer to the
     same outgoing data plane interface.

The issues are clearly:
- a desire to reduce unnecessary control plane state
- a requirement not to duplicate traffic to any egress
- a desire not to duplicate traffic on any link.

The text in the current draft states:


4.11 Tree Remerge

    It is possible for a single transit LSR to receive multiple
    signaling messages for the same P2MP LSP but for different
    sets of destinations. These messages may be received from the
    same or different upstream nodes and may need to be passed on
    to the same or different downstream nodes.

    This situation may arise as the result of the signaling solution
    definition or implementation options within the signaling
    solution. Further, it may happen during make-before-break
    reoptimization (section 4.10), or as a result of signaling
    message fragmentation (section 4.5).

    It is even possible that it is necessary to construct distinct
    upstream branches in order to achieve the correct label choices
    in certain switching technologies managed by GMPLS (for example,
    photonic cross-connects where the selection of a particular
    lambda for the downstream branches is only available on different
    upstream switches).

    The solution MUST handle the case where multiple signaling
    messages for the same P2MP LSP are received at a single transit
    LSR with the end result of all receivers being added to the
    P2MP LSP.

It seems to us that this final paragraph is too loose and propose to
replace it as follows.

    The solution MUST support the case where of multiple signaling
    messages for the same P2MP LSP are received at a single transit
    LSR and refer to the same upstream interface. In this case the
    result of the protocol procedures SHOULD be a single data flow
    on the upstream interface.

    The solution SHOULD support the case where multiple signaling
    messages for the same P2MP LSP are received at a single transit
    LSR and refer to different upstream interfaces, and where each
    signaling message results in the use of different downstream
    interfaces. This case represents data flows that cross at the LSR
    but which do not merge.

    The solution MAY support the case where multiple signaling
    messages for the same P2MP LSP are received at a single transit
    LSR and refer to different upstream interfaces, and where the
    downstream interfaces are shared across the received signaling
    messages. This case represents the merging of data flows. A
    solution that supports this case MUST ensure that data is not
    replicated on the downstream interfaces.

    An alternative to supporting this last case is for the signaling
    protocol to indicate an error such that the merge may be
    resolved by the upstream LSRs.

We would appreciate your input on this point.


Regards,
Seisho. 


_______________________________________________
mpls mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpls