Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

From: <[email-masked]>
Date: Fri, 31 Aug 2007 22:20:41 +0100

Thanks Andy,
 
I think we should be a little careful here.  Let's not forget why we have PWs, ie MPLS is not natively multiprotocol in practice...it has a special relationship with IP and nested MPLS LSP clients that do not extend to 'other clients'.....ergo the need to generate PWs in the 1st place.  I believe, if I recall correctly, you also argued for a PID field in MPLS to make it truly 'multiprotocol' in the past.  So, since this never happened, PWs are now all about coping with non IP or non MPLS layer clients....and once they go multi-hop such PW entities take on (for better or worse, though actually for worse) the requirements of a layer network (co-ps mode) in their own right.  That is simply just a recap of arch history here.
 
But even this is not strictly/completely accurate.  In the case of nested LSPs we also do not have consistent characteristic information wrt to the MPLS header...specifically the label does not carry consistent semantics......indeed, a key behaviour is that only the outer header carries a networked/forwarding semantic and the inner labels take on other semantics (depends on use case, but demerging due to use of LDP is a key one here).  Having inconsistent characteristic information is not a good idea, but nevertheless this is now how it is.
 
In the problem statement here however, we wish to carry the MPLS layer network (ignoring label semantics) of one party transparently over the MPLS network of another party.
 
Now we have 3 options as I see it (given MPLS as-is):
-    select a given technology X to act as a functional breakwater.....this is essentially what the current draft has, with ethernet as the selected technology;
-    create a 'MPLS PW'....which as I understand it is what you are arguing for...which needs a new MPLS PW defining (something I postulated for consideration over a year ago on this list);
-    sidestep the PW issue altogether and look for a way of carrying MPLS over MPLS....which is what a reserved label would offer.
 
Depends what is important as to which is considered best.  The key thing to me here is the recognition of the importance of a proper client/server relationship and (hopefully) just how important 'transparency' is as a requirement here....all these methods can indeed provide this.
 
However what we can't duck is this point:  If the characteristic information of an LSP (noting in particular this also includes its OAM) is NOT consistent then any misconnectivity between LSPs will lead to misinterpretation of the meaning of header functional semantics (and the associated OAM).  Now, because the label field of LSPs is NOT consistent wrt semantics this means that under misconnectivity we can't expect correct interpretation of the label field.  This is a problem.  However, it can be mitigated IFF the OAM that is associated with EVERY LSP is consistent.  Now the OAM for 'true' MPLS LSPs is not the same as the OAM for PWs....indeed, the OAM for PWs (the so-called VCCV OAM) is ONLY relevant to PWs and not 'normal' MPLS LSPs.  Problem.  Indeed there is no simple/easy way out for this.
 
We could make PW OAM generic, which favours your proposal of a MPLS PW....in which case what do we do about OAM on 'normal' non-PW LSPs?....this really ought to be the same on ALL LSPs, else what happens if a PW LSP gets misconnected with a normal MPLS LSP?....how is the OAM interpreted here?
 
Or, we could ignore PWs (and their OAM) altogether and just look at MPLS over MPLS, which is what we have with a reserved label approach.  However, I still recognise this still does not solve the fact that on 'normal' MPLS LSPs and PW LSPs the OAM is different...so what happens under misconnectivity between the 2 types of LSP?
 
There is now, unfortunately, no easy answer...we simply don't (and won't) have consistent MPLS characteristic information.  So take your choice but be aware of this limitation/issue.  For me (BT) it is the recognition for transparency and a proper client/server relationship that is key.  Any of the methods will provide this, though none provide the ideal.
 
regards, Neil

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]] 
Sent: 31 August 2007 19:42
To: Harrison,N,Neil,JCGA1 R
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

Neil,

Yes, that could also work, but we would need to specify the signaling and OAM when such a reserved label is used. 

For an MPLS PW, life would be simpler, since we've already defined the signaling (RFC 4447) and OAM (VCCV).
 
Cheers,
Andy

At 8/31/2007 07:10 PM +0100, [email-masked] wrote:

Hi Andy,
 
So, to be clear here, are you suggesting we need to define a 'MPLS PW'?
 
An alternative solution would be to use a reserved label that carries the semantic 'this delimits stacked LSPs from 2 different MPLS layer networks'.  This would not require a PW at all, can be efficiently recursed, and allows the (*server*) interconnecting technologies between the 2 MPLS networks to be of any type.
 
regards, Neil

-----Original Message-----

From: Andrew G. Malis [ mailto:[email-masked] <mailto:[email-masked]> ] 

Sent: 31 August 2007 18:49

To: [email-masked]

Cc: George Swallow (swallow); Yaakov Stein; [email-masked]; Danny McPherson

Subject: Re: [PWE3] WG LC: draft-ietf-pwe3-mpls-transport-00.txt

Like some of the other folks that have responded on this list, while in general I'm in support of the draft, I am concerned with the overhead added by the use of an Ethernet layer between the two MPLS label stacks, and don't see enough benefit to offset the overhead.  I would much prefer two label stacks separated by a control word.

Unless this is going to be restricted to be only used as shown in Figure 1, in conjunction with physical Ethernet ports, thus justifying the use of the Ethernet layer in the protocol stack.  But that seems awfully restrictive, and I don't recall any ITU-T requirements that would restrict this to Ethernet ports.  Thus, I've adapted figure 1 a bit from the draft:

+----------------------------------------------------------------+

|                                                                |

|                  IP/MPLS PSN (PHP may be enabled)              |

|                                                                |

|                  +---------------------------+                 |

|                  |                           |                 |

|                  |      MPLS PSN (No PHP)    |                 |

|                  |                           |                 |

|     CE1          |PE1                     PE2|           CE2   |

|   +-----+      +-----+                   +-----+      +-----+  |

|   | | | |      | | | |                   | | | |      | | | |  |

|   | | | +------+ | | |                   | | | +------+ | | |  |

|   | | | |      | | | |                   | | | |      | | | |  |

|   +-----+      +-----+                   +-----+      +-----+  |

|     |            |  |                      | |            |    |

|     |            +-- ---------------------- -+            |    |

+----- --- -------- -- ---------------------- - -------- --- ----+

      |            |  |<--MPLS PSN (no PHP)->| |            |

      |            |                           |            |

      |            |<-------MPLS PW----------->|            |

      |                                                     |

      |                                                     |

      |                                                     |

      |<---------IP/MPLS LSP (PHP may be supported)-------->|

I've just made the links between CEs and PEs to be general way to pass MPLS frames. Whatever physical interface type is used (Ethernet, PoS, etc.) would be terminated and the encapsulation would be stripped at entry to each PE, and re-added at each PE exit. There would be less overhead on the wire, and dissimilar physical interfaces could be used at each end.

We would need to specify an MPLS PW, but that would be pretty trivial.

Cheers,

Andy

At 8/31/2007 05:10 PM +0100, Stewart Bryant wrote:

Yaakov Stein wrote:

Danny and Stewart,

While definitely in favor of this ideas behind this draft,

I have a hard time with a lot of the wording.

First, the Abstract and Introduction describe the problem

to be solved as transport (AKA as "carriage") of MPLS

over MPLS. Specifically, the Introduction explains that direct

transport of one carrier´s MPLS traffic over another carrier´s MPLS

network can not be done by simple label stacking, and so a PW

is required.

But then there is a sharp turn and the rest of the draft is about

transport of Ethernet over MPLS, not MPLS over MPLS.

Some explanation is required here (other than the fact that

the PWE charter disallows MPLS PWs over MPLS),

or the Introduction should be reworded.

I have re-written the abstract and intro, and will post the proposed

alternate by COB today.

Second, the text mentions in second places that the draft

defines a "profile". It is not clear a profile of what.

At first I though it was a profile of RFC4448, and section 5 says this as well.

But then I found the sentence

  The only PWE3 encapsulation that is supported in this version of the

   profile is Ethernet RFC4448 [RFC4448].

So, if RFC4448 is used in the profile, it must be a profile of something else.

So is it a profile of MPLS? Or maybe a profile of RFC3985 ?

In any case, although profiles are used in many standards bodies,

we have never discussed profiles before. Is this term really needed?

Profile is the term that ITU used in its T-MPLS and we propagated the

term into this draft without really thinking about the implications.

I have taken a look at each use of the term and tried to replace with

suitable alternative working. I am a bit concerned that this is less

concise, but let's see. We can always go back.

The one case I left it in was VCCV, where it seemed to fit OK.

If so, please explain it.

Third, a number of constraints are put on this PW. For example,

PHP must not be used in the underlying network,

the PWE control protocol MUST NOT be used, VCCV modes, configuration,

and the fact that the CW MUST be used.

Although these are in response to the referenced ITU requests,

these liaisons are ephemeral. I think specific explanations of why these constraints

are being enforced is absolutely required, in addition to being useful to the reader.

I am concerned here that by putting in a justification we risk and argument

over the validity of the design decision. As you saw we are responding

to an ITU liaison. That liaison is no more ephemeral than an RFC, it is

published on the IETF web site, and there is no current policy of deleting

them after some period of time as with drafts. The earliest liaison posted

is 1995.

Fourth, and perhaps most significant,

in several places we seem to overstepping PWE charter restrictions

by exerting control over the underlying PSN and specifying placement of the PSN tunnel.

For example, PHP MUST NOT be used, RSVP-TE MUST be used,

no label merging, no ECMP, etc.  Perhaps this needs to be a joint PWE and MPLS WG draft?

We are not changing MPLS technology, simply specifying usage of a subset of

that technology in that application, and certainly both MPLS chairs are aware

of this draft one commented, the other is an author.

Perhaps George or Loa, could comment on whether that would like Danny

to request an MPLS WG review of this document.

- Stewart

_______________________________________________

pwe3 mailing list

[email-masked]

https://www1.ietf.org/mailman/listinfo/pwe3

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