Subject: [mpls] draft-wijnands-mpls-mldp-in-band-signaling - PIM-Bidir

From: Yakov Rekhter <[email-masked]>
Date: Fri, 6 Nov 2009 04:38:07 -0800

Folks,

Last IETF at MPLS WG meeting I asked the authors to clarify the
procedures for handling PIM-Bidir sender-only branches with mLDP
in-band signaling. The latest (-02) version of the draft still
does not address this in sufficient level of details.

>From section 1 of that draft:

                                When an IP multicast tree (either a
   source-specific tree or a bidirectional tree) enters the MPLS
   network, the IP multicast control messages used to set up the tree
   are translated into mLDP messages.  

In the case where we have PIM-Bidir sender-only branches (that do not
originate any PIM Join messages) what are "the IP multicast control
messages used to set up the tree", and how do these messages get 
"translated into mLDP messages" ?

>From section 2.2 of that draft:

 2.2.  Transiting IP multicast bidirectional trees

   Bidirectional IP multicast trees [RFC5015] MUST be transported across
   a MPLS network using MP2MP LSPs.  A bidirectional tree does not have
   a specific source address; only the group address and subnet mask are
   relevant for multicast forwarding.  The RP for the group already
   known by IP multicast is used to select the ingress PE and root of
   the LSP.  The group address is encoded in either Section 3.3 or
   Section 3.4, depending on the IP version.  The subnet mask associated
   with the bidirectional group is encoded in the Transit TLV.  There
   are two types of bidirection states in IP multicast, the group
   specific state and the RPA state.  The first type is typlically
   created due to receiving a PIM join and has a subnet mask of 32 for
   IPv4 and 128 for IPv6, the latter is typically created via the RP
   mapping protocol and has a variable subnet mask.  The RPA state is
   used to build a tree to the RP and used for sender only branches.
   Please see [RFC5015] for more details.

The above talks about "the group specific state" and "the RPA state",

Could some of the branches of an MP2MP LSP be associated with just
the RPA state, while other branches of the *same* MP2MP LSP be
associated with the group specific state ? In other words, could
some branches of an MP2MP LSP be signaled using Transit IPv4 Bidir
TLV with mask length less than 32 (the branches associated with the
RPA state), while some other branches of *the same* MP2MP LSP be
signaled using Transit IPv4 Bidir TLV with mask length 32 (the
branches associated with the group specific state) ?

If yes, then what are the procedures at the nodes where the branches
of the MP2MP LSP that are associated with just the RPA state merge
into the part of the *same* MP2MP LSP that is associated with just
the group specific state ? 

Yakov.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Sun, 8 Nov 2009 03:05:51 +0100

Yakov,

> "translated into mLDP messages" ?

In PIM this will result in two different trees, one tree that  
represents the (*,G) for the receivers, the other being the (*,G/M)  
for the senders. The same will be true for mLDP. There will be two  
MP2MP LSPs, one encoding (*,G), the other (*,G/M). The only thing that  
we are doing is translate the PIM state into a mLDP LSP. This is what  
is described in section 2.2.

> associated with the group specific state ? In other words, could

Yes.

> branches associated with the group specific state) ?

Yes.

> the group specific state ?

This is documented in RFC5015 section 3.1.4. Its not mLDP's  
functionality to merge the 2 trees together, this is done in PIM.

Let me know if this addresses your concerns.

I will also update the bidir section to state the RP discovery is via  
static configuration.

Thanks for the comments,

Ice.

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 8 Nov 2009 06:16:11 -0800

Ice,

> is described in section 2.2.

That still does not answer the question I asked above. Namely, what
are "the IP multicast control messages used to set up the tree",
and how do these messages get "translated into mLDP messages" when
we have mp2mp LSP for (*, G/M)?

> > associated with the group specific state ? In other words, could

Your answer contradicts your own statement you made above, namely,

  In PIM this will result in two different trees, one tree that  
  represents the (*,G) for the receivers, the other being the (*,G/M)  
  for the senders. The same will be true for mLDP. There will be two  
  MP2MP LSPs, one encoding (*,G), the other (*,G/M). 

> > branches associated with the group specific state) ?

see my previous comment.

> functionality to merge the 2 trees together, this is done in PIM.

Does that mean that the merge point has to run PIM ?

> Let me know if this addresses your concerns.

No this does not address my concerns - see above.

Yakov.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 9 Nov 2009 12:38:45 +0900

Yakov,

> we have mp2mp LSP for (*, G/M)?

PIM messages are not translated into mLDP messages. I think that is  
the key point of the mis-understanding. You translate multicast  
routing state into mLDP messages. So if the MRIB has (*,G) it encodes  
it into a mLDP FEC, if it has (*,G/M) is does the same. That also  
makes the solution independent of PIM, MSDP or IGMP. Any multicast  
protocol that can populate the MRIB can be used to create a mLDP LSP.

> Your answer contradicts your own statement you made above, namely,

Correct, I mis interpreted your question. There will be different  
MP2MP LSPs.

> Does that mean that the merge point has to run PIM ?

Yes, it will by default because this is the Ingress PE/Root of the  
P2MP LSP that borders with the IP PIM network.

> No this does not address my concerns - see above.

Did we make progress?

Thx,

Ice.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 9 Nov 2009 05:54:05 -0800

Ice,

> protocol that can populate the MRIB can be used to create a mLDP LSP.

That contradicts your draft. Quoting from Abstract:

                                             The IP multicast control
   messages are translated into MPLS control messages when they enter
   the MPLS domain, and are translated back into IP multicast control
   messages at the far end of the MPLS domain.  

> Correct, I mis interpreted your question. There will be different  

Use of mp2mp LSP for the (*,G/M) state would result in traffic 
originated from one source only branch to reach all other source only
branches. This is clearly undesirable. Thus the draft needs to
explain the rationale for using mp2mp LSP for the (*, G/M) state.

> P2MP LSP that borders with the IP PIM network.

Restricting the merge point to the Ingress PE defeats one of the
(main) benefits of PIM-Bidir, namely that as traffic travels from
sources towards the RPA, the traffic is forwarded to the (downstream)
receivers for that traffic. This is because with the mechanisms
proposed in your draft the traffic (from source only branches) has
to reach the Ingress PE before it could get forwarded to the
downstream receivers - the traffic can not get forwarded to the
downstream receivers in the middle of the MPLS network. The draft
should certainly document this.
  
Yakov.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 10 Nov 2009 05:04:46 +0900

Yakov,

>   messages at the far end of the MPLS domain.

I'll change that in the next revision. It basically comes down to the  
same thing. Whether you take the information directly from PIM or via  
the MRIB is an implementation matter, but I can see how the term  
'translation' causes confusion.

> explain the rationale for using mp2mp LSP for the (*, G/M) state.

Good point. I'll clarify this in the draft.

> should certainly document this.

One of the main benefits of PIM bidir is to reduce PIM state. PIM  
bidir forwarding does not guarantee packets are forwarded along the  
shortest path. The sender only traffic will indeed go up to ingress PE  
before it will go down. However, this is not very different from what  
is documented in draft-ietf-mpls-ldp-p2mp-08 section 3 with the  
exception that using a MP2MP LSP you will at least not receive your  
own originated packets back, which is a big advantage. Sites that will  
be a receiver on the bidir tree will not suffer from this. I'll add a  
section in the draft to clarify this.

Thx,

Ice.