Subject: Suggestion about draft-ietf-l3vpn-2547bis-mcast, Thanks

From: [email-masked]
Date: Mon, 4 Dec 2006 10:21:15 +0800

Hi All
    In the Multicast tunnel setup process, if the tunnel is receiver 
initiated(like mLDP), leaf nodes setup the multicast tunnel failed(maybe 
for some unexpected reasons). I think it is necessary to let the root 
node(maybe also the multicast source node) to know the failure of the leaf 
node.
    So some kind of signaling mechanism should be added to the 
draft-ietf-l3vpn-2547bis-macast-03. If the leaf node fails to setup the 
multicast tunnel, then the root node can do something else, maybe the root 
node should change to another type of tunnel to setup(maybe root node 
initiated tunnel,like RSVP).
    Do you have any opinions about my suggestions. Thank you very much!

Best Regards
Jin Lizhong

..............................................
Add:   No.68 Zijinghua Rd,Yuhuatai District, 
       Nanjing. P.R.China. 
Zip:   210012 
Tel:   0086-25-52871645 
Mail:  [email-masked] 
.............................................. 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Rahul Aggarwal <[email-masked]>
Date: Sun, 3 Dec 2006 21:32:06 -0800 (PST)

Hi Jin,

> initiated tunnel,like RSVP).

If this feature is desired why not start with P2MP RSVP-TE in the first
place ?

>     Do you have any opinions about my suggestions. Thank you very much!

Such a mechanism belongs in the P-tunnel technology domain and not in the
MVPN mechanisms.

rahul

---

From: [email-masked]
Date: Mon, 4 Dec 2006 14:05:41 +0800

Hi Rahul:

Thank you for your reply.

If PEs support multiple kinds of tunnel technology, and various tunnel 
technology has special priority. Maybe the priority is first: mLDP, 
second: PIM-SSM. If the leaf PE node fails to setup the multicast tunnel 
with mLDP, then the root node may need to negotiate another tunnel 
technology.

MVPN should have its own failure processing mechanism. I don't think 
tunnel technology can solve this problem, and some kinds of tunnel 
technology may not care about this.For example, mLDP needs not to let the 
root node to know whether the leaf node sets up P2MP LSP successfully.

Best Regards
Jin Lizhong

Rahul Aggarwal <[email-masked]>
2006-12-04 13:32
 
        To:     [email-masked]
        cc:     [email-masked], [email-masked]
        Subject:        Re: Suggestion about 
draft-ietf-l3vpn-2547bis-mcast, Thanks

Hi Jin,

rahul

> ZTE Information Security Notice: The information contained in this mail 
is solely property of the sender's organization. This mail communication 
is confidential. Recipients named above are obligated to maintain secrecy 
and are not permitted to disclose the contents of this communication to 
others.
> This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error please notify the 
originator of the message. Any views expressed in this message are those 
of the individual sender.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 04 Dec 2006 10:56:42 -0800

Jin,

> root node to know whether the leaf node sets up P2MP LSP successfully.

Since the failure to set up a p2mp LSP with mLDP can also occur
at some intermediate nodes (P routers), and not just the leaf nodes (PE
routers), and since none of the intermediate nodes (P routers) participate 
in MVPN, how could MVPN find such a failure on its own ?

Yakov.

> ZTE Information Security Notice: The information contained in this mail is so
lely property of the sender's organization. This mail communication is confiden
tial. Recipients named above are obligated to maintain secrecy and are not perm
itted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended so
lely for the use of the individual or entity to whom they are addressed. If you
 have received this email in error please notify the originator of the message.
 Any views expressed in this message are those of the individual sender.
> --=_alternative 0021B2EA4825723A_=
> Content-Type: text/html; charset="US-ASCII"
> 
> 
> <br><font size=2>Hi Rahul:</font>
> <br>
> <br><font size=2>Thank you for your reply.</font>
> <br>
> <br><font size=2>If PEs support multiple kinds of tunnel technology, and
> various tunnel technology has special priority. Maybe the priority is first:
> mLDP, second: PIM-SSM. If the leaf PE node fails to setup the multicast
> tunnel with mLDP, then the root node may need to negotiate another tunnel
> technology.</font>
> <br>
> <br><font size=2>MVPN should have its own failure processing mechanism.
> I don't think tunnel technology can solve this problem, and some kinds
> of tunnel technology may not care about this.For example, mLDP needs not
> to let the root node to know whether the leaf node sets up P2MP LSP successfu
lly.</font>
> <br>
> <br>
> <br><font size=2><tt>Best Regards</tt></font>
> <br><font size=2><tt>Jin Lizhong</tt></font>
> <br><font size=2><tt>..............................................<br>
>  Add: &nbsp; No.68 Zijinghua Rd,Yuhuatai District,<br>
>  &nbsp; &nbsp; &nbsp; &nbsp;Nanjing. P.R.China.<br>
>  Zip: &nbsp; 210012<br>
>  Tel: &nbsp; 0086-25-52871645<br>
>  Mail: &nbsp;[email-masked]<br>
> ..............................................</tt></font><font size=2 face="
sans-serif"><br>
> </font>
> <br>
> <br>
> <br>
> <table width=100%>
> <tr valign=top>
> <td>
> <td><font size=1 face="sans-serif"><b>Rahul Aggarwal &lt;[email-masked]&gt
;</b></font>
> <p><font size=1 face="sans-serif">2006-12-04 13:32</font>
> <td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To:
> &nbsp; &nbsp; &nbsp; &nbsp;[email-masked]</font>
> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc:
> &nbsp; &nbsp; &nbsp; &nbsp;[email-masked], [email-masked]</font>
> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject:
> &nbsp; &nbsp; &nbsp; &nbsp;Re: Suggestion about draft-ietf-l3vpn-2547bis-mcas
t,
> Thanks</font></table>
> <br>
> <br>
> <br><font size=2><tt><br>
> Hi Jin,<br>
> <br>
> On Mon, 4 Dec 2006 [email-masked] wrote:<br>
> <br>
> &gt; Hi All<br>
> &gt; &nbsp; &nbsp; In the Multicast tunnel setup process, if the tunnel
> is receiver<br>
> &gt; initiated(like mLDP), leaf nodes setup the multicast tunnel failed(maybe
<br>
> &gt; for some unexpected reasons). I think it is necessary to let the root<br
>
> &gt; node(maybe also the multicast source node) to know the failure of
> the leaf<br>
> &gt; node.<br>
> &gt; &nbsp; &nbsp; So some kind of signaling mechanism should be added
> to the<br>
> &gt; draft-ietf-l3vpn-2547bis-macast-03. If the leaf node fails to setup
> the<br>
> &gt; multicast tunnel, then the root node can do something else, maybe
> the root<br>
> &gt; node should change to another type of tunnel to setup(maybe root node<br
>
> &gt; initiated tunnel,like RSVP).<br>
> <br>
> If this feature is desired why not start with P2MP RSVP-TE in the first<br>
> place ?<br>
> <br>
> &gt; &nbsp; &nbsp; Do you have any opinions about my suggestions. Thank
> you very much!<br>
> &gt;<br>
> <br>
> Such a mechanism belongs in the P-tunnel technology domain and not in the<br>
> MVPN mechanisms.<br>
> <br>
> rahul<br>
> <br>
> &gt;<br>
> &gt; Best Regards<br>
> &gt; Jin Lizhong<br>
> &gt;<br>
> &gt; ..............................................<br>
> &gt; Add: &nbsp; No.68 Zijinghua Rd,Yuhuatai District,<br>
> &gt; &nbsp; &nbsp; &nbsp; &nbsp;Nanjing. P.R.China.<br>
> &gt; Zip: &nbsp; 210012<br>
> &gt; Tel: &nbsp; 0086-25-52871645<br>
> &gt; Mail: &nbsp;[email-masked]<br>
> &gt; ..............................................<br>
> &gt;<br>
> &gt; --------------------------------------------------------<br>
> &gt; ZTE Information Security Notice: The information contained in this
> mail is solely property of the sender's organization. This mail communication
> others.<br>
> &gt; This email and any files transmitted with it are confidential and
> addressed. If you have received this email in error please notify the origina
tor
> of the message. Any views expressed in this message are those of the individu
al
> sender.<br>
> &gt; This message has been scanned for viruses and Spam by ZTE Anti-Spam
> system.<br>
> &gt;<br>
> <br>
> <br>
> --------------------------------------------------------<br>
> others.<br>
> the message. Any views expressed in this message are those of the individual
> sender.<br>
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.<b
r>
> </tt></font>
> <br><br><pre>
> ZTE&nbsp;Information&nbsp;Security&nbsp;Notice:&nbsp;The&nbsp;information&nbs
p;contained&nbsp;in&nbsp;this&nbsp;mail&nbsp;is&nbsp;solely&nbsp;property&nbsp;
of&nbsp;the&nbsp;sender's&nbsp;organization.&nbsp;This&nbsp;mail&nbsp;communica
tion&nbsp;is&nbsp;confidential.&nbsp;Recipients&nbsp;named&nbsp;above&nbsp;are&
nbsp;obligated&nbsp;to&nbsp;maintain&nbsp;secrecy&nbsp;and&nbsp;are&nbsp;not&nb
sp;permitted&nbsp;to&nbsp;disclose&nbsp;the&nbsp;contents&nbsp;of&nbsp;this&nbs
p;communication&nbsp;to&nbsp;others.
> This&nbsp;email&nbsp;and&nbsp;any&nbsp;files&nbsp;transmitted&nbsp;with&nbsp;
it&nbsp;are&nbsp;confidential&nbsp;and&nbsp;intended&nbsp;solely&nbsp;for&nbsp;
the&nbsp;use&nbsp;of&nbsp;the&nbsp;individual&nbsp;or&nbsp;entity&nbsp;to&nbsp;
whom&nbsp;they&nbsp;are&nbsp;addressed.&nbsp;If&nbsp;you&nbsp;have&nbsp;receive
d&nbsp;this&nbsp;email&nbsp;in&nbsp;error&nbsp;please&nbsp;notify&nbsp;the&nbsp
;originator&nbsp;of&nbsp;the&nbsp;message.&nbsp;Any&nbsp;views&nbsp;expressed&n
bsp;in&nbsp;this&nbsp;message&nbsp;are&nbsp;those&nbsp;of&nbsp;the&nbsp;individ
ual&nbsp;sender.
> This&nbsp;message&nbsp;has&nbsp;been&nbsp;scanned&nbsp;for&nbsp;viruses&nbsp;
and&nbsp;Spam&nbsp;by&nbsp;ZTE&nbsp;Anti-Spam&nbsp;system.
> </pre>
> --=_alternative 0021B2EA4825723A_=--

---

From: [email-masked]
Date: Tue, 5 Dec 2006 11:56:29 +0800

Dear Yakov:
 
Thanks for your opinion. 

When setting up a p2mp LSP with mLDP, the intermediate nodes (P routers) 
may not know the failure of the leaf nodes (PE
routers), for the intermediate nodes may aggregate the leaf nodes. It is 
not necessary for MVPN to know the failure of intermediate nodes, and the 
root node of MVPN only cares about the status of leaf nodes.

Mechanism of leaf node failure process
Root node of MVPN sets up a P2MP LSP with one root node and n leaf nodes. 
Root node finds that half of the leaf nodes (or some other 
methodology)fail to join in the P2MP LSP through "MVPN Failure signaling 
mechanism", then re-negotiates a new tunnel type.

The aim of "MVPN Failure signaling mechanism" is for MVPN to re-negotiate 
the type of tunnel. 

And futher more, if PE support multiple type of tunnel, various types of 
tunnel could be contained in PMSI tunnel attribute.  "MVPN Failure 
signaling mechanism" can be implemented by extending PMSI tunnel attribute
, and use UPDATE packets to indicate leaf node's failure setting up of 
P2MP LSP.

Thanks!

Best Regards
Jin Lizhong

Yakov Rekhter <[email-masked]>
2006-12-05 02:56
 
        To:     [email-masked]
        cc:     Rahul Aggarwal <[email-masked]>, [email-masked], 
[email-masked]
        Subject:        Re: Suggestion about 
draft-ietf-l3vpn-2547bis-mcast, Thanks

Jin,

Yakov.

> > This message has been scanned for viruses and Spam by ZTE Anti-Spam 
is 

> This email and any files transmitted with it are confidential and 
intended 

> This message has been scanned for viruses and Spam by ZTE Anti-Spam 
is so
lely property of the sender's organization. This mail communication is 
confiden
tial. Recipients named above are obligated to maintain secrecy and are not 
perm
itted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and 
intended so
lely for the use of the individual or entity to whom they are addressed. 
If you
 have received this email in error please notify the originator of the 
message.
 Any views expressed in this message are those of the individual sender.
system.
lly.</font>
sans-serif"><br>
;</b></font>
t,
<br>
> addressed. If you have received this email in error please notify the 
origina
tor
al
> This email and any files transmitted with it are confidential and 
intended
> the message. Any views expressed in this message are those of the 
individual
> This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.<b
r>

---

From: Thomas Morin <[email-masked]>
Date: Tue, 05 Dec 2006 17:09:25 +0100

Hi,

I agree that some kind of failure detection will be useful.
This failure detection (eg. based on P2MP CV) will depend on the type of
encapsulation chosen (and not on the mvpn control plane). 

Now, while this information can be used to improve the OAM plane, I am
not sure what can be the benefit of a tight integration with the control
plane : typically I'm really not sure it will be useful for a network
operator to have a router automatically fallback on another
encapsulation when the one being used is failing (this may not be very
predictable, and may cause the source PE to send traffic twice, etc.).  

As a general case, the proposed mVPN architecture tries to avoid being
overloaded with complex mechanisms of announcement/negociation of
encapsulation capabilities, but focuses on the assumptions that the
network operator will chose a reduced set of encapsulation modes, and
will ensure consistency of his routers capabilities for these modes.

There is only one case where a failure to setup a tunnel can be used by
the control plane : the P2MP RSVP-TE case. And for that case, as Rahul
mentioned, no piece is missing. 

Cheers,

-Thomas

[email-masked] :
> 
> Dear Yakov: 
>     
> Thanks for your opinion.  
> 
> When setting up a p2mp LSP with mLDP, the intermediate nodes (P
> routers) may not know the failure of the leaf nodes (PE 
> routers), for the intermediate nodes may aggregate the leaf nodes. It
> is not necessary for MVPN to know the failure of intermediate nodes,
> and the root node of MVPN only cares about the status of leaf nodes. 
> 
> Root node of MVPN sets up a P2MP LSP with one root node and n leaf
> nodes. Root node finds that half of the leaf nodes (or some other
> methodology)fail to join in the P2MP LSP through "MVPN Failure
> signaling mechanism", then re-negotiates a new tunnel type. 
> 
> The aim of "MVPN Failure signaling mechanism"is for MVPN to
> re-negotiate the type of tunnel.  
> 
> And futher more, if PE support multiple type of tunnel, various types
> of tunnel could be contained in PMSI tunnel attribute.  "MVPN Failure
> signaling mechanism" can be implemented by extending PMSI tunnel
> attribute, and use UPDATE packets to indicate leaf node's failure
> setting up of P2MP LSP. 
> 
> Thanks! 
> 
> Best Regards 
> Jin Lizhong 
> 
> 
>         cc:
>  Rahul Aggarwal
> <[email-masked]>,
> [email-masked],
> > > node(maybe also the multicast source node) to know the failure of
> the 
> > leaf
> > > node.
> > > multicast tunnel, then the root node can do something else, maybe
> the 
> > root
> > <br><font
> size=2><tt>..............................................<br>
> ZTE Information Security Notice: The information contained in this
> mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated to
> maintain secrecy and are not permitted to disclose the contents of
> this communication to others.
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the originator of the message. Any views expressed in this message are
> those of the individual sender.