Re: [mpls] draft-wijnands-mpls-mldp-in-band-signaling - PIM-Bidir
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mpls] draft-wijnands-mpls-mldp-in-band-signaling - PIM-Bidir
Ice,
> Yakov,
>
> > 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)?
>
> 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.
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.
> > Your answer contradicts your own statement you made above, namely,
>
> Correct, I mis interpreted your question. There will be different
> MP2MP LSPs.
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.
> >> 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 ?
>
> Yes, it will by default because this is the Ingress PE/Root of the
> 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.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.