The MPLS WG Archive

[Seisho Yasukawa <yasukawa.seisho@lab.ntt.co.jp>]

Hi MPLS Working Group,

As we reported in the last IETF meeting, we have two final issues to resolve in
draft-ietf-mpls-p2mp-sig-requirement.

Below are my suggestions for how to close these issues so that we can take
the draft to working group last call.

Please send your comments to the list.

Thanks,
Seisho.


----
Issue 1. Data duplication.

Section 4.12 describes how data duplication may arise and may be an issue for
receivers. We need to decide exactly how much data duplication we can tolerate.

The current text says...
     Instead, the solution MUST provide a mechanism to resolve, limit or
     avoid data duplication at either or both of:
     - the point at which the data path diverges
     - the point at which the data paths converge.

     THE EXTENT TO WHICH DATA DUPLICATION MAY BE TOLERATED
    (in time or in a count of bits or packets) IS FOR FURTHER STUDY.

We believe that it is not necessary for the requirements draft to quantify the
amount of duplication that is permissible, but that we should give stronger
guidance on the requirements to protect against duplication. At the same time,
we don't want to put constraints on the solution (for example, some solutions
may wish to prevent duplication at the point at which the data path diverges,
some may wish to handle duplication at the point at which the data path
converges, and some may wish to handle duplication when the data is received
at the leaf).

So, we propose to replace the text quoted above with the following...

     Instead, the solution:
     - SHOULD limit to transitory conditions only the cases where
       network bandwidth is wasted by the existence of duplicate
       delivery paths.
     - MUST limit the cases of delivery of duplicate data to an
       application to error cases or rare transitory conditions.

----
Issue 2. Scaling limits.

Section 4.19 sets out the conditions for scaling, and section 4.19.1 attempts
to quantify some limits for scaling. Section 4.19.1 is currently described as
provisional and for further study, so we need to close the discussion.

Number of recipients.

Currently the draft says that...

       ...initial deployments of P2MP TE
       LSPs may be limited to only several hundred recipients, but also
       that future deployments may require significantly larger numbers.

We believe this should be changed to read

       ...initial deployments of P2MP TE
       LSPs will be limited to a maximum of around a hundred recipients,
       but that medium term deployments may increase this to several
       hundred, and that future deployments may require significantly
       larger numbers.

Tree dynamics (rate of graft and prune).

This requirements discussion is hard to hold without looking at possible
applications, but applications have been ruled out of scope for this draft.
Nevertheless, we can usefully consider two cases here.

a. P2MP tunnels are established through management actions (e.g. P2MP
tunnel provisioning) as new leaves are signed up to a service.
In this model the management action is likely to be a gating factor and
join/prune changes will probably be carried out as bulk changes relatively
infrequently.

b. P2MP tunnels are automatically managed as the result of some form
or routing or signaling action that notifies the root about changes to
the leaves. This model will result in individual join/prune operation
occurring more often, but it must be remembered that the P2MP TE
LSP provides an aggregation technique so that (for example)
in the case of a multicast VPN, a leaf represents a participating VPN site,
not an individual receiver. (Note that this is only applied to S-PMSI model.
In case of I-PMSI model, join/prune operations are occurred during
VPN's site addition and deletion process and it is assumed that the
frequency of this operation is not so high). Thus join/prune operations
are likely to be relatively infrequent.

Therefore, no change is proposed to the current text.

Effect of join/prune on transit LSRs and control plane load.
This issue is shown at the end of section 4.19 with the text

     Key considerations SHOULD include:
     - the amount of control plane processing required by the ingress,
       transit and egress LSRs to add/delete a branch LSP to/from an
       existing P2MP LSP.

We believe that this point needs to be expanded to cover the cost of such
a mechanism during join/prune *and* during steady state. That is, the cost
of detecting a join/prune operation must not impose a significant burden on
an LSR when no join/prune is actually taking place.

Therefore, we propose to replace the text above with the following...
     Key considerations SHOULD include:
     - the amount of additional control plane processing required in
       the network to detect whether an add/delete of a new branch is
       required, and in particular, the amount of processing in steady
       state when no add/delete is requested
     - the amount of control plane processing required by the ingress,
       transit and egress LSRs to add/delete a branch LSP to/from an
       existing P2MP LSP.

Further, we propose that the "SHOULD" in this section is changed to "MUST". 


_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls