Subject: [mpls] applicability of draft-wijnands-mpls-mldp-in-band-signaling-02

From: Yakov Rekhter <[email-masked]>
Date: Fri, 6 Nov 2009 04:33:18 -0800

Folks,

At the last IETF I asked the authors to explicitly spell out the
applicability of this draft to various "flavors" of PIM.  
 
The latest version of the draft (-02) still does not address this.
To address this I propose to insert the following in the Introduction
section of the draft:
 
    The procedures specified in this draft are sufficient to support
    IP multicast with PIM-SM in SSM mode. The procedures specified
    in this draft are insufficient to support IP multicast with
    PIM-SM in ASM mode for the reason mentioned in section 2.3 of
    this draft. The procedures specified in this draft do not support
    IP multicast with PIM-DM.

Yakov.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Sun, 8 Nov 2009 02:30:46 +0100

Yakov,

>    IP multicast with PIM-SM in SSM mode. The procedures specified

That is too restrictive.

>    PIM-SM in ASM mode for the reason mentioned in section 2.3 of

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.

>    IP multicast with PIM-DM.

This is fine, I can add that.

Thx,

Ice.

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 8 Nov 2009 06:31:43 -0800

Ice,

> restrict is transport (*,G) traffic down the P2MP LSP, that is covered  

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.

Yakov.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 9 Nov 2009 12:38:48 +0900

Yakov,

> including the interaction with the out-of-band source discovery via  

There are no additional mechanisms/procedures to support this  
behavior. This is basic PIM Sparse-mode behavior.

Maybe this goes back to my comment on the other email, that PIM  
messages are not translated into mLDP messages. The multicast routing  
state is used to drive the creating of the mLDP LSPs.

Thx,

Ice.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 9 Nov 2009 06:08:57 -0800

Ice,

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

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 10 Nov 2009 05:15:08 +0900

Yakov,

> behavior" result in Rcv1 receiving multicast traffic from S (assuming

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.

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.

Thx,

Ice.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 9 Nov 2009 13:13:31 -0800

Ice,

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

> state for the source. Section 2.1 suggest that MSDP can be used to do  

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.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 10 Nov 2009 15:06:40 +0900

Yakov,

> is all what section 2.1 said about MSDP*, is not sufficient.

I thought that how MSDP would be used is fairly obvious. But I can  
enhance the section.

Thx,

Ice.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 12 Nov 2009 12:23:25 -0500

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

That doesn't follow.  Supporting PIM-SM in ASM mode does require that there
be a way to discover the active sources, but joining a shared tree is not
the only way to do that.

It is fair to ask the draft to say something like the following:

      "When PIM-SM is used in ASM mode, the usual means of discovering
      active sources is to join a sparse mode shared tree.  However, this
      document does not provide any method of transporting a sparse mode
      shared tree across an MPLS network.  To apply the technique of this
      document to PIM-SM in ASM mode, there must be some other means of
      discovering the active sources.  One possible means is the use of
      MSDP, but specification of such means is outside the scope of this
      document".

Yakov> the draft needs to explicitly spell out how exactly MSDP will be used
Yakov> in the scenarios like the one I showed above.

Well, then it wouldn't be out of scope, would it?

The notion of discovering the active sources without using a shared tree
isn't exactly new; see, e.g., section 14 of draft-ietf-l3vpn-2547bis-mcast-
bgp.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 16 Nov 2009 07:51:47 -0800

Eric,

> be a way to discover the active sources, but joining a shared tree is not

Let's be a bit more precise... 

PIM-SM is specified in rfc4601. Support for the ASM service model
with PIM-SM, as defined in rfc4601, *does require a shared tree* to
discover the active sources.

There are other ways to discovery the active sources in the ASM
service model, but they are outside the scope of rfc4601, and thus
are outside the scope of PIM-SM.

>       active sources is to join a sparse mode shared tree.  

When PIM-SM is used to support the ASM service model joining a sparse
mode shared tree is not "the usual means", but *the required* mean.

>                                                            However, this
>       shared tree across an MPLS network.  

That is certainly correct.

>                                           To apply the technique of this
>       discovering the active sources.  

Either that, or a method of transporting a sparse mode shared tree across
an MPLS network.

>                                       One possible means is the use of

Not only "specification of such means is outside the scope of this
document", but also the interaction of such means with the MPLS
network is outside the scope of this document.

Wrt MSDP as "one possible means" please note that the MSDP spec
(rfc3618) specifies just two possible deployment scenarios: (1)
between PIM domains, and (2) between Anycast-RPs. If one proposes
to use MSDP to support the ASM service model over an MPLS network,
then one has to spell out how these two deployment scenarios apply
in this context.

With the above comments in mind, I'd like to propose to add the following
to the draft:

     Supporting the ASM service model with PIM-SM [RFC4601] requires
     a sparse mode shared tree as the way of discovering active
     sources. However, this document does not provide any method
     of transporting a sparse mode shared tree across an MPLS
     network. To apply the technique of this document to the ASM
     service model, there must be either (a) some other means of
     discovering active sources, outside of PIM-SM, or (b) a method
     of transporting a sparse mode shared tree across an MPLS
     network. The specification of such means and their interaction
     with an MPLS network is outside the scope of this document.
     Likewise, the specification of a method of transporting a
     sparse mode shared tree across an MPLS network is outside the
     scope of this document. Thus, supporting the ASM service model
     over an MPLS network is outside the scope of this document.

> isn't exactly new; see, e.g., section 14 of draft-ietf-l3vpn-2547bis-mcast-

That is correct. Please see draft-rekhter-pim-sm-over-mldp-00.txt for 
more details.

Yakov.

---

From: Eric Rosen <[email-masked]>
Date: Tue, 17 Nov 2009 12:41:16 -0500

Eric> Supporting PIM-SM in ASM mode does require that there be a way to
Eric> discover the active sources, but joining a shared tree is not the only
Eric> way to do that.

Yakov> PIM-SM is specified in rfc4601. Support for the ASM service model
Yakov> with PIM-SM, as defined in rfc4601, *does require a shared tree* to
Yakov> discover the active sources.

Please see RFC 4611, which explains how to support the ASM service model
with PIM-SM and MSDP.  In this BCP, active sources are not always discovered
via the shared tree, yet PIM-SM is still used.

You may also wish to look at draft-rekhter-pim-sm-over-mldp-00.txt, which
specifies another way of using PIM-SM in ASM mode without using a shared
tree to discover the active sources.

Yakov>     supporting the ASM service model over an MPLS network is outside
Yakov>     the scope of this document.

I don't really see what's wrong with what I proposed:

We'd be happy to add that another possible means of dicovering the active
sources is specified in draft-rekhter-pim-sm-over-mldp-00.txt.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 17 Nov 2009 11:47:06 -0800

Eric,

> via the shared tree, yet PIM-SM is still used.

To support the ASM service model over an MPLS network the combination
of PIM-SM (rfc4601) and rfc4611 is insufficient, as the deployment
scenarios described in rfc4611 do not cover MPLS network.
  
> tree to discover the active sources.

Thanks for repeating what I said in my previous e-mail:

   Eric> The notion of discovering the active sources without using 
   Eric> a shared tree isn't exactly new; see, e.g., section 14 of 
   Eric> draft-ietf-l3vpn-2547bis-mcast-bgp.

   Yakov> That is correct. Please see draft-rekhter-pim-sm-over-mldp-00.txt 
   Yakov> for more details.

>       MSDP, but specification of such means is outside the scope of this

What's wrong with what you proposed is that it still refuses to
explicitly spell out that supporting the ASM service model over an
MPLS network is outside the scope of this document. In other words,
what is missing in what you proposed is the following sentence:

   Supporting the ASM service model over an MPLS network
   is outside the scope of this document.

> sources is specified in draft-rekhter-pim-sm-over-mldp-00.txt.

That would be fine. 

Yakov.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 18 Nov 2009 15:01:55 +0100

Yakov,

>   is outside the scope of this document.

I already tried to explain to you that this is too restrictive. Only a  
specific part of the ASM model is out of scope, that that is what Eric  
proposed in the text above. Its wrong to claim the whole ASM service  
model is out of scope. One example, in ASM the (S,G) inherits the  
(*,G) O-list. This is typical behavior that is needed in combination  
with MSDP and BGP A-D S-A's.

You're response to this is probably that the draft needs to spell this  
out. However, this is basic PIM ASM behavior that does not belong in  
this draft. All the PIM ASM procedures apply, except what has been  
written above by Eric.

Thx,

Ice.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 19 Nov 2009 12:45:24 -0800

Ice,

> this draft. All the PIM ASM procedures apply, except what has been  

Since as you said above part of the ASM model is out of scope, then
the document should say the following:

   This document specifies support for some, but not all parts 
   of the ASM service model. 

Yakov.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 20 Nov 2009 08:09:46 +0100

Yakov,

>   of the ASM service model.

Yes, that is fine.

Thx,

Ice.