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,

> > 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).
> 
> Section 2.3 in the draft says this is out of scope. We're not using  
> mLDP in-band signaling to pull traffic down a (*,G) tree.

What I showed in my example above is a fairly simple PIM-SM in ASM mode
scenario. Since as you said above, supporting this scenario "is out of
scope", the draft has to say that supporting PIM-SM in ASM mode is "out
of scope".

> If you want to support the example above, LSR1 needs to create (S,G)  
> state for the source. Section 2.1 suggest that MSDP can be used to do  
> that.

If you do not want to state in the draft that supporting PIM-SM in
ASM mode is out of scope, then the draft needs to explicitly spell
out how exactly MSDP will be used in the scenarios like the one I
showed above. Saying that "IP multicast source trees can either be
created via PIM operating in SSM mode [RFC4607] or ASM mode [RFC4601]
(for example via last hop behavior or MSDP [RFC3618])", *as that
is all what section 2.1 said about MSDP*, is not sufficient.

Yakov.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.