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

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 13 Apr 2011 07:49:59 -0400

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

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 13 Apr 2011 13:14:55 +0000

I am sure that we need a way to generate co-routed bidirectional PWs,
and thus believe that we need a solution to the problem.
BTW, in TICTOC we have a document draft-ietf-tictoc-1588overmpls
that accomplishes this for timing over IP over MPLS, using RSVP-TE.

There are two questions :
1) is the solution in the scope of PWE3 ?
2) is the solution the right one ?

The PWE3 charter states :
   PWE3 operates "edge to edge" and will not exert control on
   the underlying PSN, other than to use any existing QoS or
   path control mechanism to provide the required connectivity
   between the endpoints of the PW.

So we seem to be covered by the "other than" exception.

GMPLS provides a mechanism for co-routing LSPs,
while PWE3 mechanisms (and certainly the LDP-based PWE3 control protocol)
do not provide such mechanisms.
However, as the draft shows, by ensuring that a PW is placed in the correct LSP
we get co-routing essentially free of charge.

So I support adoption as a WG draft.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Wednesday, April 13, 2011 14:50
To: [email-masked]
Subject: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt

Thanks,
Andy and Matthew
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Ping Pan <[email-masked]>
Date: Wed, 13 Apr 2011 08:30:40 -0700

This is a good solution solving a real problem. Support to make it as a WG
draft.

Thanks!

- Ping

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 13 Apr 2011 14:18:40 -0400

> we get co-routing essentially free of charge.

	Is it possible to adapt the GMPLS approach to solve this problem rather than reinventing the wheel?

	--Tom

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 13 Apr 2011 15:23:04 -0400

In message <BANLkTi=[email-masked]>
> Please send your responses to the PWE3 list.

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

---

From: Jie Dong <[email-masked]>
Date: Thu, 14 Apr 2011 02:31:23 +0000

The requirement is clear and the solution is reasonable.

Support the adoption.

Regards,
Jie

> Sent: Wednesday, April 13, 2011 7:50 PM
> To: [email-masked]
> Subject: [PWE3] PWE3 working group poll for
> draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt
>

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 13 Apr 2011 20:31:24 -0700

This is very useful draft providing solution for a real problem. Hence, I support it.

-sam

Sent from my iPad

---

From: Luca Martini <[email-masked]>
Date: Wed, 13 Apr 2011 23:02:45 -0600

> 2) is the solution the right one ?
You did not answer question #2 ...

Luca

---

From: Luca Martini <[email-masked]>
Date: Wed, 13 Apr 2011 23:27:16 -0600

> Please send your responses to the PWE3 list.
No, Not in the current form.
Although I agree that this problem is a real problem and needs a
solution, this draft does not have enough information to actually build
a protocol extension to LDP.
In addition to the problems that Curtis mentions, there is no
description on how to use the proposed TLVs in the LDP message.

How would LDP , which is IP based , even run on an MPLS-TP network ?

PW assume that a PSN tunnel is identified by an IP address, which is
also used as the LDP target session IP address.
How is this possible with an MPLS-TP LSP ?

At the minimum we would need some way to identify the IP address at the
other end of the mpls-tp tunnel.

Also I strongly believe that this WG needs to stop attempting to extend
FEC 128 to have similar functionality as FEC 129.
Just define new extensions for FEC 129 only , unless they are minor ,
and can be supported by FEC 128 without changing any existing procedures...

Luca

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 13 Apr 2011 23:09:24 -0700

Luca,
you've asked
How would LDP , which is IP based , even run on an MPLS-TP network ?
but isn't T-LDP part of MPLS-TP control plane? Control plane assumes IP
addressing thus use of T-LDP is plausible.

Regards,
Greg

---

From: Mach Chen <[email-masked]>
Date: Thu, 14 Apr 2011 09:09:12 +0000

Hi Luca,

Thanks for your comments!

> solution,

Great!

> this draft does not have enough information to actually build

Please note that this is not a WG last call :-)  the draft is still working in progress, and we'd appreciate that could give suggestion and advice!

> description on how to use the proposed TLVs in the LDP message.

Section 3 of the draft does describe the usage of the PW to LSP Binding TLVs, they are carried in the LDP Mapping message for associating tunnel selection and binding when signaling a PW, the current version of this draft defines how to communicate tunnel LSP selection and binding at the initiation of a PW. Regarding Curtis's comments, it's about dynamic changing the tunnel LSP (whatever for FRR, reroute or protection switching) after a PW established, the authors are working on a revision to resolve the this. And suggestions are welcomed!

> How is this possible with an MPLS-TP LSP ?

As Greg pointed out , this is about the extension to the control plane of PW and LDP is it, and MPLS-TP may run with control plane.

In addition, this mechanisms defined in this document is not only for MPLS-TP network, but could be applied to any other scenarios where require both directions of a PW having congruent paths.

Best regards,
Mach

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 14 Apr 2011 15:01:11 +0000

> Luca

I answered it by saying that simply forcing placement of a PW into the appropriate LSP
solves the problem. (Meaning that I do not want more complex PW-specific methods.)

I purposely did not state whether the particular LDP mechanism proposed is optimal or even correct.
This is not a LC, it is just a motion to move this to WG status.

Y(J)S

---

From: Luca Martini <[email-masked]>
Date: Thu, 14 Apr 2011 10:07:52 -0600

> This is not a LC, it is just a motion to move this to WG status.
Yes , but historically we have always moved documents to wg status that
where at least 80% there...
This document is maybe 10% done.
I do not think that there is any argument that we, as the PWE3 WG, want
to work on this problem.
Can you suggest something a bit more complete then ?

Thanks.
Luca

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 14 Apr 2011 18:45:08 +0100

Luca, Yaakov, Colleagues,

I'll admit I haven;t read draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02 so I won't express any specific opinion on that, however please see below.

> I do not think that there is any argument that we, as the PWE3 WG, want

If the WG agrees to work on a problem then that's a milestone in the charter IMO.

If the WG has a reasonable idea of what the solution should be and a reasonable enough description of that solution is documented in a draft such that folks can stand behind it and say "yes that's the right direction to take to solve the problem" then that's the right time to "promote" it to a WG draft and bring it under WG change control in order to finish it off IMO.

Promoting a solution draft to a WG draft with a view of "once it's a WG draft we'll figure out what actual solution to put in there later" seems a bad idea to me.

Ben

---

From: Luca Martini <[email-masked]>
Date: Thu, 14 Apr 2011 12:10:44 -0600

On 04/14/11 00:09, Greg Mirsky wrote:
> but isn't T-LDP part of MPLS-TP control plane? Control plane assumes
> IP addressing thus use of T-LDP is plausible.
>
No T-LDP is not  part of the MPLS-TP control plane.
It could be , but i think folks are more leaning toward GMPLS instead.

Note that the problem described in this document exists for MPLS. So in
that case LDP is certainly used. But the document appears to only care
about MPLS-TP.

Luca

> Regards,
> Greg
>
> On Wed, Apr 13, 2011 at 10:27 PM, Luca Martini <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 14 Apr 2011 14:50:50 -0400

I'm with luca. As I said earlier I'd like more discussion as to whether or not other existing solutions couldn't be leveraged before we go forward with this one as it is quite under specified.

Tom

---

From: Mach Chen <[email-masked]>
Date: Fri, 15 Apr 2011 02:35:17 +0000

Hi Luca,

You said T-LDP is not part of the MPLS-TP control plane.

IMHO, this is not right, according to Section 4.4.1 of RFC5921, there is figure about "MPLS-TP layer boundary", it shows that PW belongs to MPLS-TP layer.

In addition, in the abstract of MPLS-TP control plane (http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-cp-framework-06), it says:
"...MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for Pseudowires (PWs)..."

Best regards,
Mach

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Luca Martini
> Sent: Friday, April 15, 2011 2:11 AM
> To: Greg Mirsky
> Cc: [email-masked]
> Subject: Re: [PWE3] PWE3 working group poll for

---

From: Mach Chen <[email-masked]>
Date: Fri, 15 Apr 2011 02:36:03 +0000

Hi Tom，

One candidate solution is manual configuration, but it is prone to configuration error and inefficient to manage large number of PWs, and even worse when do FRR, reroute, protection switching. 

That will be helpful if you could enumerate some other candidates, then the WG could discuss it more specifically.

Best regards,
Mach

> Thomas Nadeau
> Sent: Friday, April 15, 2011 2:51 AM
> To: Luca Martini
> Cc: Yaakov Stein; [email-masked]
> I'm with luca. As I said earlier I'd like more discussion as to whether or not
> other existing solutions couldn't be leveraged before we go forward with this
> one as it is quite under specified.
> 
> Tom
> 
> 
>

---

From: Mach Chen <[email-masked]>
Date: Fri, 15 Apr 2011 02:41:34 +0000

Hi Yaakov and Luca,

I think Section 5.3.2. "Support for Explicit Control of PW-to-LSP Binding" of http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-cp-framework-06 could answer the question #2.

Best regards,
Mach

> Yaakov Stein
> Sent: Thursday, April 14, 2011 11:01 PM
> To: Luca Martini
> Cc: [email-masked]

---

From: Mach Chen <[email-masked]>
Date: Fri, 15 Apr 2011 02:57:29 +0000

Hi Luca,

I am not sure where is the 10% from, that will be helpful you could point out what are the other 90% :-)

Until now, the only unresolved specific comments is from Cutris, so we'd appreciate more people to read the draft(http://tools.ietf.org/html/draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02) and give your comments!

Best regards,
Mach

> Sent: Friday, April 15, 2011 12:08 AM
> To: Yaakov Stein
> Cc: [email-masked]

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 15 Apr 2011 07:40:24 +0300

Luca, and all,
>From RFC 5718 "An In-Band Data Communication Network For the MPLS Transport Profile":
<quote>
2.1.  Pseudowire Setup

   Provider Edge nodes (PEs) may wish to set up PWs using a signaling
   protocol that uses remote adjacencies (such as LDP [RFC5036]).  In
   the absence of an IP-based control plane network, these PEs MUST
   first set up an LSP tunnel across the MPLS-TP network.  This tunnel
   can be used both to carry the PW once it has been set up and to
   provide a G-ACh-based DCN for control plane communications between
   the PEs.
<end quote>

I interpret this as accepting T-LDP as an element of the MPLS-TP control plane for PWs.

Please note also that MS-PWs may cross IP/MPLS and MPLS-TP domains, in which case usage of T-LDP as the signaling protocol seems natural.

To make it clear, this should not be taken as support (or lack thereof) for draft-cao.
My position with regard to this draft is similar to Ben's.

Regards,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Luca Martini [[email-masked]]
Sent: Thursday, April 14, 2011 9:10 PM
To: Greg Mirsky
Cc: [email-masked]
Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt

Luca

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 15 Apr 2011 07:45:10 +0300

Mach, Luca, Greg and all,
I concur with Mach on this point.

Regards,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Mach Chen [[email-masked]]
Sent: Friday, April 15, 2011 5:35 AM
To: Luca Martini; Greg Mirsky
Cc: [email-masked]; [email-masked]
Subject: [PWE3] Whether T-LDP is part of the MPLS-TP control plane

Hi Luca,

Best regards,
Mach

---

From: <[email-masked]>
Date: Fri, 15 Apr 2011 08:12:59 +0100

Luca is actually correct in that PWs are NOT part of the MPLS-TP CP.  This follows from the simple (obvious?) observation that MS PWs represent a different layer network to MPLS-TP.  The fact PWs should not exist in MPLS-TP is a different issue...but given they do then their functional layer network specification has to be addressed.

Aside=> I asked Stewart (Bryant) many months ago on a call (in the early ITU/IETF discussion days) as to why we don't simply use the same GMPLS-based signalling protocol for setting up PW connections as we do for MPLS-TP connections, ie why reinvent the wheel?  I also had a secondary point that the PW layer CP/MP also needs to be logically OOB like the MPLS-TP CP/MP.  I was told for the 1st point that it was because RSVP-TE does not support the specific type of addressing that PWs use.  [Note that access point addressing is probably THE most definitive component of defining a layer network and one has to take great care with it.  Get it wrong or do it badly at the outset (I can think of some examples ;-)) and it is very hard to change later.]  Wrt to the 2nd point Stewart had already realised there was also an OOB issue for the PW layer network CP/MP, but had no answer at that time.

regards, Neil

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

> Alexander Vainshtein
> Sent: 15 April 2011 05:45
> To: Mach Chen; Luca Martini; Greg Mirsky
> Subject: Re: [PWE3] Whether T-LDP is part of the MPLS-TP control plane
> 
> IMHO, this is not right, according to Section 4.4.1 of RFC5921, there
> is figure about "MPLS-TP layer boundary", it shows that PW belongs to
> MPLS-TP layer.
> 
> In addition, in the abstract of MPLS-TP control plane
> (http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-cp-framework-06),
> it says:
> "...MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched
> Paths (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for
> Pseudowires (PWs)..."
> 
> Best regards,
> Mach
> 
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please inform
> us by e-mail, phone or fax, and then delete the original and all copies
> thereof.
>

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 15 Apr 2011 07:54:24 -0400

> That will be helpful if you could enumerate some other candidates, then the WG could discuss it more specifically.

	Take a look at the GMPLS area's bidir LSP solution.

	--Tom

---

From: Francesco Fondelli <[email-masked]>
Date: Fri, 15 Apr 2011 16:19:12 +0200

Hi,

hemmm D'oh :-)

   --- draft-ietf-ccamp-mpls-tp-cp-framework-06 ---

   'Per the MPLS-TP framework [RFC5921], the MPLS-TP control plane is
based on GMPLS with
    RSVP-TE for LSP signaling and targeted LDP for PW signaling'

and "How would LDP , which is IP based , even run on an MPLS-TP network ?"

just fine

ciao
FF

On Thu, Apr 14, 2011 at 8:10 PM, Luca Martini <[email-masked]> wrote:
>>     > 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
>>     > _______________________________________________
>>     > pwe3 mailing list
>>     > [email-masked] <mailto:[email-masked]>
>>     > https://www.ietf.org/mailman/listinfo/pwe3

---

From: Mach Chen <[email-masked]>
Date: Fri, 15 Apr 2011 18:06:02 +0000

Tom,

I have feeling that you may not really understand the problem that the draft tries to resolve. 

The problem is that the current mechanism can not guarantee both directions of a  PW select and bind to congruent tunnel  LSP when there are multiple LSPs exists between the two PEs, even if there are GMPLS bidir LSPs exist.  This is because that each end of the PW selects and binds to PSN tunnel LSP independently.

Best regards,
Mach  
________________________________________
发件人: [email-masked] [[email-masked]] 代表 Thomas Nadeau [[email-masked]]
发送时间: 2011年4月15日 19:54
到: Mach Chen
Cc: [email-masked]; Yaakov Stein; Luca Martini
主题: Re: [PWE3] PWE3 working group       poll    for     draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt

        --Tom

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Apr 2011 20:13:43 -0400

> addressing thus use of T-LDP is plausible.

Greg,

MPLS-TP when using a control plane uses OSPF with OSPF-TE extensions
or ISIS with ISIS-TE extensions and uses RSVP-TE with many applicable
GMPLS extensions to the base MPLS RSVP-TE.

There is no such thing as PW-TP.  The control plane for PW is always
TCP over IP over something.  It could be over the IP forwarding
supported byt the plain old OSPF or ISIS link state IGP or it could be
over a G-Ach reserved for control plane traffic.  The IGP could also
use the control plane G-Ach, even on sections where G-Ach would ride
over a naked GAL - no pun intended.  There could also be no MPLS-TP
control plane but PW T-LDP control plane over this G-Ach.

An assumption is that T-LDP can function somehow if PW are being
signaled (are not static).

Curtis

> --bcaec548654058ad5304a0dac45d
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>  
> Luca,<br>you&#39;ve asked<br>How would LDP , which is IP based , even run o=
> n an MPLS-TP network ?<br>but isn&#39;t T-LDP part of MPLS-TP control plane=
> ? Control plane assumes IP addressing thus use of T-LDP is plausible.<br>
> <br>Regards,<br>Greg<br><br><div class=3D"gmail_quote">On Wed, Apr 13, 2011=
>  at 10:27 PM, Luca Martini <span dir=3D"ltr">&lt;<a href=3D"mailto:lmartini=
> @cisco.com">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=
> =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid=
>  rgb(204, 204, 204); padding-left: 1ex;">
> <div class=3D"im">On 04/13/11 05:49, Andrew G. Malis wrote:<br>
> &gt; The authors of draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt have<br=
> >
> &gt; asked that this draft be made a PWE3 working group draft.<br>
> &gt;<br>
> &gt; This email starts a two week poll, closing Tuesday April 26, to help<b=
> r>
> &gt; judge consensus on this.<br>
> &gt;<br>
> &gt; Please send your responses to the PWE3 list.<br>
> &gt;<br>
> &gt; Thanks,<br>
> &gt; Andy and Matthew<br>
> &gt; _______________________________________________<br>
> &gt; pwe3 mailing list<br>
> &gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/pwe3" target=3D"_blan=
> k">https://www.ietf.org/mailman/listinfo/pwe3</a><br>
> </div>No, Not in the current form.<br>
> Although I agree that this problem is a real problem and needs a<br>
> solution, this draft does not have enough information to actually build<br>
> a protocol extension to LDP.<br>
> In addition to the problems that Curtis mentions, there is no<br>
> description on how to use the proposed TLVs in the LDP message.<br>
> <br>
> How would LDP , which is IP based , even run on an MPLS-TP network ?<br>
> <br>
> PW assume that a PSN tunnel is identified by an IP address, which is<br>
> also used as the LDP target session IP address.<br>
> How is this possible with an MPLS-TP LSP ?<br>
> <br>
> At the minimum we would need some way to identify the IP address at the<br>
> other end of the mpls-tp tunnel.<br>
> <br>
> Also I strongly believe that this WG needs to stop attempting to extend<br>
> FEC 128 to have similar functionality as FEC 129.<br>
> Just define new extensions for FEC 129 only , unless they are minor ,<br>
> and can be supported by FEC 128 without changing any existing procedures...=
> <br>
> <font color=3D"#888888"><br>
> <br>
> Luca<br>
> </font><div><div></div><div class=3D"h5"><br>
> <br>
> _______________________________________________<br>
> pwe3 mailing list<br>
> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <a href=3D"https://www.ietf.org/mailman/listinfo/pwe3" target=3D"_blank">ht=
> tps://www.ietf.org/mailman/listinfo/pwe3</a><br>
> </div></div></blockquote></div><br>
>  
> --bcaec548654058ad5304a0dac45d--

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Apr 2011 20:21:20 -0400

Mach,

We welcome a new draft, but IMHO as-is this document is not ready to
become a WG document.  Having identified a real problem is not by
itself sufficient to make something a standards track WG document.

The discussion shows interest but also shows that the holes in the
proposed solution are still too big for this to be a WG doc.

Curtis

In message <[email-masked]>
Mach Chen writes:
> Please note that this is not a WG last call :-)  the draft is still
> working in progress, and we'd appreciate that could give suggestion
> and advice!
>
> Section 3 of the draft does describe the usage of the PW to LSP
> Binding TLVs, they are carried in the LDP Mapping message for
> associating tunnel selection and binding when signaling a PW, the
> current version of this draft defines how to communicate tunnel LSP
> selection and binding at the initiation of a PW. Regarding Curtis's
> comments, it's about dynamic changing the tunnel LSP (whatever for
> FRR, reroute or protection switching) after a PW established, the
> authors are working on a revision to resolve the this. And suggestions
> are welcomed!
>
> >
> As Greg pointed out , this is about the extension to the control plane
> of PW and LDP is it, and MPLS-TP may run with control plane.
>
> In addition, this mechanisms defined in this document is not only for
> MPLS-TP network, but could be applied to any other scenarios where
> require both directions of a PW having congruent paths.
>
>
> Best regards,
> Mach

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Apr 2011 20:29:40 -0400

In message <[email-masked]>
Yaakov Stein writes:
> I answered it by saying that simply forcing placement of a PW into the
> appropriate LSP solves the problem. (Meaning that I do not want more
> complex PW-specific methods.)
>  
> I purposely did not state whether the particular LDP mechanism
> proposed is optimal or even correct.  This is not a LC, it is just a
> motion to move this to WG status.
>  
> Y(J)S

Yaakov,

Putting the PW into the right LSP solves the problem for SS-PW and for
the first hop of a MS-PW, but not for the middle hops of MS-PW.

OTOH, this proposal also does not solve the mid-segment problem for
MS-PW since it does not specify selection criteria to select a tunnel
at the S-PE.

The practical reality is that a PW needs configuration at both ends.
At one end it needs at the very least an admission control statement
of some sort and that could direct traffic to the right LSP.  If you
consider that this solves the far end problem and the draft doesn't
solve the MS-PW problem, then the draft adds nothing of use in its
current form.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Apr 2011 20:48:22 -0400

In message <[email-masked]>
Mach Chen writes:
>  
> Hi Yaakov and Luca,
>  
> I think Section 5.3.2. "Support for Explicit Control of PW-to-LSP
> Binding" of
> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-cp-framework-06
> could answer the question #2.
>  
> Best regards,
> Mach

Luca's question #2 was "is this the right solution?"

So mpls-tp-cp-framework does not answer that question.

Curtis

> > appropriate LSP

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 17 Apr 2011 06:14:10 +0000

Curtis
> the first hop of a MS-PW, but not for the middle hops of MS-PW.

Yes, I agree.  I must admit that I was not thinking about MS-PWs when I voiced my support.

But how can the general MS-PW case be handled ?
Assuming transit service providers to be reticent about revealing topology information, 
we need for the entity setting up the PW to request co-routed LSPs from each transit domain.
The problem then reduces to routing the PW through the S-PEs that terminate these LSPs,
and ensuring that at the S-PEs the PW is properly placed.

An interesting problem arises if we want S-PE redundancy.
We would need to trigger simultaneous switchovers in both directions.

It would seem that the MS case would be more easily handled by management operations.

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 17 Apr 2011 06:16:23 +0000

and if the reference was to my question #1 (is it in the scope of PWE3?)
I don't think a CCAMP document can provide an answer.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, April 16, 2011 03:48
To: Mach Chen
Cc: Yaakov Stein; Luca Martini; [email-masked]
Subject: Re: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt 

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 19 Apr 2011 01:20:20 -0400

In message <[email-masked]>
Yaakov Stein writes:
> But how can the general MS-PW case be handled ?  Assuming transit
> service providers to be reticent about revealing topology information,
> we need for the entity setting up the PW to request co-routed LSPs
> from each transit domain.  The problem then reduces to routing the PW
> through the S-PEs that terminate these LSPs, and ensuring that at the
> S-PEs the PW is properly placed.
>  
> An interesting problem arises if we want S-PE redundancy.  We would
> need to trigger simultaneous switchovers in both directions.
>  

Yaakov,

Late response..

For the MS-PW case the only real solution is to either 1) put criteria
for selection of a tunnel in the PW signaling, or 2) put in the tunnel
ID (which is normally a configured tunnel identifier for a TE LSP) and
use whatever LSP that tunnel is using.

For dymanic routing the tunnel should be using the best route
available at the time for the parameters configured on the tunnel.
The second method is a lot simpler.

If you needed dynamic PW switchover, you'd need to use something like
the XRO object in the MS-PW signaling so that the working and protect
PW did not take a common S-PE or LSP path through the network.

My understanding is that MS-PW redundancy is T-PE to T-PE and is
mostly to protect against failure on the AC side of the PW, with LSP
protection dealing with a fault along the way.

At some point you begin to duplicate IGP-TE and RSVP-TE in T-LDP.
Sort of like duplicating some of it in TP OAM (for no good technical
reason IMHO).

Curtis

---

From: [email-masked]
Date: Wed, 20 Apr 2011 16:54:24 +0800

Hi curtis, 

see in line[Fei]

Curtis Villamizar <[email-masked]> 
发件人:  [email-masked]
2011-04-19 13:20
请答复 给
[email-masked]

收件人
Yaakov Stein <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, Luca Martini <[email-masked]>
主题
Re: [PWE3] PWE3 working group poll for 
draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt

Yaakov,

Late response..

[Fei] This let me consider another related question, why not introdcue the 
Record Route TLV
in the PW signaling since the Explicit Route TLV has been introduced in 
the
document 
http://tools.ietf.org/html/draft-ietf-pwe3-dynamic-ms-pw-13#section-6.2.4.

As described in http://tools.ietf.org/html/rfc3212#section-4.7.4, LSP ID 
could be a sub-TLV
of Explicit Route TLV, which can be used in the Record Route TLV also.

If the Record Route TLV can be reused in SS-PW or MS-PW, PW-to-LSP binding 
can be realized 
easily and the solution is scalable also.

[Fei] Yeah, it is a simpler solution, but if two or more LSPs are working 
LSPs under
the same tunnel (for example, in the scenarios of ECMP), how to guarantee 
the same 
selection of the LSP ID? 

Curtis

---

From: Mach Chen <[email-masked]>
Date: Wed, 20 Apr 2011 09:59:29 +0000

Hi Fei,

Please see inline...

> in the PW signaling since the Explicit Route TLV has been introduced in the
> document
> As described in http://tools.ietf.org/html/rfc3212#section-4.7.4, LSP ID could
> be a sub-TLV

If the originating PE or the operator have the tunnels information, explicitly specifying the Tunnel LSPs is a candidate solution, there were some off-line discussions about this. Defining a new TLV or reusing the existing TLV is easy, the difficult for this method is that the originating PE is hard or even impossible to know the information of the middle tunnel LSPs. 

BTW, RFC3212 has already been abandoned by IETF for years.

> [Fei] Yeah, it is a simpler solution, but if two or more LSPs are working LSPs
> under
> the same tunnel (for example, in the scenarios of ECMP), how to guarantee the
> same
> selection of the LSP ID?

This is why the current draft includes LSP ID in the PW to LSP Binding TLV. 

Although primary/standby is the most usage, I am not sure whether there are requirements or deployments about multiple working LSPs for load balancing/ECMP. 

Best regards,
Mach

---

From: [email-masked]
Date: Wed, 20 Apr 2011 22:07:44 +0800

Hi Mach

see in line [Fei]

If the originating PE or the operator have the tunnels information, 
explicitly specifying the Tunnel LSPs is a candidate solution, there were 
some off-line discussions about this. Defining a new TLV or reusing the 
existing TLV is easy, the difficult for this method is that the 
originating PE is hard or even impossible to know the information of the 
middle tunnel LSPs.

[Fei] I think you did not catch my idea clearly. the Record Route TLV is 
used to record the LSP ID or interface ID that the PW passes; like the 
usage of RRO object in RSVP-TE.
      So, there is no need for the originating PE to know the information 
of the middle tunnel LSPs at the starting time. 

[Fei] Yeah, but IMHO, the existing TLV can be reused if it is possible.

B.R.

Fei

Mach Chen <[email-masked]> 
2011-04-20 17:59

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, Yaakov Stein <[email-masked]>, Luca Martini 
<[email-masked]>, "[email-masked]" <[email-masked]>
主题
RE: [PWE3] PWE3 working group poll for 
draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt

Hi Fei,

Please see inline...

the
> As described in http://tools.ietf.org/html/rfc3212#section-4.7.4, LSP ID 
could
> easily and the solution is scalable also.

If the originating PE or the operator have the tunnels information, 
explicitly specifying the Tunnel LSPs is a candidate solution, there were 
some off-line discussions about this. Defining a new TLV or reusing the 
existing TLV is easy, the difficult for this method is that the 
originating PE is hard or even impossible to know the information of the 
middle tunnel LSPs. 

> the same tunnel (for example, in the scenarios of ECMP), how to 
guarantee the

This is why the current draft includes LSP ID in the PW to LSP Binding 
TLV. 

Although primary/standby is the most usage, I am not sure whether there 
are requirements or deployments about multiple working LSPs for load 
balancing/ECMP. 

Best regards,
Mach

---

From: Luca Martini <[email-masked]>
Date: Wed, 20 Apr 2011 10:37:48 -0600

On 04/20/11 02:54, [email-masked] wrote:
>
> Hi curtis,
>
> see in line[Fei]
>
>
> *Curtis Villamizar <[email-masked]>*
> ·¢¼þÈË:  [email-masked]
>
> 2011-04-19 13:20
> Çë´ð¸´ ¸ø
> [email-masked]
>
>
> 	
> ÊÕ¼þÈË
> ³ËÍ
> Ö÷Ìâ
> [Fei]This let me consider another related question, why not introdcue
> the Record Route TLV
> As described in http://tools.ietf.org/html/rfc3212#section-4.7.4, LSP
> ID could be a sub-TLV
> If the Record Route TLV can be reused in SS-PW or MS-PW, PW-to-LSP
> binding can be realized
No. That Explicit Path TLV has nothing to do with the underling PSN.
It simply selects the S-PEs that should be traversed, by overriding the
normal PW routing table look up procedures.

> [Fei]Yeah, it is a simpler solution, but if two or more LSPs are
> working LSPs under
> the same tunnel (for example, in the scenarios of ECMP), how to
> guarantee the same
> selection of the LSP ID?   
>
I believe that the best way to solve this problem is to force a PW to
select a specific bi-directional LSP.
In the case of MS-PW this process needs to be repeated at each S-PE.
As Curtis suggested , we can add a "PSN Tunnel Profile TLV"  to the LDP
signaling to indicate to each S-PE what kind of PSN tunnel is needed.
Then we would need a "PSN traversed tunnel list TLV" to make sure that
the reverse path ( for the PW) uses the exact same set of PSN tunnels.
What needs to be well thought out, is how to handle all the corner cases
when an initial failure occurs , and when something goes wrong in a
middle segment of a working MS-PW.

Luca

---

From: Luca Martini <[email-masked]>
Date: Wed, 20 Apr 2011 16:12:49 -0600

On 04/20/2011 02:54 AM, [email-masked] wrote:
Cut....
> of Explicit Route TLV, which can be used in the Record Route TLV also.
Because the functionality is already there. In the S-PE TLV.
Again note that none of this information applies to the PSN tunnel.
Luca

---

From: Luca Martini <[email-masked]>
Date: Wed, 20 Apr 2011 16:18:27 -0600

> "...MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for Pseudowires (PWs)..."
Mach,
The point is not about running LDP over an MPLS-TP LSP. Today you simply
cannot control or provision an MPLS-TP LSP using LDP. You can Provision
a PW using LDP, but not an MPLS-TP LSP.

There are several ways to run LDP over an MPLS -TP LSP, as well, but I
cannot find an explicit indication of a standard way.

In any case the problem you are proposing is not specific to MPLS-TP, so
solution must be general enough to apply to MPLS.

Luca

---

From: Luca Martini <[email-masked]>
Date: Wed, 20 Apr 2011 18:16:39 -0600

> just fine
really ?
what if there is no GMPLS control plane ?
There are several ways to run IP across a mpls-TP LSP , how are folks
going to pick the same method ?

Since in LDP you must target an IP address , how do you know what IP
address to target to reach the end of an LSP ? or the opposite: given an
IP address which LSP gets you there ?

Of course you can configure everything manually, but then what is the
value of running LDP ?

The one liner in that GMPLS RFC does not address these problems when we
have an MPLS-TP network.
Or Am I missing some other document ?

Luca

---

From: [email-masked]
Date: Thu, 21 Apr 2011 08:42:03 +0800

Hi Luca

see in line[Fei]

Best regards

Fei

Luca Martini <[email-masked]> 
2011-04-21 06:12

收件人
[email-masked]
抄送
[email-masked], "[email-masked]" <[email-masked]>, [email-masked], 
Yaakov Stein <[email-masked]>, Thomas Nadeau <[email-masked]>
主题
Re: [PWE3] PWE3 working group poll for 
draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt

[Fei] Yeah, S-PE TLV and Explicit Route TLV have been introduced in the 
doucment http://tools.ietf.org/html/rfc6073
and 
http://tools.ietf.org/html/draft-ietf-pwe3-dynamic-ms-pw-13#section-6.2.4.
The record route was not introuced in the document 
http://tools.ietf.org/html/rfc3212, but it is useful. If it can be
introduced in the document 
http://tools.ietf.org/html/draft-ietf-pwe3-dynamic-ms-pw-13, "PSN Tunnel 
Profile TLV" can be one of it's sub-TLV, just
like LSPID TLV (0x0821) is one sub-TLV of the Explicit Route TLV.
In this way, the solution is applicable to MPLS and MPLS-TP.

---

From: Mach Chen <[email-masked]>
Date: Thu, 21 Apr 2011 01:55:53 +0000

Hi Fei,

Thanks for your response!

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 20, 2011 10:08 PM
To: Mach Chen
Cc: [email-masked]; Luca Martini; [email-masked]; [email-masked]; Yaakov Stein
Subject: 答复: RE: [PWE3] PWE3 working group poll for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-02.txt

Hi Mach

see in line [Fei]

[Fei] I think you did not catch my idea clearly. the Record Route TLV is used to record the LSP ID or interface ID that the PW passes; like the usage of RRO object in RSVP-TE.
      So, there is no need for the originating PE to know the information of the middle tunnel LSPs at the starting time.
[Mach] Yes, there need a mechanism to record the Traversed Tunnel LSPs(just as Luca suggested).

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Thu, 21 Apr 2011 02:10:52 +0000

Hi Luca, Fei,

Thanks for the suggestions comments!

> middle segment of a working MS-PW.

It sounds reasonable!

There are similar off-line discussions and ideas, we are working on a update to solve the issues in question.

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Thu, 21 Apr 2011 02:18:17 +0000

Hi Luca,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Luca Martini
> Sent: Thursday, April 21, 2011 6:18 AM
> To: Mach Chen
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls] Whether T-LDP is part of the MPLS-TP control plane
> 
> 
> > IMHO, this is not right, according to Section 4.4.1 of RFC5921, there is figure
> about "MPLS-TP layer boundary", it shows that PW belongs to MPLS-TP layer.
> >
> (http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-cp-framework-06), it says:

But noting that we are talking about whether LDP is "PART" of the MPLS-TP control plane :-)

> solution must be general enough to apply to MPLS.

Agree!

Best regards,
Mach

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

---

From: Francesco Fondelli <[email-masked]>
Date: Thu, 21 Apr 2011 11:32:49 +0200

Hi,

> what if there is no GMPLS control plane ?

MPLS-TP ctrl plane := GMPLS + RFC 4447, in case no GMPLS I guess no
4447 too.  However I see no restrictions in running a mixed network:
a) GMPLS and no PW signaling (manual PW conf), b) PW signaling and no
GMPLS (manual LSP conf) [well 'manual' actually means NMS].

> going to pick the same method ?

Implement everything that is in RFC 5718 and in ITU-T G.7712, or if
you go for a subset make sure your customers are fine with that subset
:-)

> IP address which LSP gets you there ?

A RSVP Notify message may be targeted too and reaches its destination
even in a SONET/SDH network... and for sure there is no IP in the
SONET/SDH data plane :-)

In case control plane is present (with either one of the ingredients:
GMPLS or LDP for PW) you MUST have IP!  Perhaps some weird form of IP,
tunneled/abused but... it's IP.  On such a network, in case you
need/want, you can establish a LDP targeted session between the tunnel
head end and the tail end (automatically or manually).

> Of course you can configure everything manually, but then what is the

agree, however once the session is up you get all PW LDP features

> The one liner in that GMPLS RFC does not address these problems when we

Partially agree.  IMHO ramifications of the usage of LDP (targ session
for PW signaling) within the context of a GMPLS controlled network
(i.e. MPLS-TP) should be discussed somewhere (mpls-tp control plane
draft?) in details.  However what's in this email comes from the GMPLS
framework.

> Or Am I missing some other document ?

I found http://tools.ietf.org/search/rfc4990 enlightening (think LDP
for PW running in a "native control plane" as described in Section
7.1.1).

> Luca

thanks
Ciao
FF