Subject: Re: [PWE3] GAL above and below the PW label

From: Curtis Villamizar <[email-masked]>
Date: Mon, 04 Apr 2011 19:48:14 -0400

In message <AANLkTi=[email-masked]>
venkatesan mahalingam writes:
>  
> Hi,
>  
> >> > You don't want ECMP to hash on PW payload.  With CW and without
> >> > fat-pw, you don't get ECMP on a PW but you do get ECMP on an LSP
> >> > containing many PW.
> >>
> >> When the PW payload is IP, the hashing it for ECMP is useful (If the
> >> payload is not IP then use CW). FAT-PW may not be present in all
> >> deployments.
> >
> > I really don't know that any PW are carrying IP.  That was not in the
> > survey.  L3VPN would be carrying IP.
>  
> Why are we very much concerned about the ECMP in MPLS-TP networks?

Because some of us are realists.

> I think, as per the RFC-5960,
>  
>    Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed on
>    an MPLS-TP LSP.

That is all fine and well.  The case that is being discussed is an
expected common case with an MS-PW where a MPLS-TP LSP in the access
tier on one side, one or more MPLS LSP is traversed in the regional or
core tier, and an MPLS-TP may be traversed in the access tier on the
other side.

In both MPLS-TP LSP there may be no need for multipath (for example
LAG or link bundle).  In the core LAG or link bundle may be essential,
but there LSP are MPLS, not MPLS-TP.

> Thanks,
> Venkat.
> Re: [PWE3] GAL above and below the PW label

Curtis

---

From: <[email-masked]>
Date: Tue, 5 Apr 2011 08:37:01 +0100

Curtis,

You wrote 05 April 2011 00:48 to Venkat:

> To: venkatesan mahalingam
> Cc: [email-masked]
> Subject: Re: [PWE3] GAL above and below the PW label
> 
> 

I don't understand your point here and why you are saying Venkat is wrong and (in particular) 'not being realistic'.  

The key point is this:  Why should the 2 outer MPLS-TP layer network partitions care (or even know) what is happening in the core MPLS layer partition wrt ECMP (or any other transparency violation) behaviour? 

If you don't get this instantly try this architecturally identical alternative case:  Consider an IP layer network where each link connection is served by a different server layer network technology X, Y, Z, etc, and in the most general case each may be owned by a different party.  Why should the server layer technology partition X care (or even know about) what any other server layer technology partition Y, Z, etc is doing here across the whole span of the client IP layer network?

Hopefully it should be quite clear that:
(i) each server layer technology partition must be independent of any other server layer technology partition, 
(ii) they all must form a pukka client/server relationship with the common IP layer client, and (in particular)
(ii) carry it transparently..else the owner of the IP layer client would not be very happy ;-)

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

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

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 05 Apr 2011 16:20:53 -0400

Neil,

draft-villamizar-mpls-tp-multipath describes how an underlying MPLS
layer using multipath (LAG or link bundle) can carry MPLS-TP LSPs
without a "transparency violation" as you put it.

Curtis

In message <[email-masked]>
[email-masked] writes:

Curtis,

regards, Neil

---

From: <[email-masked]>
Date: Wed, 6 Apr 2011 08:03:42 +0100

Thanks Curtis,
You said 05 April 2011 21:21:

> To: Harrison,N,Neil,DKQ7 R
> Cc: [email-masked]; [email-masked]; [email-masked]

NH=> This is not relevant to the technical correction I provided.  I was making it clear that:

-	 there must be a functionally decoupled relationship between the MS PW layer network and each of its of underlying MPLS server layer networks in the example given (which becomes crystal clear in the case each of these MPLS networks being owned by a different operating party)...also see my related mail to Ben (Niven-Jenkins) of a day or so earlier that he has unfortunately not been able to respond to yet.... and

-	an immediate consequence of this (though this is a quite general networking case, as I showed with the IP layer network example in the mail below) is that there is no functional coupling/relationship (or even knowledge of existence) between each of the MPLS server layer networks.

You surely cannot disagree with any of the above.

Aside=> If MPLS-TP is serious about assuming a transport service mantle it must be able to provide a pukka client/server case of MPLS-TP_over_MPLS-TP.  This is merely the above situation re-cast.  And BTW this is (one reason) why traditional LSP sublayering and proper LSP layering do not sit as easy bedfellows and thus why one now has to take some action to make this demarc clear and efficient in the traffic DP (I am aware of one manufacturer who has recognised this point).  Also note that when we have proper layering as we will need in a transport networking role then one will need to consider both intra-layer and inter-layer misconnectivity.

I will try and find time to look at your draft (thanks for the pointer), but as I hope you can see this is not relevant to the above.  

regards, Neil
BT Design

> > >    Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be
> performed
> > on
> > >    an MPLS-TP LSP.
> >
> I don't understand your point here and why you are saying Venkat is
> wrong and (in particular) 'not being realistic'.
> 
> The key point is this:  Why should the 2 outer MPLS-TP layer network
> partitions care (or even know) what is happening in the core MPLS layer
> partition wrt ECMP (or any other transparency violation) behaviour?
> 
> If you don't get this instantly try this architecturally identical
> alternative case:  Consider an IP layer network where each link
> connection is served by a different server layer network technology X,
> Y, Z, etc, and in the most general case each may be owned by a
> different party.  Why should the server layer technology partition X
> care (or even know about) what any other server layer technology
> partition Y, Z, etc is doing here across the whole span of the client
> IP layer network?
> 
> (ii) they all must form a pukka client/server relationship with the
> common IP layer client, and (in particular)

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 07 Apr 2011 11:53:42 -0400

Neil,

Going back to the example.  If each network is owned by a separate
party we have:

  PW - fat-pw is used, therefore owner of PW label is OK with load
  split and indicates how to do so.

  MPLS-TP segment carrying MS-PW segment: ignores label stack except
  top lagel and uses no multipath of any kind and does no hash and no
  load balance.

  MPLS segment carrying MS-PW segment: may make use of information
  provided in fat-pw label to distribute traffic among components of a
  multipath where it is necessary or convenient to use multipath.

There is no layering problem here.  There is no violation of MPLS-TP
fate sharing.  Things work as each owner of a given layer intends it
to work.  Use of MPLS-TP on the edge/access has no issues.

Aside in response to your aside => a case for MPLS over MPLS can be
found in RFC 5439 "An Analysis of Scaling Issues in MPLS-TE Core
Networks".  The two recommendations to acheive scalability are LDP (to
make use of multipoint to point LSP) and hierarchy.  With hierarchy
the LSP become greater than 100Gb/s in large networks and that
requires multipath.  Both recommendations for scalability are
therefore not applicable to MPLS-TP in large networks.  Conclusion:
MPLS-TP won't scale; use MPLS in the core.

Now back to our previous discussion about whether we can relax the
requirement to have GAL at the bottom of stack (which is the part of
the stack that PWE people draw on top :).

Curtis

In message <[email-masked]>
[email-masked] writes:

Thanks Curtis,

regards, Neil
BT Design