Re: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02
Ice,
> Yakov,
>
> >> This prevents receiving a (S,G) from the P2MP LSP and send it down
> >> the
> >> (*,G) PIM tree. This is the behavior we want to support in
> >> combination
> >> with out-of-band source discovery via MSDP. The only thing we want to
> >> restrict is transport (*,G) traffic down the P2MP LSP, that is
> >> covered
> >> by section 2.3.
> >
> > Then the draft should explicitly spell out "the behavior we want
> > to support", *and* the mechanisms/procedures to support such behavior,
> > including the interaction with the out-of-band source discovery via
> > MSDP.
>
> There are no additional mechanisms/procedures to support this
> behavior. This is basic PIM Sparse-mode behavior.
Consider the following example:
Rcv1--R1---LSR1---LSR2---LSR3----R2--RP
\
LSR5--------LSR4---R3--S
DR connected to Rcv1 sends Join(*,G) to R1, which in turn sends it
to LSR1. If indeed we rely just on "basic PIM Sparse-mode behavior"
(as specified in rfc4601), then how would this "basic PIM Sparse-mode
behavior" result in Rcv1 receiving multicast traffic from S (assuming
S sends to G).
Yakov.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.