Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt

From: [email-masked]
Date: Fri, 15 Apr 2011 15:04:56 +0800

I agree with Curtis, and I also raised similar comments before MIC during 
IETF79 in Beijing.

Additional more comments as below:
1. section 2, what's the difference between figure2 and figure3 of the LSP 
encoding? If they are the same, can we use only one type of TLV? In 
draft-ietf-mpls-tp-identifiers-04, the node id is 32bit, why this document 
define node-id with IPv6 address?
2. Suggest to not include unidirectional LSPs in section 2, and only cover 
the co-routed and associated LSP. Unidirectional LSPs works fine 
currently.
3. I suggest to keep the PW signaling independent as much as possible, and 
each end-point just simply indicate its locally configured LSP to the 
remote end-point. For the co-routed LSP, each PE can check if the binding 
is correct, if not, just raise an alarm. Such kind of alarm can be cleared 
by the operator if it is not an issue.

Regards
Lizhong

> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 13 Apr 2011 15:23:04 -0400
> From: Curtis Villamizar <[email-masked]>
> To: "Andrew G. Malis" <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [PWE3] PWE3 working group poll for
>    draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt
> Message-ID: <[email-masked]>
> 
> 
> In message <BANLkTi=[email-masked]>
> "Andrew G. Malis" writes:
> > 
> > The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have
> > asked that this draft be made a PWE3 working group draft.
> > 
> > This email starts a two week poll, closing Tuesday April 26, to help
> > judge consensus on this.
> > 
> > Please send your responses to the PWE3 list.
> > 
> > Thanks,
> > Andy and Matthew
> 
> 
> 
> No - not in its current form - maybe with some significant issues
> resolved.
> 
> 
> The draft as it now stands identifies the underlying tunnel by
> endpoint ID, 16 bit tunnel index, and 16 bit LSP ID.  The LSP ID may
> be a transient value in the general MPLS case.
> 
> In the general MPLS case, the LSP ID is a transient value according to
> RFC 3209 while the tunnel ID in the SESSION object remains constant.
> For example, if RFC 3209 make-before-break is used, the LSP-ID changes
> but the Extended Tunnel ID remains the same.
> 
> See RFC 3209 section 2.5.  Specifically "To effect a reroute, the
> ingress node picks a new LSP ID and forms a new SENDER_TEMPLATE."
> 
> This also has to be done to increase the bandwidth on an LSP using
> make-before-break.
> 
> An LSP (or more correctly a tunnel) may carry many PW.  IF a PW is
> added, the bandwidth may have to be increased.  If the bandwidth is
> increased using make-before-creak semantics, then the LSP-ID is
> changed and all of the other PW in the LSP would have to be resignaled
> with the new LSP-ID.
> 
> Also if a working an protect LSP were selected with GMPLS style path
> protections, the LSP-ID delivering traffic is different when
> protection is enabled.  This could be ignored, but if so needs to be
> mentioned.  If both paths go down and a new path has to be created
> with a reroute, then the LSP-ID changes.  If a better path becomes
> available or some optimization is made changing the working path, then
> a new LSP-ID is created.
> 
> I would rather see these problems resolved *before* making this a WG
> document.
> 
> Curtis
> 
> 
> 

--------------------------------------------------------
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: Mach Chen <[email-masked]>
Date: Fri, 15 Apr 2011 09:12:32 +0000

Hi Lizhong,

Thanks for your comments!

Please see my reply inline...
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, April 15, 2011 3:05 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt

I agree with Curtis, and I also raised similar comments before MIC during IETF79 in Beijing.

Additional more comments as below:
1. section 2, what's the difference between figure2 and figure3 of the LSP encoding? If they are the same, can we use only one type of TLV? In draft-ietf-mpls-tp-identifiers-04, the node id is 32bit, why this document define node-id with IPv6 address?

[Mach]  The difference is that one is for IPv4 and the other is for IPv6 scenario.  The reason for IPv6 address based node-id is that: for a MPLS/GMPLS TE LSP(RFC3209, RFC3471), the Extended Tunnel ID, Tunnel end point address, and Tunnel sender address(which are used to identify a specific TE LSP) could be IPv6 addresses, and this draft is not only for MPLS-TP scenario, but for normal cases where require both directions of a PW to follow congruent path.

2. Suggest to not include unidirectional LSPs in section 2, and only cover the co-routed and associated LSP. Unidirectional LSPs works fine currently.

[Mach] The key point is about how to guarantee a bidirectional PW to follow congruent path(no matter what the tunnel is uni- or bi-directional). Including unidirectional LSPs is for the cases where there are only unidirectional LSPs available.

3. I suggest to keep the PW signaling independent as much as possible, and each end-point just simply indicate its locally configured LSP to the remote end-point. For the co-routed LSP, each PE can check if the binding is correct, if not, just raise an alarm. Such kind of alarm can be cleared by the operator if it is not an issue.

[Mach] Do you mean that the PW signaling of each end should be independent? If so, IMHO, this is not the practice of the existing PW signaling. With the current PW signaling, many attributes has to be negotiated when setup a PW(e.g., AC-ID, CW, PW Status, VCCV type, etc) between PEs. So, back to this PW-to-LSP binding, the tunnel LSP is just like another attribute that require to be negotiated between the both ends when setup a PW, hence to make sure that the both directions of the PW are over the desired congruent paths.

Best regards,
Mach

Regards
Lizhong

---

From: [email-masked]
Date: Fri, 15 Apr 2011 17:31:45 +0800

Hi Mach,
See comments in line below.

Regards
Lizhong

Mach Chen <[email-masked]> wrote on 2011-04-15 05:12:32:

> Please see my reply inline…
> 1. section 2, what's the difference between figure2 and figure3 of 
> the LSP encoding? If they are the same, can we use only one type of 
> TLV? In draft-ietf-mpls-tp-identifiers-04, the node id is 32bit, why
> this document define node-id with IPv6 address? 
> 
> [Mach]  The difference is that one is for IPv4 and the other is for 
> IPv6 scenario.  The reason for IPv6 address based node-id is that: 
> for a MPLS/GMPLS TE LSP(RFC3209, RFC3471), the Extended Tunnel ID, 
> Tunnel end point address, and Tunnel sender address(which are used 
> to identify a specific TE LSP) could be IPv6 addresses, and this 
> draft is not only for MPLS-TP scenario, but for normal cases where 
> require both directions of a PW to follow congruent path.
[Lizhong] if you use LDPv6 as the signaling protocol, there should be also 
a 32bit value of LDP-ID to be used as node id.

> 
> 2. Suggest to not include unidirectional LSPs in section 2, and only
> cover the co-routed and associated LSP. Unidirectional LSPs works 
> fine currently. 
> 
> [Mach] The key point is about how to guarantee a bidirectional PW to
> follow congruent path(no matter what the tunnel is uni- or bi-
> directional). Including unidirectional LSPs is for the cases where 
> there are only unidirectional LSPs available. 
[Lizhong] for unidirectional LSP case, just leave it as it is now, by 
configuration and administration. I think this is a rare case.

> 
> 3. I suggest to keep the PW signaling independent as much as 
> possible, and each end-point just simply indicate its locally 
> configured LSP to the remote end-point. For the co-routed LSP, each 
> PE can check if the binding is correct, if not, just raise an alarm.
> Such kind of alarm can be cleared by the operator if it is not an issue. 

> 
> [Mach] Do you mean that the PW signaling of each end should be 
> independent? If so, IMHO, this is not the practice of the existing 
> PW signaling. With the current PW signaling, many attributes has to 
> be negotiated when setup a PW(e.g., AC-ID, CW, PW Status, VCCV type,
> etc) between PEs. So, back to this PW-to-LSP binding, the tunnel LSP
> is just like another attribute that require to be negotiated between
> the both ends when setup a PW, hence to make sure that the both 
> directions of the PW are over the desired congruent paths. 
[Lizhong] I mean not to negotiated the LSP automatically, just indicate an 
alarm to the operator if not congruent.