Subject: Local service delimiters and PWs (was: Ethernet over MPLS )

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 19 Mar 2003 11:31:15 +0200

Hi all,
I have been silently tracing this thread for some time,
and my growing feeling was that of deja vu: I have already seen these
arguments before. Only, it was not with VLAN tags - it was with 
the FR DLCIs in FR emulation and later with VPI/VCI in ATM emulation...

Having understood this, I have done some simple checking. I have found,
that, with almost every service the PWE3 has been chartered to emulate,
it has encountered, in some form, the same issue, namely how to treat the
local
service delimiters:

1. The first encounter has been with the FR DLCIs:
   o Early Martini drafts have had them (and, indeed, the entrire FR header)
     stripped, and have used the CW flags to carry DE, FECN, BECN and even 
     (usually meaningless) C/R indications across the PSN. The arguments
behind
     included BW efficiency, local significance of DLCIs, different DLCI
     dormats at the twh ends of the PW
   o These arrangements have been vehemently opposed. In particular,
     the opponents have been arguing the need for the port mode, 
     pushed for placing the DLCI swapping functionalyu into appropriate
     NSPs etc.
   o The results, as reflected in the latest WG document: 
     * 1:1 mode that strips FR headers, is mandatory and is the 
       only mode that can be used in conjunction with MPLS PSN
     * N:1 mode that carries FR headers, and is optional over IP PSN

2. The next encounter has been with ATM VPIs/VCIs:
   o Early Martini drafts suggested carrying them all the way
     over the PSN in the cell mode. This mode supported carrying
     a single VCC, a single VPC or port transparent mode
   o This arrangement has been vehemently opposed (citing BW efficiency,
     local significance etc.)
   o The results, as reflected in the latest WG document:
     * N:1 mode is mandatory
     * 1:1 modes (for VPI and VCI) are optional

3. The Ethernet tags are discussed now, with some people pressing for the
   "raw" mode and placing the VLAN tag add/remove/swap operation in the NSP,
   while other claim that this functionality is de-facto lacking in
off-the-shelf
   available NSPs and hence should be part of the PW

4. IMO the next encounter could be with structured TDM emulation
   which implicitly uses absolute timeslot positions in the attachment
circuit
   trunk as local service delimiters. The "fractional SPE/VC4" modes of the
   latest SONET draft provide, IMO, a valuable insight into the possible
   discussion. 

My conclusion (probably, trivial) from these observations is that
treatment of local service delimeters is a valid ARCHITECTURAL 
issue for PWE3. IMO the PWE3 requirements and architecture
documents should address this issue and provide guidelines that 
could then be followed in the service-specific documents. 
These guidelines should definitely address such issues as 
BW efficiency, implementation complexity, availability of 
off-the-shelf NSPs and trade-offs between pacing certain 
functionality into the PW IWF or NSP.

My 2c.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Shahram Davari [mailto:[email-masked]]
> Sent: Tuesday, March 18, 2003 7:38 PM
> To: 'Ali Sajassi '; 'Andrew G. Malis '; [email-masked] '
> Cc: 'Busschbach, Peter B (Peter) '; ''Andrew G. Malis' '; 
> [email-masked]' '; 'Vach Kompella '
> Subject: RE: [PWE3] Ethernet over MPLS 
> 
> 
>  Ali,
> 
> -----Original Message-----
> From: Ali Sajassi
> To: Shahram Davari; 'Ali Sajassi'; Andrew G. Malis; [email-masked]
> Cc: Busschbach, Peter B (Peter); 'Andrew G. Malis'; 
> [email-masked]'; Vach Kompella
> Sent: 3/17/03 5:29 PM
> Subject: RE: [PWE3] Ethernet over MPLS 
> 
> At 11:53 PM 3/16/2003 -0800, Shahram Davari wrote:
> 
> > >>Why can't one use raw mode for the latter case? If the
> > >ingress PE can't strip
> > >>the VLAN tags, then it can simply send all tagged frames in a
> > >single PW.
> > >>The egress
> > >>PE (which can pop tags) could simply pop the tags.
> > >
> > >Yes, everything is possible with the raw mode.
> > >
> >
> >I can't understand. If you agree that the raw mode can satisfy the
> >requirement in which one of the PEs can't push/pop, then why is there
> >a need for tagged mode?
> 
> Lets go back to your previous question again and lets go over 
> different 
> scenarios:
> 
> 1) mapping a trunk port on the ingress to a trunk port on the egress
> This is basically port-based operation and raw mode needs to 
> be used for
> 
> the PW.
> 
> SD=>OK.
> 
> 2) mapping a trunk port on the ingress to multiple access ports on the
> egress
> In this case, there are two options: a) use a single raw-mode 
> PW to send
> 
> all the VLAN tags from ingress to egress and then use the VLAN tags in
> the 
> egress PE to decide which access port to send the frames to or b) use 
> multiple tagged-mode PWs (one for each VLAN). The problem 
> with the first
> 
> approach is that when VLAN tags are used as service delimiter, each PE
> uses 
> them independent from others. So you can't expect VLAN-10 in 
> the ingress
> PE 
> means the same thing as egress PE.
> 
> 
> SD=> Why? VLAN tag meaning at the two ends are configured, 
> aren't they?
> 
> 
> What this means is that if you want to use a single raw-mode PW, you
> need 
> to translate the VLAN in the ingress PE before sending it 
> over the PW; 
> however, this conflicts with raw-mode definition which says the VLAN
> tags 
> are transparent. Therefore, you need to use either multiple 
> raw-mode PWs
> 
> (one for each VLAN) or multiple tagged-mode PWs (one for each 
> VLAN). If 
> raw-mode is used, then you need to do push/poping in both ingress and 
> egress PEs; whereas, if tagged mode is used, you need to do 
> push/pop in
> the 
> ingress PE (w/ trun port) and VLAN re-write in the egress PE 
> (w/ access 
> ports). Furthermore, if tagged mode is used, then the egress PE can 
> re-write the tag based on the PW itself and without paying 
> any attention
> to 
> the value of the VLAN tag coming over the PW.
> 
> Hope this helps. If not, then lets talk on Wednesday before 
> or after the
> 
> meeting.
> 
> -Ali
> 
> 
> 
> 
> 
> 
> >-Shahram
> >_______________________________________________
> >pwe3 mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/pwe3
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 19 Mar 2003 13:01:39 +0200

Muneyoshi,
Please see a rief comment inline. 

With best regards,
                                   Sasha Vainshtein

> From: Muneyoshi Suzuki [mailto:[email-masked]]
> Sent: Wednesday, March 19, 2003 12:44 PM
> To: Sasha Vainshtein; [email-masked]
> Cc: [email-masked]
> Subject: Re: Local service delimiters and PWs (was: [PWE3] 
> Ethernet over MPLS )
> 
> 
> 
> I fully agree with this and would suggest that the req and arch
> docs should also address compatibility/consistency with existing
> recommendations/standards.
> 
IMO, the checks vs. applicable standards should be part of the 
service-specific documents because the applicable standards 
are service-specific.

Hence the (common) requirements document should only express the 
common need to address explicitly compatibility/consistency 
with the relevant existing standards in all the service-specific 
documents. 

> Thanks,
> 
> 
> Muneyoshi Suzuki
> Nippon Telegraph and Telephone Corp.
>

---

From: [email-masked]
Date: Wed, 19 Mar 2003 12:47:06 -0000

Sasha,

You are raising an important set of observations IMO.  However, we don't see
this getting fixed any time soon unless there is a more fundamental re-think
of the architectural principles used in PWE3.  Indeed, I and colleagues
(across various BT lines of business) have discussed the sort of issues you
are raising in some detail, and we have concluded that our architectural
requirements are not aligning with what we see emerging from
PWE3....especially where MPLS is concerned.  This worries us.

I don't want to get too wide-ranging here (but to understand the full
architecture picture one really needs to take this total view, ie IP to duct
layers) so I'll try and keep the comments as brief/focussed as possible:

We need all 3 networking modes of cnls, co pkt-sw and co cct-sw (I
specifically mean SDH/OTNs transport here, not *application-interfacing* for
co cct-sw)....we simply cannot provide the full range of services required
without all these.  All technologies map to one of these modes.  What we
need as a business is functional convergence of technologies *within* each
mode but not *across* them (ie we specifically do not want the GMPLS
peer-model).  Without within-mode functional convergence we get the familiar
stovepipes (ie 'service=technology') that all operators know and hate,
and/or complex functional interworking problems to address across
user/control-planes.  So the architecture must consider this convergence
perspective.

IP is *the* cnls mode, MPLS is *a* co pkt-sw technology (though LDP mp2p is
an oddball type of MPLS technology that has a co pkt-sw forwarding mode but
the topology constructs allowed give a cnls flavour/difficulty to its
traffic/QoS/fault behaviour.....and so whilst we have to cater for this
whilst we use it, this in itself should not dictate the key MPLS
requirements going forward).  So the requirements/solutions required for an
IP server layer case are not the same as those required for an MPLS server
layer case.  Trying to unify them (in terms of treatment in PWE3) is a
mistake in our view, and in particular its damaging the potential of MPLS to
become *the* core co pkt-sw convergence mode that many people would like to
it assume (and we for sure need *some* core co pkt-sw mode technology).

Looking at the specific issues PWE3 is tackling we have these architectural
observations:
 
When 2 technologies form a client/server relationship it is very important
that the mapping between them is (ideally) a simple adaptation function (see
G.805, G.809).  Why?  Well, we need to ensure a flexible client (X) and
server (Y) relationship so that X and Y can be varied independently (subject
to the mode relationships making operational QoS sense).  If there is any
dependency between a specific pair of X and Y this will not be possible.
Sometimes such dependencies are created due to the inadequate specification
of either the client layer X or the server layer Y.  The right answer
however is to correctly/properly functionally specify both the client and
server layer technologies so that they can stand on their own independent of
each other.  This is vital also so that we, as operators, can introduce_new
or sunset_old client or server layer technologies independently.
 
A further issue here is the cost of functional management.  If there is not
a simple adaptation between X and Y, but a new 'in-between' layer with
bolt-on functions added to cater for deficiencies in either the client or
server layer, then these functions will require to be managed.....though not
this does *not* remove the need to be able to manage the client/server
layers anyway, its just 'something extra' to worry about.  The worst case is
when the added in-between layer functions are different for different
technology pairings of X and Y (for the reasons noted above).  These all
will result in increased Opex costs to operators.
 
XoverMPLS in the original Martini drafts already has an issue here regarding
Sequence Numbers.  In essence, MPLS has really no need to misorder packets
as it is a co pkt-sw technology.  The sequence number field is currently
inadequately specified wrt handling aberrations and the required consequent
actions (wrt to Seq No. wrapping, and how to tell the difference between
dead (or high-rate, high-loss) clients and quiescent (or low-rate, low loss)
clients....mainly applies to pkt-sw clients not cct-sw clients).  This
problem is therefore going to get shifted on to us operators (with I guess
some vendor-specific solutions?).
 
Now we are seeing proposals appearing (ie draft-nadeau-pwe3-vccv-00.txt) to
introduce OAM into this 'in-between' layer, and this is largely there to
proxy for an inadequate defect handling specification of the MPLS layer.  If
this goes ahead then a set of defects will need identifying and specifying
in terms of entry/exit criteria and consequent actions for this in-between
layer.  How likely do we think this will be given past experience?....not
much is our view.  And it will not help the defect handling in the MPLS
layer one bit.  We still need to manage this network (there are other cases
besides the PWE3 case to consider).  But in this case of XoverMPLS using p2p
LSPs there is no need for this.  We should be using the OAM of the client
and Y.1711 in MPLS (independently).

I don't know how easy it will be for PWE3 to change tact now......maybe its
simply too late?  However, I believe there could be some improvements
possible by (for example):
-	recognising/accepting that the solutions don't have to be common for
an IP or MPLS server layer;
-	limiting 'in-between' layer functions to only those that are
absolutely essential;
-	minimising specific X/Y client/server pairing dependencies;
-	in the case of p2p LSPs use Y.1711 for the fault-management of MPLS.

regards, Neil

> From: Sasha Vainshtein [mailto:[email-masked]]
> Sent: 19 March 2003 09:31
> To: Danny McPherson (E-mail); Xipeng Xiao (E-mail 2); Prayson 
> Pate (E-mail); Stewart Bryant (E-mail)
> 'Vach Kompella '; 'Shahram Davari'; 'Ali Sajassi '; 'Andrew 
> G. Malis '; [email-masked] '; Luca (E-mail); Ron Cohen 
> (E-mail); 'Riegel Maximilian' (E-mail); [email-masked]' '
> Subject: Local service delimiters and PWs (was: [PWE3] 
> Ethernet over MPLS )
> 
> 
> Hi all,