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

From: venkatesan mahalingam <[email-masked]>
Date: Wed, 13 Apr 2011 20:54:11 -0400

I agree with Curtis. We may have to dynamically notify the LSP-id change
from local PE to the Remote PE when there is a change in LSP.
I support this draft for WG adoption before or after solving the LSP-id
change related notification.

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

   - *To*: "Andrew G. Malis" <amalis at gmail.com <[email-masked]>>
   - *Subject*: Re: [PWE3] PWE3 working group poll for
   draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt
   - *From*: Curtis Villamizar <curtis at occnc.com <[email-masked]>>
   - *Date*: Wed, 13 Apr 2011 15:23:04 -0400
   - *Cc*: pwe3 at ietf.org <[email-masked]>
   - *Delivered-to*: pwe3 at ietfc.amsl.com <[email-masked]>
   - *In-reply-to*: Your message of "Wed, 13 Apr 2011 07:49:59 EDT."
<BANLkTi=jMSCH37CkHhZfTY2Zoq9V_BxCzw
   at mail.gmail.com <[email-masked]>>
   - *List-archive*: <http://www.ietf.org/mail-archive/web/pwe3>
   - *List-help*:
<mailto:[email-masked]?subject=help<[email-masked]?subject=help>
   - *List-id*: Pseudo Wires Edge to Edge <pwe3.ietf.org>
   - *List-post*: <mailto:[email-masked] <[email-masked]>>
   - *List-subscribe*: <https://www.ietf.org/mailman/listinfo/pwe3>, <
   mailto:[email-masked]?subject=subscribe<[email-masked]?subject=subscribe>
   - *List-unsubscribe*: <https://www.ietf.org/mailman/options/pwe3>, <
   mailto:[email-masked]?subject=unsubscribe<[email-masked]?subject=unsubscribe>
   - *Reply-to*: curtis at occnc.com <[email-masked]>
   - *Sender*: curtis at occnc.com <[email-masked]>

------------------------------

In message <BANLkTi=jMSCH37CkHhZfTY2Zoq9V_BxCzw at mail.gmail.com>
"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