Subject: [mpls] working group last call on draft-ietf-mpls-mldp-node-protection

From: Loa Andersson <[email-masked]>
Date: Tue, 17 Jun 2014 11:39:11 +0200

Working Group,

This is to initiate a two week working group last call on
draft-ietf-mpls-mldp-node-protection-01.

Please send your comments to the mpls wg mailing list ([email-masked]).

There are two IPR disclosures against this document. The authors and
the working group members have been asked in a separate mail to state
whether they are aware of other IPRs that relate to this document.

This working group last call ends July 1, 2014.

/Loa
for the MPLS wg chairs

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Loa Andersson <[email-masked]>
Date: Wed, 18 Jun 2014 09:12:10 +0200

Authors,

> This working group last call ends July 1, 2014.

I've a question on the definition of "root node" for mp2mp networks.

I think there are two models

1. the mp2mp network have ingress nodes and egress nodes, an ingress
    node send traffic to all egress nodes, thus acting as a root node
    on a for an p2mp network.

2. the mp2mp network have ingress nodes, egress node and one (active)
    root node. The ingress node send traffic to the root node, which send
    the traffic to all the egress nodes.

Which model is assumed in draft-ietf-mpls-mldp-node-protection?

/Loa

--

---

From: Eric Rosen <[email-masked]>
Date: Wed, 18 Jun 2014 10:54:30 -0400

Loa> I've a question on the definition of "root node" for mp2mp networks.

RFC6388 defines "root node" for an MP2MP LSP.

An MP2MP LSP is a tree, and as a tree it has a root node.  However, the root
node is not necessarily an ingress or egress node; any node can be an
ingress, and any node can be an egress.  Traffic from an ingress node
travels both downstream from the ingress and upstream towards the root.
When the traffic reaches the root, it travels downstream from the root on
all branches other than the one from which the root received the traffic.

Loa> I think there are two models

No, RFC6388 doesn't have two models, and the model it does have is neither
of the two below.

Loa> 1. the mp2mp network have ingress nodes and egress nodes, an ingress
Loa>    node send traffic to all egress nodes, thus acting as a root node on
Loa>    a for an p2mp network.

This description confuses the "root node" (the only node in the tree that is
not a child of any other node) with an "ingress node" (a node that puts
traffic onto the tree.)  In a P2MP LSP, the only ingress point to the tree
is the root node, but that's not true in MP2MP LSPs.

Loa> 2. the mp2mp network have ingress nodes, egress node and one (active)
Loa>    root node. The ingress node send traffic to the root node, which
Loa>    send the traffic to all the egress nodes.

If I understand correctly, this model requires the ingress to unicast to the
root, and then requires the root to multicast down a P2MP tree.  In general,
this model does not work for MPLS.  In this model, if a given node is both a
sender and a receiver, it will receive its own traffic back, with no way to
detect that it has already seen the traffic.  This will result in traffic
duplication.

Loa> Which model is assumed in draft-ietf-mpls-mldp-node-protection?

The RFC6388 MP2MP LSP model.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 19 Jun 2014 10:11:42 +0200

Eric,

tnx - I think I get this, the question I have now I try to capture in
the figures below.

Assume a mp2mp tree like this.

                              A
                             / \
                            /   \
                           B     C
                          /|     |\
                         / |     | \
                        D  E     F  G
                       /|  |     |  |\
                      / |  |     |  | \
                     H  I  J     K  L  M

Assume the for a particular packet "G" is the ingress, G will replicate
the packet and send it to L and M, and to C.

C will send to it to F to be passed to K, C will also send to A.

A will send it to B and eventually it will reach D, E, H, I and J.

If node A fails, a bypass will be established between, and the tree
will look like this:

                              A

                           B-----C
                          /|     |\
                         / |     | \
                        D  E     F  G
                       /|  |     |  |\
                      / |  |     |  | \
                     H  I  J     K  L  M

One observation is that with respect to the packet using G as ingress,
G is the root.

The only change here is that C does not send the packet to A, but to B,
i.e. with respect to traffic there are no unique functions performed by
the root.

I think this aligns with what you said about mp2mp root protection.

However, if A has a third child.

                              A----------------+
                             / \               |
                            /   \              |
                           B     C             N
                          /|     |\            |\
                         / |     | \           | \
                        D  E     F  G          O  P
                       /|  |     |  |\         |  |\
                      / |  |     |  | \        |  | \
                     H  I  J     K  L  M       Q  R  S

Why isn't it enough that C (or B) establishes the bypass to N,
like this:

                              A

                           B-----C-------------N
                          /|     |\            |\
                         / |     | \           | \
                        D  E     F  G          O  P
                       /|  |     |  |\         |  |\
                      / |  |     |  | \        |  | \
                     H  I  J     K  L  M       Q  R  S

You seem to say that we need this:

                              A
                           +-------------------+
                           |                   |
                           B-----C-------------N
                          /|     |\            |\
                         / |     | \           | \
                        D  E     F  G          O  P
                       /|  |     |  |\         |  |\
                      / |  |     |  | \        |  | \
                     H  I  J     K  L  M       Q  R  S

Why is that?

/Loa

PS

Sometimes I think there is an easy answer, but it keeps escaping me :(

/Loa

--

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Thu, 19 Jun 2014 21:12:19 +0000

Hi Loa,

Per my understanding, it may result in disconnected tree incase of ROOT
failure. Assume there is one more downstream leg from A as N1-N2-N3

So there are 4 MPTs now (B, C, N and N1) to protect ROOT A. If the
intention is to choose any one as PLR and establish the backup LSP, due to
any local matter it may result in below:

1. B chooses C as PLR.
2. C chooses B as PLR.
3. N chooses N1 as PLR.
4. N1 chooses N as PLR.

Now, the tree will be disconnected during ROOT failure and any traffic
flowing from H will not reach N or N1 and downstream and traffic from S
will not reach B or C.

Thanks,
Nagendra

On 6/19/14, 4:11 AM, "Loa Andersson" <[email-masked]> wrote:

>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Loa Andersson <[email-masked]>
Date: Fri, 20 Jun 2014 05:12:57 +0200

Nagendra,

Yes you are right! Took me some time to go over the cases.

Further comments:

1. Figure 2 does not really explain your point.

              |
            (LSR1)
           .  |  .
          .   |   .
         .   (N)   . root
         .   /  \  .
          . /    \.
       (LSR2)....(LSR3)
          |        |
                       Figure 2.

    N: The MP2MP root node being protected.
    ...: Backup LSPs between LSR1, LSR2 and LSR3.

The tree will be fully connected by only two of the by-pass LSPs.

Figure 2 would need to look like this:

          |        |
       (LSR1)....(LSR4
         . \     / .
         .  \   /  .
         .   (N)   . root
         .   /  \  .
          . /    \.
       (LSR2)....(LSR3)
          |        |

And I would like to see some text around this also, one sentence under
figure could e.g. be amended like this:

    In order to protect node N, and in order to avoid partitioning of
    the  MP2MP tree, all the LSRs directly connected to N must
    participate in protecting node N by acting both as PLR and MPT
    LSRs. If, as in the case of non-root protection, each LSR just chose
    one PLR, and LSR 1 and LSR2 chose each other, while LSR3 and LSR4
    chose each other the tree will be partioned.

Modulo grammar changes by the authors.

/Loa

--

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 23 Jun 2014 15:00:57 +0200

Hi Loa,

Thanks for the comments/suggestions to the draft.

Besides Nagendra’s point, to backup the Root node, we need a full mesh of P2P LSPs between the nodes connected to the Root. For your figure 2, it means there is a dotted line between LSR3 - LSR1 and LSR4 - LSR2. The reason is to avoid looping. (Its like how a mesh-group works).

Thx,

Ice.