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

[Yakov Rekhter <yakov at juniper.net>]

Ice,

> > 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" ?
> 
> 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.

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)?

> >> 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
> 
> Yes.

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). 

> > 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) ?
> 
> Yes.

see my previous comment.

> > 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 ?
> 
> 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.

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.