[mpls] Next MPLS-TE P2MP Requirements Issue

[Seisho Yasukawa <[e-mail]>]

Hi,

Thank you for your support in the discussion of the first MPLS-TE
P2MP signaling requirements issue and I am sorry for breaking up
the discussion for a while.

I would like to move on to the next open issue which is in section 4.10
of the draft (draft-ietf-mpls-p2mp-sig-requirement-00.txt)

This section discusses re-optimization of P2MP LSP trees.
The main intention is that the ingress LSR is able to perform
any form of re-optimization of all or part of the tree and
that such an operation should be available in a way that has
minimal impact on the service (i.e. negligible traffic hit).

The section concludes with the paragraph...

    The solution SHOULD also provide the ability for the ingress LSR to
    have a strict control on the re-optimization process.
    Such re-optimization MAY be initiated by the sub-tree root branch
    node (that is, the branch node MAY setup a new sub-tree, then splice
    traffic on the new subtree and delete the former sub-tree).

This paragraph is open to some debate.

[Debate 1]
Should a non-ingress LSR (branch & transit) be allowed to notice
that re-optimizataion is possible ?

Our opinion is yes.


[Debate 2]
What should it do when it does notice ?

a. Act autonomously ?
b. Act autonomously, but only if granted permission by the ingress on LSP setup ?
c. Notify the ingress of potential re-optimization and allow the ingress to act ?

Previous discussion said that it was dangerous to allow re-optimization
out of the control of the ingress LSR.

At the least, the ingress should have the ability to grant or deny permission
for autonomous re-optimization.

This can be compared to draft-vasseur-ccamp-loose-path-reopt-02.txt
for P2P TE LSPs, but there may be additional mechanisms available to
facilitate splicing new sub-trees in P2MP MPLS-TE.

There are some immediate concerns about the possibility of
re-convergence (merging) of the data tree as a result of partial
re-optimization outside the control of the ingress LSR.

However, no re-optimization is ever allowed to avoid the explicit path
of the LSP, so the problem is no different from that which exists with
loose hops in the first place.
[A separate discussion on how tree remerge is handled comes later in this 
thread.]

[Debate 3]
Can re-optimization be carried out by any downstream LSR ?

We think the answer is yes.
That is, each downstream LSR may consider itself to be the root of
a sub-tree and may perform whatever re-optimization is required.


This reasoning led us to the original paragraph which we would like to
refine as follows:

    The solution SHOULD also provide the ability for the ingress LSR to
    have a strict control on the re-optimization process. The ingress
    LSR SHOULD be able to limit all re-optimization to be source-
    initiated.

    Where sub-tree re-optimization is allowed by the ingress LSR, such
    re-optimization MAY be initiated by a downstream LSR that is the
    root of the sub-tree that is to be re-optimized. Sub-tree
    re-optimization initiated by a downstream LSR MUST be carried out
    with the same regard to minimizing the hit on active traffic as
    was described above for other re-optimization.

Please contribute your opinions.

Thanks,
Seisho. 


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