Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt

From: Mach Chen <[email-masked]>
Date: Tue, 05 Jul 2011 01:41:02 +0000

Hi,

We submitted an update for the explicit PW to PSN binding draft( http://tools.ietf.org/id/draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt ), which is mainly based on the comments received during the polling. We'd appreciate that you could review the draft and give your comments!

Many thanks,
Mach 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 28, 2011 5:49 PM
> To: Mach Chen
> Cc: [email-masked]; [email-masked]; Mach Chen; Wayne
> Cao(wei)
> Subject: New Version Notification for
> draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt
> 
> A new version of I-D, draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt has been
> successfully submitted by Mach(Guoyi) Chen and posted to the IETF repository.
> 
> Filename:	 draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp
> Revision:	 03
> Title:		 LDP extensions for Explicit Pseudowire to transport LSP
> mapping
> Creation date:	 2011-06-28
> WG ID:		 Individual Submission
> Number of pages: 16
> 
> Abstract:
>    A bidirectional Pseudowire (PW) service currently uses two
>    unidirectional PWs each carried over a unidirectional LSP.  Each end
>    point of a PW or segment of multi-segment PW (MS-PW) independently
>    selects the LSP to use to carry the PW for which it is the head end.
> 
>    Some transport services may require that bidirectional PW traffic
>    follows the same paths through the network in both directions.
>    Therefore, PWs may be required to use LSP with congruent paths.
>    Bidirectional LSPs or co-routed associated unidirectional LSPs allow
>    this service to be provided.
> 
>    This document specifies an optional extension to LDP that allows both
>    ends of a PW (or segment of a MS-PW) to select and bind to the same
>    bidirectional LSP (or co-routed unidirectional LSPs).
> 
> 
> 
> 
> 
> The IETF Secretariat

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 14 Jul 2011 08:44:55 -0400

In message <[email-masked]>
Mach Chen writes:
>  
> Hi,
>  
> We submitted an update for the explicit PW to PSN binding draft(
> http://tools.ietf.org/id/draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt
> ), which is mainly based on the comments received during the
> polling. We'd appreciate that you could review the draft and give your
> comments!
>  
> Many thanks,
> Mach 

Mach,

This draft has more information but it has the same problem I pointed
out in the -02 version.

The LSP is identified, not the tunnel.  The tunnel should be
identified.  In a make-before-break reroute the tunnel remains
constant but the LSP changes.

When an LSP reroutes for whatever reason, it may be carrying a large
number of PW.  After the make-before-break reroute completes, the old
LSP no longer exists.  It should not be necessary to resignal the PW
to reroute the LSP.  With the text you have, using the LSP numbers,
that reroute of all the carried PW would be necessary.

There is only one active LSP for any given tunnel.  How the active LSP
is identified, relative to any other LSP is out of scope for this
document.  There may be a working and protect or a working and protect
and new working and a new protect during a make-before-break
transition.  The IP traffic on an LSP and all LSP carried by a
hierarchical LSP automatically move during a make-before-break
reroute.  The PW should also move without any additional and totally
unecessare signaling.

Curtis

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

---

From: Ping Pan <[email-masked]>
Date: Thu, 14 Jul 2011 06:38:25 -0700

On Thu, Jul 14, 2011 at 5:44 AM, Curtis Villamizar <[email-masked]> wrote:

>
> In message <
> [email-masked]>
> Mach Chen writes:
> >
> > Hi,
> >
In this version, we have explicitly made changes on all the issues being
brought up since last time, specifically, in signaling MHOP PW's, and
passing information on mapping PW's to co-routed LSP's. The consideration
for signaling Tunnel vs. LSP has also been considered in Section 2.1.1.

The idea is to enable a PE informing anther PE on PW-LSP mapping in terms
of:

1. if they are co-routed
2. if the mapping is mandatory or requires further negotiation
3. the identification of the underlying LSP's, (could be a tunnel or an
explicit LSP)

> that reroute of all the carried PW would be necessary.
If reroute is a frequent event in a network, the operator can use T-flag
(Section 2.1) to negotiate LSP's on TunnelID only.

> reroute.  The PW should also move without any additional and totally
In case of FRR, traffic is only going over ONE tunnel at any give time, may
that be active or protection. So there is no need to identify active vs.
protection for the purpose of PW-LSP binding at negotiation time.

Please elaborate your question.

Thanks!

Ping

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 14 Jul 2011 14:38:07 -0400

In message <CAHEV9L3SOLJcg0rns8RARCtHmxOS=[email-masked]>
Ping Pan writes:
> In this version, we have explicitly made changes on all the issues
> being brought up since last time, specifically, in signaling MHOP
> PW's, and passing information on mapping PW's to co-routed LSP's. The
> consideration for signaling Tunnel vs. LSP has also been considered in
> Section 2.1.1.
>  
> The idea is to enable a PE informing anther PE on PW-LSP mapping in
> terms of:
>  
> 1. if they are co-routed
> 3. the identification of the underlying LSP's, (could be a tunnel or
>    an explicit LSP)
>  
> If reroute is a frequent event in a network, the operator can use
> T-flag (Section 2.1) to negotiate LSP's on TunnelID only.

I understand the T-bit.  I think you should get rid of the T=0 case.

> In case of FRR, traffic is only going over ONE tunnel at any give
> time, may that be active or protection. So there is no need to
> identify active vs.  protection for the purpose of PW-LSP binding at
> negotiation time.
>  

In FRR the PLR and merge need not be at the ingress or egress.  The
indication the FRR protection has occurred is the Local protection in
use bit is set [RFC3209].  For FRR neither the tunnel or LSP change
during the protection in use state.  The IGP will at some point
(slight flooding delay) propogate a change in topology (the link or FA
down) to the ingress.  A new working LSP is created.  Usually all the
facilities LSPs needed are already available and so the new LSP comes
up with Local protection available bit set and Local protection in use
bit clear.  The protected LSP is preferred and that triggers the
switch.  During all this time the tunnel ID does not change but the
LSP_ID changes.

Identifying the LSP is harmful in the FRR case.  Every PW carried by the
old LSP has to be resignaled before the new LSP is put into use.
Currently this is not the case.

In the case of GMPLS path protection a different LSP is used when
protection is in use.  It would not be a good idea to require the PW
to be resignaled before protection takes effect.

Identifying the LSP is even more harmful in the GMPLS protection case.
The large number of PW carried by the LSP have to be resignaled before
the LSP protection takes effect.

---

From: Ping Pan <[email-masked]>
Date: Thu, 14 Jul 2011 13:59:00 -0700

> I understand the T-bit.  I think you should get rid of the T=0 case.
Curtis,

Actually, we have checked with some customers. Some don't subscribe the
notion that they will change the LSP from the headend, and want to have the
explicit control on binding PW's to a fixed LSP. This is why we use a bit.

> the LSP protection takes effect.
Wait. First, if a network is in constant use of FRR, we have more serious
issues. In which case, the PW-LSP binding overhead should be last thing the
operators  care about. :-)

In transport networks, especially that of GMPLS-enabled optical core, the
network is relatively stable. The configuration needs to be accurate, but
does not need to screaming fast.

However, you are right, in case of FRR, if a LSP is rerouted at the headend,
the PW-LSP binding should be seamless. This is why we have defined the T-bit
to signal Tunnel-id only.

As for MPLS path protection case, T-bit is also sufficient. The rule of
thrum is: the protecting connections in FRR use the same Session Object,
same source IP, but different LSP-id. The protecting connections in Path
Protection use the same Session Object, same LSP-id but different source IP
address. The way we define T-bit is that, map a PW to a LSP's tunnel (a.k.a.
Session) only. It works! ;-)

Thanks!

Ping

> > > > > A new version of I-D,
> > > has been

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 14 Jul 2011 17:31:28 -0400

In message <[email-masked]>
Ping Pan writes:
>  
> --20cf30563a01bd9fd504a80dcfa2
> Content-Type: text/plain; charset=ISO-8859-1
>  

Unless you are talking about statis LSPs, they always "change at the
headend".  I'm not sure which customers you are talking about but we
can take that offline.

> does not need to screaming fast.

This is not about "constant use of FRR" it is about a single event in
which more than one fault occurs.  This happens quite often.  There
may be a large number of LSP affected and a much larger number of PW
affected.

The statement "In transport networks, especially that of GMPLS-enabled
optical core, the network is relatively stable" is really nonsense in
that context.  Hurricane Katrina was the classis "network outage" but
floods, earthquakes, bridge collapses, train wrecks taking out fiber
on both side of tracks, and even errant backhoe operators removing the
wrong unused gas lines, are all among the more dramatic causes, not to
mention the many mundane outages of the same sort.  Transport is no
more reliable (due to lack of restoration in transport gear with no
control place or slow restoration in some gear, it is generally
provably less relaibel) than the same network with protection and
restoration in the IP/MPLS layers.

Anyway, it doesn't matter.  See below.

> Session) only. It works! ;-)

I feel that the T=0 is a misfeature but as long as the T=1 is there,
it becomes a "let the market decide" situation.

> Ping

I'd like to point out another topic on a separate thread.

Curtis

[ trimmed original draft announcement. ]

---

From: Mach Chen <[email-masked]>
Date: Fri, 15 Jul 2011 08:53:47 +0000

Hi Curtis,

Thanks for your comments!

As Ping said, we have changed the draft to include tunnel option and make it as the default, and at the same time, keeps the LSP option (OPTINAL) hence to give the capability for explicit binding/moving a PW to a specific LSP when needed.

Best regards,
Mach
 
> reroute.  The PW should also move without any additional and totally

There may be requirement for doing PW 

Best regards,
Mach

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Jul 2011 10:21:48 -0400

In message <[email-masked]>
Mach Chen writes:
> As Ping said, we have changed the draft to include tunnel option and
> make it as the default, and at the same time, keeps the LSP option
> (OPTINAL) hence to give the capability for explicit binding/moving a
> PW to a specific LSP when needed.
>  
> Best regards,
> Mach

Mach,

Can you cite any case where it is needed, where more than one LSP is
bound to a tunnel and it is not otherwise obvious which LSP to use.
In both the make-before-break reroute case and the GMPLS protection
case it is possible to determine which LSP to bind to.  If there is
another case where this is not true, please point it out.

Curtis

---

From: Ping Pan <[email-masked]>
Date: Fri, 15 Jul 2011 07:57:30 -0700

Curtis,

Today, there are multiple options in binding PW's to the underlying LSP's on
a local PE. Some of the policies I have seen include: random (binding PW's
to one of the multiple LSP tunnels randomly), least-fill (binding PW's to
the ones with most available BW), most-fill... etc. (I know, copying a
similar feature from Juniper). Given the current binding does not involve
any protocol change, don't think most people would notice.

Now, if we are to bind the PW's to co-routed/bi-directional LSP's, or extend
the binding policy in multi-hop PW scenarios, we'd have to make the binding
request as a part of the PW negotiation. This is the intent of the draft.

- Ping

On Fri, Jul 15, 2011 at 7:21 AM, Curtis Villamizar <[email-masked]> wrote:

>
> In message <
> [email-masked]>
> Mach Chen writes:
> >
> > Hi Curtis,
> >
> draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt has
> > > been

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Jul 2011 13:08:41 -0400

In message <[email-masked]>
Ping Pan writes:
>  
> >  
> > Curtis,
> >  
> > Today, there are multiple options in binding PW's to the underlying
> > LSP's on a local PE. Some of the policies I have seen include: random
> > (binding PW's to one of the multiple LSP tunnels randomly), least-fill
> > (binding PW's to the ones with most available BW),
> > most-fill... etc. (I know, copying a similar feature from
> > Juniper). Given the current binding does not involve any protocol
> > change, don't think most people would notice.
> >  
> > Now, if we are to bind the PW's to co-routed/bi-directional LSP's, or
> > extend the binding policy in multi-hop PW scenarios, we'd have to make
> > the binding request as a part of the PW negotiation. This is the
> > intent of the draft.
> >  
> > - Ping

If there is only one LSP per tunnel, then you still didn't answer the
question as to why the LSP_ID is needed.

I've stated very clearly why the LSP_ID is bad.  If you do
make-before-break, or swithc from working to protect in GMPLS
protection, you have to resignal all of the affected PW, where without
using LSP-ID you don't have to do that.

If you don't have a reason for more than one LSP per tunnel, then
there is no need for the LSP_ID.

The 16 bit tunnel_num is there for a reason.  It allows 64K tunnels
between any two LSR.  The LSP_ID allows more than one LSP per tunnel,
but generally it is one except during a brief transition period that
occurs in make-before-break reroute.

Curtis

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 15 Jul 2011 13:15:28 -0400

> occurs in make-before-break reroute.

	I agree with you Curtis. There are already mechanisms in place
for choosing paths for PWs in the various popular implementations that
let you nail down which path (or paths) are allowed to be chosen. This
is available for all of the applications (l3VPN, l2VPN, PWs, static)
as far as I can tell BTW.

	--Tom

---

From: Ping Pan <[email-masked]>
Date: Fri, 15 Jul 2011 10:40:25 -0700

> using LSP-ID you don't have to do that.
Then turn-on the T-flag, and get on with it.

> > > > > > > > Cc: [email-masked]; [email-masked]; Mach
> Chen;
> > > > Wayne
> > > > > > > > Cao(wei)
> > > > > > > > successfully submitted by Mach(Guoyi) Chen and posted to the
> IETF
> > > > > > repository.
> > > > > > > >
> > > > > > > >    unidirectional PWs each carried over a unidirectional LSP.
>  Each
> > > > end
> > > > > > > >    selects the LSP to use to carry the PW for which it is the
> head
> > > > end.
> > > > > > > >
> > > > > > > >    Bidirectional LSPs or co-routed associated unidirectional
> LSPs
> > > > allow
> > > > > > > >    This document specifies an optional extension to LDP that
> allows
> > > > both
> > > > > > > >    ends of a PW (or segment of a MS-PW) to select and bind to
> the
> > > > same

---

From: Ping Pan <[email-masked]>
Date: Fri, 15 Jul 2011 10:57:07 -0700

Hi,

I think we are talking over each other. ;-) Let me try to describe an
example here:

  A --- B ---- C ---- D

A and D and Ethernet CE's. B and C are PE's. Between B and C, we have a
transport network, say, GMPLS-enabled optical transport network.

There are tons of VLAN circuits between A and D, and there are multiple
optical connections (as in GMPLS LSP's) between B and C. The connections
take different path onto different fiber etc.

On B and C, each uni-directional Ethernet VLAN is mapped to a PW. And we
need to make sure of the mapping for each bi-directional Ethernet circuit
onto a bi-directional LSP.

There are two ways to go about:

1. Configure both ends
2. Do something intelligent during the setup time (as described in this
draft).

There is no make-before-break in optical network.

Now, extending it further, this apply to co-routed MPLS LSP's, And MHOP PW
needs to be addressed.

Hope this helps.

- Ping

On Fri, Jul 15, 2011 at 10:15 AM, Thomas Nadeau <[email-masked]>wrote:

> [email-masked]>
> > Ping Pan writes:
> >>
> >>>
> >>> Curtis,
> >>>

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Jul 2011 13:58:54 -0400

> Then turn-on the T-flag, and get on with it.

So the answer is that there is no use for the T=0 case, just use the
T=1 case and ignore it?

 > another case where this is not true, please point it out.

Care to answer?  So far your only answer is "Then turn-on the T-flag,
and get on with it."

Curtis

---

From: Ping Pan <[email-masked]>
Date: Fri, 15 Jul 2011 11:03:20 -0700

On Fri, Jul 15, 2011 at 10:58 AM, Curtis Villamizar <[email-masked]>wrote:

>
> In message <CAHEV9L1W8=
> [email-masked]>
> Ping Pan writes:
> >
> > > > > Curtis,
> > > > >
Curtis,

For those who have other means to protect user traffic other than FRR, they
have the option to turn T-flag off.

Is this better? ;-)

- Ping

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Jul 2011 14:53:44 -0400

In message <[email-masked]>
Ping Pan writes:
> A and D and Ethernet CE's. B and C are PE's. Between B and C, we have
> a transport network, say, GMPLS-enabled optical transport network.
>  
> There are tons of VLAN circuits between A and D, and there are
> multiple optical connections (as in GMPLS LSP's) between B and C. The
> connections take different path onto different fiber etc.
>  
> On B and C, each uni-directional Ethernet VLAN is mapped to a PW. And
> we need to make sure of the mapping for each bi-directional Ethernet
> circuit onto a bi-directional LSP.
>  
> 2. Do something intelligent during the setup time (as described in
>    this draft).
>  
> Now, extending it further, this apply to co-routed MPLS LSP's, And
> MHOP PW needs to be addressed.
>  
> Hope this helps.

Yes. it helps underscore that fact that you don't get it.

There is no need for one LSP per PW from B to C.  All of the PW can
ride within one LSP (and that is the typical case).  If there is one
LSP per PW, then there is still one LSP per tunnel.  If there is a
make-before-break reroute of B-C (assuming these are T-PE and there
are other nodes between these two) the the PW don't need to be
resignaled.

The tunnel_ID is sufficient to identify the thing that the PW needs to
map to.  That is the point that you are still not getting.

Maybe if you didn't top post without thoroughly reading the question
you are top posting over, you maight see the original question and see
what it was that Tom was agreeing with.  They are still part of this
email, though I trimmed beyond that.

Curtis

> [  ... trim ... ]

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Jul 2011 15:16:00 -0400

In message <CAHEV9L133K=L=[email-masked]>
Ping Pan writes:
> For those who have other means to protect user traffic other than FRR,
> they have the option to turn T-flag off.
>  
> Is this better? ;-)
>  
> - Ping

Please refer to RFC 4872 section 14, PROTECTION Object.

      Secondary (S): 1 bit

         When set to 1, this bit indicates that the requested LSP is a
         secondary LSP.  When set to 0 (default), it indicates that the
         requested LSP is a primary LSP.

      Protecting (P): 1 bit

         When set to 1, this bit indicates that the requested LSP is a
         protecting LSP.  When set to 0 (default), it indicates that the
         requested LSP is a working LSP.  The combination, S set to 1
         with P set to 0 is not valid.

   [ ... ]

      Operational (O): 1 bit

         When set to 1, this bit indicates that the protecting LSP is
         carrying the normal traffic after protection switching.  The O
         bit is only applicable when the P bit is set to 1, and the LSP
         Protection Type Flag is set to either 0x04 (1:N Protection with
         Extra-Traffic), or 0x08 (1+1 Unidirectional Protection) or 0x10
         (1+1 Bidirectional Protection).  The O bit MUST be set to 0 in
         any other case.

If there is a working and protect LSP it is possible to determine
which LSP is the working LSP.  It is also possible to tell when the
other end has switched over to the protect for some reason.

Do you know of a protection mechansism besides FRR and GMPLS
protection where this would not work?

If the LSPs are static, with no control plane at all, then there is
nothing to signal through and this draft has no purpose.  If there is
a control plane it is easy to determine which LSPs are working LSP and
which LSPs are used for protection.

> >  > another case where this is not true, please point it out.

Thanks for the continued replies.  If you can't answer this question,
you need to take out the T bit and only support the T=1 functionality.

Curtis

---

From: Ping Pan <[email-masked]>
Date: Fri, 15 Jul 2011 14:27:55 -0700

Curtis,

Yes. The center of the debate is if we should only represent PW's LSP with
the Tunnel-id, given information could be gathered in FRR etc. Correct?

I prefer to leave the flexibility in at this point, as there are other
protecting schemes and deployment scenarios that are not bounded to the
constraints as defined in FRR.

If you prefer, we can chat directly offline.

Ping