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.