Subject: [mpls] RE: New comments and ideas for <draft-ietf-mpls-ldp-p2mp-02>

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 8 Mar 2007 11:16:14 +0100

Hi Jin,
 
Procedures to advertise the P2MP capability should rely on encoding rules and procedures defined in draft-thomas-mpls-ldp-capabilities-02.txt.
This simply requires defining a new capability parameter, the P2MP capability, and requesting for a TLV code point.
Also note that v01 of draft-ietf-mpls-ldp-upstream (submitted last monday) is now aligned with draft-thomas.
 
>Second, in section 7.1.Protocol event, line 11, I think the word 'LSR-D' should be 'LSR-U', it is misunderstanding in both the version 1 and 2
. 
Actually this applies indifferently to LSR D and LSR U. 
 
Kind Regards,
 
JL

________________________________

	De : [email-masked] [mailto:[email-masked]] 
	Envoyé : jeudi 8 mars 2007 10:28
	À : [email-masked]; [email-masked]; [email-masked]; zzx-Huji KAMITE [email-masked]; [email-masked]; [email-masked]; LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]; [email-masked]; [email-masked]; [email-masked]
	Objet : New comments and ideas for <draft-ietf-mpls-ldp-p2mp-02>

	Dear all: 
	
	I read the draft <draft-ietf-mpls-ldp-p2mp-02>, and have some comments below. Thank you. 
	
	First, it is very necessary to use the mLDP capability TLV to signal the capability of LDP Session. Just like the capability described in <draft-ietf-mpls-ldp-upstream-00>, using the capability TLV, it is quite convenient to the trouble shooting. Without the capability TLV, if the P2MP LSP does not set up successfully, one has to check the upstream LSR; and if the upstream LSR does not show any information of P2MP LSP and FEC, we can not figure whether the mapping message sent by the downstream LSR is silently discarded by upstream LSR or lost during the transmission. 
	
	Because the mLDP is very new, and many equipments that have been deployed in the network do not support mLDP, then the scenario described above will always happen when deploying. And this is only one of the scenarios for capability TLV; it will be more useful and convenient for deploying mLDP. 
	
	Following is the format of the mLDP Capability TLV, much like defined in <draft-ietf-mpls-ldp-upstream-00>: 
	
	       0                   1                   2                   3 
	       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	      |1|0| Capability TLV (TBD)      |      Length (= 4)             | 
	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	      |                        Sub-TLVs...                            | 
	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	
	Following is the format of the mLDP Capability sub-TLV: 
	
	       0                   1                   2                   3 
	       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	      |         mLDP Cap = 1          |      Length (= 4)             | 
	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	      |                        Reserved                               | 
	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	
	If a LSR includes the mLDP Capability sub-TLV in LDP Initialization Messages it implies that the LSR is capable of processing both distributing P2MP FEC Element and MP2MP FEC Element. Reserved bits MUST be set to zero on transmission and MUST be ignored on receipt. 
	
	Second, in section 7.1.Protocol event, line 11, I think the word 'LSR-D' should be 'LSR-U', it is misunderstanding in both the version 1 and 2. 
	
	Hope for your comments, thank you very much. 
	
	Best Regards 
	Jin Lizhong 
	
	..............................................
	Add:   No.68 Zijinghua Rd,Yuhuatai District, 
	      Nanjing. P.R.China. 
	Zip:   210012 
	Tel:   0086-13912967531 
	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.

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: [email-masked]
Date: Thu, 8 Mar 2007 17:27:44 +0800

Dear all:

I read the draft <draft-ietf-mpls-ldp-p2mp-02>, and have some comments 
below. Thank you.

First, it is very necessary to use the mLDP capability TLV to signal the 
capability of LDP Session. Just like the capability described in 
<draft-ietf-mpls-ldp-upstream-00>, using the capability TLV, it is quite 
convenient to the trouble shooting. Without the capability TLV, if the 
P2MP LSP does not set up successfully, one has to check the upstream LSR; 
and if the upstream LSR does not show any information of P2MP LSP and FEC, 
we can not figure whether the mapping message sent by the downstream LSR 
is silently discarded by upstream LSR or lost during the transmission.

Because the mLDP is very new, and many equipments that have been deployed 
in the network do not support mLDP, then the scenario described above will 
always happen when deploying. And this is only one of the scenarios for 
capability TLV; it will be more useful and convenient for deploying mLDP.

Following is the format of the mLDP Capability TLV, much like defined in 
<draft-ietf-mpls-ldp-upstream-00>:

       0                   1                   2                   3

       0                   1                   2                   3

If a LSR includes the mLDP Capability sub-TLV in LDP Initialization 
Messages it implies that the LSR is capable of processing both 
distributing P2MP FEC Element and MP2MP FEC Element. Reserved bits MUST be 
set to zero on transmission and MUST be ignored on receipt.

Second, in section 7.1.Protocol event, line 11, I think the word 'LSR-D' 
should be 'LSR-U', it is misunderstanding in both the version 1 and 2. 

Best Regards
Jin Lizhong

---

From: Ina Minei <[email-masked]>
Date: Wed, 14 Mar 2007 08:20:47 -0700 (PDT)

Jin,

 	What would the capability accomplish? If it is a way to enable 
error notification, then this is already available in LDP today. Is there 
any other functionality that would be accomplished by turning on the 
capability advertisement?

 				Ina

On Wed, 14 Mar 2007 [email-masked] wrote:

> Hi JL
>
> Thank you very much for your comments.
>
> Does any other guys think P2MP capability TVL is necessary?
>
> Best Regards
> Jin Lizhong
>
> "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
> 2007-03-08 18:16
>
>        To:     <[email-masked]>, <[email-masked]>,
> <[email-masked]>, <[email-masked]>, "zzx-Huji KAMITE
> [email-masked]" <[email-masked]>, <[email-masked]>,
> <[email-masked]>, <[email-masked]>, <[email-masked]>,
> <[email-masked]>, <[email-masked]>
>        cc:
>        Subject:        RE: New comments and ideas for
> <draft-ietf-mpls-ldp-p2mp-02>
>
>
> Hi Jin,
>
> Procedures to advertise the P2MP capability should rely on encoding rules
> and procedures defined in draft-thomas-mpls-ldp-capabilities-02.txt.
> This simply requires defining a new capability parameter, the P2MP
> capability, and requesting for a TLV code point.
> À : [email-masked]; [email-masked]; [email-masked];
> zzx-Huji KAMITE [email-masked]; [email-masked]; [email-masked];
> LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]; [email-masked];
> [email-masked]; [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.
> 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.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 14 Mar 2007 11:56:19 +0100

Jin,

I agree with JL.

Thx,

Ice.

On Mar 14, 2007, at 8:10 AM, [email-masked] wrote:

>         To:        <[email-masked]>,  
> <[email-masked]>, <[email-masked]>,  
> <[email-masked]>, "zzx-Huji KAMITE  [email-masked]"  
> <[email-masked]>, <[email-masked]>, <[email-masked]>,  
> <[email-masked]>, <[email-masked]>, <[email-masked]>,  
> <[email-masked]>
>         cc:        
> Procedures to advertise the P2MP capability should rely on encoding  
> rules and procedures defined in  
> draft-thomas-mpls-ldp-capabilities-02.txt.
> Also note that v01 of draft-ietf-mpls-ldp-upstream (submitted last  
> monday) is now aligned with draft-thomas.
>  
> >Second, in section 7.1.Protocol event, line 11, I think the word  
> 'LSR-D' should be 'LSR-U', it is misunderstanding in both the version  
> 1 and 2
> .
>  À : [email-masked]; [email-masked];  
> [email-masked]; zzx-Huji KAMITE [email-masked];  
> [email-masked]; [email-masked]; LE ROUX Jean-Louis RD-CORE-LAN;  
> [email-masked]; [email-masked]; [email-masked];  
> [email-masked]
>  First, it is very necessary to use the mLDP capability TLV to signal  
> the capability of LDP Session. Just like the capability described in  
> <draft-ietf-mpls-ldp-upstream-00>, using the capability TLV, it is  
> quite convenient to the trouble shooting. Without the capability TLV,  
> if the P2MP LSP does not set up successfully, one has to check the  
> upstream LSR; and if the upstream LSR does not show any information of  
> P2MP LSP and FEC, we can not figure whether the mapping message sent  
> by the downstream LSR is silently discarded by upstream LSR or lost  
> during the transmission.
>
>  Because the mLDP is very new, and many equipments that have been  
> deployed in the network do not support mLDP, then the scenario  
> described above will always happen when deploying. And this is only  
> one of the scenarios for capability TLV; it will be more useful and  
> convenient for deploying mLDP.
>
> distributing P2MP FEC Element and MP2MP FEC Element. Reserved bits  
> MUST be set to zero on transmission and MUST be ignored on receipt.
>
>  Second, in section 7.1.Protocol event, line 11, I think the word  
> 'LSR-D' should be 'LSR-U', it is misunderstanding in both the version  
> 1 and 2.
>
>  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.
> ZTE Information Security Notice: The information contained in this mail 
>  is solely property of the sender's organization. This mail communicati 
> on is confidential. Recipients named above are obligated to maintain se 
> crecy and are not permitted to disclose the contents of this communicat 
> ion to others.
> This email and any files transmitted with it are confidential and inten 
> ded solely for the use of the individual or entity to whom they are add 
> ressed. If you have received this email in error please notify the orig 
> inator of the message. Any views expressed in this message are those of 
>  the individual sender.

---

From: [email-masked]
Date: Wed, 14 Mar 2007 15:10:57 +0800

Hi JL

Best Regards
Jin Lizhong

 

Hi Jin,
 
Procedures to advertise the P2MP capability should rely on encoding rules 
and procedures defined in draft-thomas-mpls-ldp-capabilities-02.txt.
This simply requires defining a new capability parameter, the P2MP 
capability, and requesting for a TLV code point.
Also note that v01 of draft-ietf-mpls-ldp-upstream (submitted last monday) 
is now aligned with draft-thomas.
 
>Second, in section 7.1.Protocol event, line 11, I think the word 'LSR-D' 
should be 'LSR-U', it is misunderstanding in both the version 1 and 2
. 
Actually this applies indifferently to LSR D and LSR U. 
 
Kind Regards,
 
JL

Dear all: 

       0                   1                   2                   3 

       0                   1                   2                   3 

Best Regards 
Jin Lizhong 

This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: Thomas Morin <[email-masked]>
Date: Fri, 16 Mar 2007 17:01:24 +0100

Hi,

> capability advertisement?

This question does indeed make sense.

For instance, having mLDP capability be advertised by LDP won't permit
using P2MP LDP on a topology where only a subset of routers is
mLDP-aware, even if the mLDP aware nodes/links would provide a connex
topology. Because the capability information is "local" (not in the
IGP), it can't be used to have routers select the
best-neighbors-among-mLDP-aware-neighbors in a reliable manner:
non-transient loops would possibly exist.

-Thomas

> _______________________________________________ mpls mailing list [email-masked] https://www1.ietf.org/mailman/listinfo/mpls

---

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 16 Mar 2007 19:23:33 +0100

Hi Thomas,

> non-transient loops would possibly exist.

Right, there is no way you can reroute around non-mLDP capable routers. 
One reason we like to have draft-thomas-mpls-ldp-capabilities-02.txt 
support a capability for mLDP is to let your adjacent LDP router know 
that mLDP has been enabled. That way the adjacency routers can trigger 
mLDP label mappings to populate the state with out the need to reset 
the LDP session.

Thx,

Ice.

>>> rules
>>>> 'LSR-D'
>>> [email-masked];
>>> the
>>> quite
>>> deployed
>>>      |                        Sub-TLVs...                            
>>> |
>>>      |                        Reserved                               
>>> |
>>> MUST be
>>> 'LSR-D'
>>> mail is
>>> intended
>>> mail is
>>> intended
>>> communication is confidential. Recipients named above are obligated 
>>> to maintain secrecy and are not permitted to disclose the contents 
>>> of this communication to others.
>>> 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.
>> _______________________________________________ mpls mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/mpls
>
>

---

From: Thomas Morin <[email-masked]>
Date: Sun, 18 Mar 2007 20:29:49 +0100

Hi Ice,

IJsbrand Wijnands :
> Ina Minei:
> >> [...] 
> >> Is there any other functionality that would be accomplished by turning on the

[ BTW, using a multitopology-IGP or announcing the capability in the IGP
could provide a solution to this. If there is a requirement need for
it. ]

> mLDP label mappings to populate the state with out the need to reset 

I definitely agree that such capability advertisement will be useful.

Thanks,

-Thomas

---

From: [email-masked]
Date: Thu, 15 Mar 2007 20:16:38 +0800

Hi Ina:

Thank you for your reply and comments.

You are right, LDP error notification can handle the unknow TLV for LDP 
P2MP TLV. 

Not using capability TLV
1. If we use error notification to handle it, and when LSR receives the 
error notification with unknow tlv, then it does not send the mLDP mapping 
message. It is not explicitly expressing the error. I don't think its a 
nice processing for mLDP. 

Using capability TLV
1. If we don't use the above mechanism, and if the LSR don't know its 
neighbor does not support mLDP capability, it will continue sending mLDP 
mapping message to its neighbor, and many error notification messages will 
be continuely received. If we use mLDP capability negotiation, then LSR 
will not send mLDP mapping message to its neighbor, and save many 
processing of LDP protocol messages.

2. Using mLDP capability TLV, it can be very easy to see what's wrong with 
this P2MP LSP, and can easily avoid P2MP LSP partially being set up.

3. If we use mLDP capability TLV, then mLDP can be very clearly co-existed 
with many other LDP capabilities, such as upstream label assign 
capability. And the virtue of LDP capability TLV also has been described 
in [draft-thomas-mpls-ldp-capabilities-02].

Thanks you very much.

Best Regards
Jin Lizhong

ZTE Corporation

Ina Minei <[email-masked]>
2007-03-14 23:20
 
        To:     [email-masked]
        cc:     LE ROUX Jean-Louis RD-CORE-LAN 
<[email-masked]>, [email-masked], 
[email-masked], [email-masked], "zzx-Huji KAMITE 
[email-masked]" <[email-masked]>, [email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked]
        Subject:        RE: [MPLS]New comments and ideas for 
<draft-ietf-mpls-ldp-p2mp-02>

                 Jin,

                 What would the capability accomplish? If it is a way to 
enable 
error notification, then this is already available in LDP today. Is there 
any other functionality that would be accomplished by turning on the 
capability advertisement?

                                                                 Ina

rules
> Also note that v01 of draft-ietf-mpls-ldp-upstream (submitted last 
monday)
'LSR-D'
deployed
> <draft-ietf-mpls-ldp-upstream-00>:
is
intended
> This message has been scanned for viruses and Spam by ZTE Anti-Spam
is
intended
> This message has been scanned for viruses and Spam by ZTE Anti-Spam
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.
system.

---

From: [email-masked]
Date: Mon, 19 Mar 2007 08:38:34 +0800

Hi Ina:

When not using capability TLV

When using capability TLV
1. If we don't use the above mechanism, and if the LSR don't know its 
neighbor does not support mLDP capability, it will continue sending mLDP 
mapping message to its neighbor, and many error notification messages will 
be continuely received for each P2MP LSP. If we use mLDP capability 
negotiation, then LSR will not send mLDP mapping message to its neighbor, 
and save many processings of LDP protocol messages.

2. For mLDP is very new, when deploying, there must be some LSRs that not 
supporting mLDP. Using mLDP capability TLV, it can be very easy to see 
what's wrong with this P2MP LSP, and can easily avoid P2MP LSP partially 
being set up.

3. If we use mLDP capability TLV, then mLDP can be very clearly co-existed 
with many other LDP capabilities, such as upstream label assigning 
capability. And the virtue of LDP capability TLV also has been described 
in [draft-thomas-mpls-ldp-capabilities-02].

Thanks you very much.

Best Regards
Jin Lizhong

 

                 Jin,

                                                                 Ina

rules
monday)
'LSR-D'
deployed
is
intended
is
intended
system.

---

From: Ina Minei <[email-masked]>
Date: Wed, 21 Mar 2007 16:13:29 -0700 (PDT)

Thank you for the comments. The new revision of the draft will 
reflect this discussion.

 				Ina