Subject: PWE Service interworking

From: Mark Seery <[email-masked]>
Date: Tue, 3 Jun 2003 09:54:57 -0700 (PDT)

It has been stated that service interworking is not
part of the current charter. This might be
appropriate, but I believe some consideration to this
issue is advisable, most especially the encapsulations
fixed on in the standards.

My best current view of the situation is that PWE is
an adaptation layer in both the IP and MPLS cases, and
in the MPLS case, a 1:1 mapping between attachment
circuits and unique LSPs (i.e. not the PSN LSP) is
also provided; in the IP case PWE provides a
multiplexing field rather than creating a new layer as
it does in the MPLS case.

As such, I have no philisophical problem with viewing
PW as an adaptation layer that is equivalent to 1490
over FR, 1483 over ATM, AAL1 over ATM, or AAl5 over
ATM. Therefore, to me the test is whether PW can
interwork with 1490, 1483, AAL1, and AAL5. This I
imagine is mostly a function of whether the encaps are
defined for PW in such a way that interworking is
possible without too many contortions (0 being
desireable)

I understand the argument that by placing too much
functionality in the PW adaption process, then PW runs
the risk of evolving into being more than a minimalist
adaptation - I am still study the implications of
this, but for now my main concern is that encaps
chosen for x/PW services enables interworking with
existing service networks that use 1490, 1483, AAL1,
and AAL5.

So even though authors of such encaps are not bound by
the current charter to make an assessment of this, it
would seem to me to be valuable if they did before
these encaps become further entrenched in service
networks.

Is this being considered already in encap
specifications?

Mark

---

From: Mark Seery <[email-masked]>
Date: Tue, 3 Jun 2003 10:46:03 -0700 (PDT)

--- Mustapha Aissaoui <[email-masked]>
wrote:
[SNIP]
> It is my opinion that the proper way to addres this
> case is to add
> multiprotocol support to the PW/MPLS PID in a way
> ....

Thanks, I suspect the above would provide a lot of
benefits and if it had already been present may have
influenced the design direction of PW over MPLS.

Mark

---

From: Mark Seery <[email-masked]>
Date: Tue, 3 Jun 2003 12:21:36 -0700 (PDT)

Hi Eric,

--- Eric Rosen <[email-masked]> wrote:
[SNIP] 
> Mark> I would be curious to know whether encaps
> authors
> Mark> looked at existing adaptations (1490, 1483,
> AAL1,
> Mark> AAL5) and decided they were unsuitable for
> some
> Mark> reason.
> 
> Those existing  adaptations are for  a completely
> different purpose,  so I'm
> not sure just what you're asking. 

Before I attempt to define service interworking, I
think it would be valuable for you to explain the
different purposes these encapsulations have. Your
answer **may** dramatically lower the size of the
thread and also help me better define service
interworking. 

Thanks,
Mark

---

From: "Ghassem Koleyni" <[email-masked]>
Date: Tue, 3 Jun 2003 15:38:34 -0400

There is a useful and accepted definition in ITU-T Recommendations, e.g.
I.555 for Service Interworking. Please take a look at it. 

Regards, Ghassem 

Hi Eric,

Thanks,
Mark

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

---

From: Eric Rosen <[email-masked]>
Date: Tue, 03 Jun 2003 15:44:00 -0400

Mark> Before I attempt  to define service interworking, I  think it would be
Mark> valuable   for   you  to   explain   the   different  purposes   these
Mark> encapsulations have.  

All I  meant is that RFC  1483, e.g., defines an  encapsulation for carrying
arbitrary  layer  2 or  layer  3  PDUs over  ATM,  whereas  PWE3 defines  an
encapsulation  for carrying  layer 2  frames over  a pseudowire  over  IP or
MPLS.   As the "gap"  between the  emulated service  and network  service is
very different in  the two cases, it's not obvious what  one means by saying
"why didn't  you use the  1483 encaps for  pseudowires"?  There was  also an
expectation that a given pw would carry a single kind of payload.

---

From: Mark Seery <[email-masked]>
Date: Tue, 3 Jun 2003 13:13:20 -0700 (PDT)

I understand the intention, but if we can not explain
this simply without reference to another document,
then we can not have a general discussion where
general concepts are agreed to.

I also realize that there would be a desire not to
reinvent the wheel, but Eric has suggested a way of
getting in the same page without pulling in
potentially stale state associated with any given
reference, and I think it is worth a try. We can
always reference the detail later.

mark

--- Ghassem Koleyni <[email-masked]>

---

From: Mark Seery <[email-masked]>
Date: Tue, 3 Jun 2003 14:16:53 -0700 (PDT)

--- Mark Seery <[email-masked]> wrote:
> All, remember the constraints: a) can't quote from a
> non-IETF standard, b) can't use the word layer. Will
> do my best.
> 
> Defining service interworking
> =====================
> 

This obviously was user/data plane discussion only,
and the details of mapping/interworking all the
various types of PDUs (OAM....) etc. not discussed.

Mark

---

From: Mark Seery <[email-masked]>
Date: Tue, 3 Jun 2003 16:54:21 -0700 (PDT)

Lloyd,

--- Lloyd Wood <[email-masked]> wrote:
[SNIP]
> While management interworking is well defined for
> ATM/Frame Relay [FRF.8, ITU-T I.555], the mapping of
> PW
> failures to the equivalent ATM/Frame Relay OAM
> messages when
> pseudo wires are used to interconnect these
> technologies is
> not well defined.

Specifically what you essentially end up with (in the
case where the IWF is not done at the ingress point)
is service interworking occuring over a network
interworking function, which complicates the decision
process of where to map OAMs to (i.e. the far-end
service interface, the PW, the PSN,.....); probably
depends on how much transparency is desireable WRT the
intermediate cloud.

Can probably be done, but makes things interesting.
Moreover, if the interworked "technologies" have
different capabilities, then becomes even harder.

As has been noted, on some occassions, some types of
IWF can occur outside the PSN cloud, so there are some
short-term options available.

IMHO, the value of looking at above referenced
documents would be to try and glean the types of
mappings that past IWF implementors have considered;
therefore becoming a guide, and diminishing the
chances of reinventing the wheel - but as you say,
they do not cover this particular case.

In practice (in the short-term at least), I suspect
that when shipping traffic to an MPLS core, the IWF
will occur before the PW entry point; and after the PW
exit point in the reverse direction, thus avoiding the
issue all together.

Mark

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 4 Jun 2003 08:41:44 +0300

> I would be curious to know whether encaps authors
> looked at existing adaptations (1490, 1483, AAL1,
> AAL5) and decided they were unsuitable for some
> reason.

At least one encap author looked at AAL1 and decided
that it was most suitable.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 4 Jun 2003 08:43:39 +0300

> To head  off the start of  another long, useless, and  
> in-bred thread, could you start  by offering a  precise definition of "service  
> interworking"?  In your answer, please do not  refer to any document whose 
> designation consists of a letter  followed by a period followed by a  sequence of 
> numbers.  Also, please do not use the word "layer" in your answer.

The definitions were in the architecture draft,
but were removed due to lack of interest at the time.

Stewart - perhaps this should be rethought.

Y(J)S

---

From: "Jack Pugaczewski" <[email-masked]>
Date: Wed, 4 Jun 2003 06:46:45 -0500

A carrier's perspective:

The existing customer based is a combination of the following Networking
Interworking options:
ATM-ATM, FR-FR, CE-CE, Ethernet-Ethernet

and Service Interworking Options:
ATM-FR, ATM-CES

A major purpose for moving to a converged MPLS (or PWE-3) network is to take
all of this functionality with as well a have the ability to introduce new
services (MPLS, IP,...).  This functionality must bring with it the OAM
fault and performance functionality that allows carriers to use the
combination of PE, CE and element management systems to perform fault
localization.

Specifications such as FRF.5 and FRF.8 are clearly defined and this same
approach should be used int the PWE3 space.

Respectfully,

Jack

PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY

F
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Mark
> Seery
> Sent: Tuesday, June 03, 2003 11:01 PM
> To: [email-masked]
> Subject: Re: [PWE3] PWE Service interworking
>
>
> So having tried a general description, a slightly
> (not constructing access points etc.) treatment of
> this issue might look something like the following.
>
> Acronyms NIWF - network internetworking function and
> SIWF - Service interworking function are not acronyms
> used by any standards body (that I know of).
>
> fig.1 is essentially how I think of PW today.
>
> Network Interworking
> ====================
> fig.1
>
>  CE1         PE1         P         PE2       CE2
>         -----------            -----------
>         |   NIWF  |            |  NIWF   |
> ------  |---------|   ------   |---------|  ------
> | FR |--| FR | PW |---| PW |---| PW | FR |--| FR |
> ------  -----------   ------   -----------  ------
>
> Where FR could be FR, Ethernet, or ATM.
> In the ATM case, AAL5 would (typically) be
> encapsulated on to a PW, and no understanding of upper
> layer protocols would be required.
>
> Service Interworking
> ====================
> fig.2
>
>  CE1         PE1         P         PE2       CE2
>         -----------            -----------
>         |   SIWF  |            |         |
> ------  |---------|   ------   |         |  ------
> | FR |--| FR | PW |---| PW |---|   PW    |--| PW |
> ------  -----------   ------   -----------  ------
>
> The scenario of a PW going to a CE is unlikely today,
> of course, but shown here as a theoretical option.
>
> or
> fig.3
>
>  CE1         PE1         P         PE2       CE2
>         -----------            -----------
>         |   SIWF  |            |         |
> ------  |---------|   ------   |         |  ------
> | FR |--| FR | MP |---| MP |---|   MP    |--| MP |
> ------  -----------   ------   -----------  ------
>
> The scenario of a MPLS (MP) service going to a CE is
> more likely than that of a PW, but still not likely to
> be widespread in the near term
>
> or
> fig.4
>
>  CE1         PE1         P         PE2             CE2
>         -----------            -----------------
>         |   NIWF  |            |  NIWF | SIWF  |
> ------  |---------|   ------   |---------------|
> -----
> | FR |--| FR | PW |---| PW |---| PW | FR | ATM
> |--|ATM|
> ------  -----------   ------   -----------------
> -----
>
> In this scenario FR is encapsulated on to a PW at PE1
> and decapsulated off of a PW at PE2 and then service
> interworked to an ATM service. The ATM service may be
> going to a CE or to an ATM network (in which case the
> SIWF would be slightly different)
>
> or
> fig.5
>
>  CE1         PE1         P         PE2       CE2
>         -----------            -----------
>         |   SIWF  |            |  SIWF   |
> ------  |---------|   ------   |---------|  ------
> | FR |--| FR | PW |---| PW |---| PW | ATM|--| ATM|
> ------  -----------   ------   -----------  ------
>
> this seems simpler than some of the previous examples
> but might actually be quite hard and is where
> translation to from PW encaps would need to be pretty
> good (my guess).
>
> or
> fig.6
>
>  CE1       FR SW      ATM SW        PE1         P
>         -----------             -----------
>         |   SIWF  |             |NIWF/SIWF|
> ------  |---------|   -------   | --------|  ------
> | FR |--| FR | ATM|---| ATM |---| ATM | MP|--| MP |
> ------  -----------   -------   -----------  ------
>
> In this case FR is interworked with ATM, and RFC 1490
> with RFC 1483 at the FR SW. Then at the PE, ATM is
> network or service interworked with MP. In the case of
> routed RFC 1490/1483, an IP packet could be popped and
> encapsulated over MPLS, but there would still be OAM
> interworking between the ATM and MPLS functions.
>
> In the case of bridged RFC1490/1483, it may be
> possibly to interwork the ATM and MPLS functions and
> then interwork RFC1483 and PW.
>
> Just some ideas of scenarios we may be looking at in
> the future.
>
> Having thought about it, there is probably no getting
> by with just a casual discussion of this issue. So we
> either add it to the charter now, or delay it as seems
> to be the consensus (i.e. I have only heard one strong
> voice pushing it to the forefront).
>
> Mark
>
>

---

From: Shahram Davari <[email-masked]>
Date: Wed, 4 Jun 2003 07:42:08 -0700

Mark,

Regarding Service interworking I believe the simplest and
most logical model is to do service interworking with MPLS
on both IWFs. Assuming (PL= Payload), the following figure shows an
example of what I think is a proper AT-MPLS-FR service interworking:

CE--------PE-------P--------PE---------CE
     PL        PL      PL        PL
    AAL5       X       X        Q.922
    ATM       MPLS    MPLS       FR

Both PEs do service interworking. One does ATM-MPLS service
interworking and the other one does FR-MPLS service interworking.

The advantage is that each PE needs to support a maximum of N service
interworking functions (N is all known L2 protocols). While your 
proposed model requires N square service interworking functions to be
supported in a single PE.

Yours,
-Shahram

>From: Mark Seery [mailto:[email-masked]]
>Sent: Tuesday, June 03, 2003 5:01 PM
>To: [email-masked]
>The simplest explanations (IMO) for interworking are
>as follows:
>
>Network interworking - ingress and egress attachment
>circuits use the same protocols
>Service interworking -  ingress and egress attachment
>circuits use different protocols
>
>Now any interworking agreement is going to specify
>exactly what protocols, so the actual definition
>necessarily becomes less generalized. Typical
>protocols that have been involved in interworking
>standards are link-layer PDUs and adaptation layers
>(FR, ATM, AAL1, AAL5) and Multiprotocol encapsulation
>standards (RFC 1483, RFC 1490).
>
>Simplistically a network interworking function has to
>map a service PDU to an encapsulation that provides
>service attributes on an underlying network such that
>the service entrities at each side of the network do
>not realize they are not operating over a native
>service network. An example of this would be two Frame
>Relay attachment circuits connected to an ATM network,
>or two Ethernet attachment circuits connected to a
>MPLS or IP network (i.e. PW)
>
>For example:
>
>CE--FR--PE--FR/PW/PSN--PE-FR-CE
>
>I don't think there has been much controversy about
>this, the only real area of controversy I recall is
>the degree to which the PW/PSN emualtes the
>ingress/egress service definitions. In providing this
>service emulation things such as the following may be
>mapped:
>
>1. Variable length PDU formatting and delimiting
>2. Error detection
>3. Connection multiplexing
>4. Loss Priority Indication
>5. Congestion Indication (Forward and Backward)
>6. PVC Status Management
>
>So in this sense Eric is correct. RFC 1490/1483 are
>not the same as the encapsulations used to perform
>network interworking, or what might otherwise be
>referred to as (sub)convergence. In this context the
>more appropriate question might be, was AAL1 or AAL5
>explored as to their applicability for encapsulating
>services over MPLS or IP; they may not provide what is
>needed, and that is a perfectly acceptable answer if
>that is the case. 
>
>Some standards differentiate between the case when two
>subscribers are communicating over a cloud, and when
>two networks are communicating over a third cloud; I
>will not for the sake of trying to establish some
>basic concepts.
>
>Now we move to service interworking, where we are
>trying to provide for a service to have two different
>interfaces at either end of a cloud. In this case,
>simple encapsulation does not work, the hard task (and
>I do understand it is not considered trivial by some
>developers) is to have say Frame Relay go in one side,
>and have ATM come out the other side. For example:
>
>CE--FR--PE--FR/PW/PSN--PE-IWF-ATM-CE
>
>The IWF (interworking function) could be in a variety
>of places, I just put it there for grins.
>
>In this example, we now have to not only convert the
>Frame Relay base protocol to ATM, but if we do not
>convert RFC1490 running above it to RFC1483, then
>there will be problems at that level of protocol
>interaction.
>
>NLPIDs are used often in encapsulations to provide
>indication of encapsulated protocols. Service
>interworking could be done at the ingress PE, in which
>case the resultant PW is really in the format of the
>egress attachment circuit. Another option is to do it
>at the egress PE, which would mean translating from
>the 1490/FR/PW/MPLS or IP PDUs to the resultant
>1483/aal5/atm attachment circuit. The question then
>becomes should the FR PDU just be popped from the PW
>and examined, or should the PW indicate, by a NLPID
>equivalent, what is contained within the FR PDU? That
>would probably be an implementation decision, but
>those types of dicussions may uncover any weaknesses
>in the current methods, if they exist at all, and they
>may not.
>
>If the PW is discarded before the IWF function, then
>that is probably not a problem as long as the
>resultant FR PDU is sufficient to perform the mapping;
>and therefore I am not concerned that the PW
>"whatever" disappears, this is analgous to the ATM
>AAL5 PDU disappearing and a new one being created, if
>the service interworking was performed in the same way
>
>So the more I think about, the less problems I
>see..........
>
>There is some thought floating around that if the PW
>encap was similar to or identical to whatever network
>is most likely to be interworked to, then that may
>make like easier for implementors and operators - that
>I leave as a discussion point, and note the horse has
>probably already bolted on that one, for this WG, in
>this time slot.
>
>Mark

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 4 Jun 2003 18:27:52 +0200

Shahram, Mark and all,
A couple of comments/questions.

1. I agree with Shahram that the model he has proposed
   is much simpler than one proposed by Mark in his
   "explanation email". To me, this makes it preferable.

2. My gut feeling is that:
   a) This difference in approaches is exactly what 
      the current PWE3 WG Charter defines as the 
      rationale for the PWE3 work when it says:
      <quote>
      	The PSN can transport PDUs for multiple services, 
	      and the conversion/interworking functions per
		service pair are not needed.  
	<end quote>
   b) It means (and has been correctly interpreted by many
      people including, I think, Mark) that the Charter defines
      "service interworking" out of scope for PWE3 - and for a good
      reason.

3. I am not sure if the term "X-to-MPLS service interworking" 
   is applicable to Shahram's diagram. E.g., for PL=Ethernet I 
   do not expect that the EXC bits in the MPLS encap will reflect 
   DE/CLP markings of the containing FR/ATM-based AC. All the 
   ETHoATM/ETHoFR-specific information will be simply discarded by the PEs!
   (At least this is, IMO, what the current Ethernet encapsulation 
   draft says:-). However, this does not affect the conclusions of (1) 
   and (2) above in any way.

Did I miss something?

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

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Wednesday, June 04, 2003 4:42 PM
> To: 'Mark Seery'; [email-masked]
> Subject: RE: [PWE3] PWE Service interworking 
> 
> 
> Mark,
>

---

From: Mark Seery <[email-masked]>
Date: Wed, 4 Jun 2003 08:32:33 -0700 (PDT)

thanks for the feedback Jack and understood.

Quick question, when you say service interworking
between ATM-CES, I an not quite sure what that means,
does that mean ATM to TDM or non AAL1 ATM to AAL1 ATM?

Thanks,
Mark

--- Jack Pugaczewski <[email-masked]> wrote:
> > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Mark
> > Seery
> >  CE1         PE1         P         PE2            
> CE2

---

From: Mark Seery <[email-masked]>
Date: Wed, 4 Jun 2003 08:56:40 -0700 (PDT)

Jack,

If the requirement is to interwork with MPLS, then I
suspect a number of organizations are probably already
delving in this area including MPLS Forum/FR Forum,
ITU, and possibly MEF (though I don't have much
visibility in there).

If the requirement is to interwork with PW, then I
suspect it would probably land in the IETF's court so
to speak.

Mark

--- Jack Pugaczewski <[email-masked]> wrote:
> Then what group/organization is going to take on the
> interworking and all of
> the issues ?
>

---

From: "Jack Pugaczewski" <[email-masked]>
Date: Wed, 4 Jun 2003 11:00:10 -0500

CES per ATM Forum specification af-vtoa-0078.000 which discusses AAL1 and
specifically Structured and Unstructed CES.  The benefit of ATM-CES is that
a customer can share a common facility for both AAL-5 and CES traffic.  The
CE (or CPE) is responsible for being CES compliant.  Within the carrier
cloud the CES termination can be handed off to a Class 5 switch TDM circuit.
It should also be noted that the CES functionality requires DCS
functionality for the trunk conditioning.  It would be expected that any
PWE-3 implementation would provide the same functionality.

> Sent: Wednesday, June 04, 2003 10:33 AM
> To: Jack Pugaczewski
> Cc: [email-masked]

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Wed, 4 Jun 2003 12:07:49 -0400

Shahram,

> interworking and the other one does FR-MPLS service interworking.

Okay, but in this example MPLS is just a transport not a service
(I don't think ATM-MPLS service interworking is the
right term). 

I would have assumed service interworking implies interworking
between an attachment circuit of type X (that attaches
to the client device) and another attachment circuit
of type Y and there is a pw or tunnel between X and Y (like
in your example). 
 
In fact if I reuse the scheme described in the PW architecture 
document (the "protocol layering model" - sorry Eric for the
use of the term layer ;-)), for that scenario (as in
Shahram figure), a service interworking is as well a 
pseudo-wire (PW) that:
 
a) connects two heterogeneous attachment/service types where
b) the encapsulation is null and
c) the PSN convergence which can be null
 
(we still have the PW demultiplexing and PSN)
 
In that case there is a service interworking scenario even if there 
is no service interworking function implemented on the PE that takes 
frames received on attachment circuit X and send them as type Y 
on that PE on either the PSN or CE sides. 

Hamid.

---

From: Mark Seery <[email-masked]>
Date: Wed, 4 Jun 2003 09:16:52 -0700 (PDT)

Jack,

> suspect it would probably land in the IETF's court

Though I have been informed offline that MPLS Forum is
already doing work in the area of PW, with the
inference that the IETF tends not to pursue
interworking projects.

So perhaps pursuing this discussion further is not
fruitful, lest the thread becomes an annoyance.

Mark

---

From: Mark Seery <[email-masked]>
Date: Wed, 4 Jun 2003 10:00:41 -0700 (PDT)

Hi Eric,

--- Eric Rosen <[email-masked]> wrote:
> 
> Mark> Service  interworking -  ingress  and egress 
> attachment circuits  use
> Mark> different protocols 
> 
> That's clear enough.

Good.
 
> My  assumption has  always  been  that the 
> interworking  function would  be
> applied either  before or after  the use of  the
> pseudowire.  When  there is
> already  a well-defined service  interworking
> function,  as in  ATM/FR case,
> that function  would be used.  Hence  the fact that 
> service interworking is
> taking place is transparent to the  pseudowire, and
> no PWE3 (or IETF) issues
> are raised.

In addition, for those that have already implemented
PW, this is the most intuitive way to now add service
interworking (which is why I think I was leaning in
this direction as opposed to the models others have
presented).
 
> 
> I think this is the same as you indicate in your
> example:
> 

Agreed.

> Is there anything more to say about it?

If the consenus in the WG is that this is the right
approach for *this* WG and organization to pursue,
then no.

The only thing I am not sure about is whether others
want the PW to be considered as a transparent cloud to
OAM functions. If that is not the case, then yes, I
guess we are done, given the above assumptions.

Other organizations will no doubt pursue other
approaches with the consequent tradeoffs and benefits;
and no doubt these will compete in the market place.

> In  the special  case where  the  payload is  always
> IP  datagrams, but  the
> ingress  and  egress  ACs  use  different data  link
>  protocols,  then  "ARP
> Mediation" can  be used  for interworking, as  long
> as  there is no  need to
> provide any sort of faithful data  link emulation. 
> This seems to be the one
> case that might be of interest to the IETF. 

Agreed, which really gets to the meat of the issue.
The IETF is an organization that has facilitated
wide-spread connectivity by developing a protocol (IP)
that works across multiple subnetworks and hence views
IP as the service layer and not ATM, FR, Ethernet,
TDM,...which is why I suspect it tends to pass on
layer 2 interworking projects.

That said, by developing layer 2 VPN standards, among
other things, the IETF has opened a small window in
the old time/space continuem (sp?) through which a
variety of activities could be punched through if
rough consensus was achieved.

Mark

---

From: "Himanshu Shah" <[email-masked]>
Date: Wed, 4 Jun 2003 13:08:51 -0400

I am participating in this effort in all three groups (IETF, MPLS and MEF).
IETF showed the door for service interworking (i.e. not a charter :-),
 although this may change and I believe IP-inteworking PW type already
defined?

MPLS forum is tackling service interworking when disparate
ACs are connected through MPLS PW.

MEF is concentrating on service interworking when disparate
ACs are directly attached.

Both MPLS forum and MEF are going to concentrate first
on service interworking for protocols that would work - such as IP.
For multiprotocol, some assumptions are made. Such as 
CEs would treat the underlying FR/ATM transport as Ethernet
and generate bridged Ethernet frames over that transport.

As for "service" aspects of the interworking, details are being hammered
out; Ethernet-LMI of MEF would help.

At MPLS forum, what frame format to use over the service interworking
PW is being discussed; canonical format of ATM SDU is one of the
option.

Again, at both forums this work is in infancy but charter exist.

/himanshu
wavesmith networks

> From: Jack Pugaczewski [mailto:[email-masked]]
> Sent: Wednesday, June 04, 2003 11:53 AM
> To: Sasha Vainshtein; 'Shahram Davari'; 'Mark Seery'
> Cc: [email-masked]
> > From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Sasha
> > Vainshtein
> > Sent: Wednesday, June 04, 2003 11:28 AM
> > To: 'Shahram Davari'; 'Mark Seery'
> > Cc: [email-masked]

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Wed, 4 Jun 2003 19:46:06 -0400

Eric,

[clipped]...

> I think this is the same as you indicate in your example:
>

I think you meant something like:
 
      CE--FR--PE--FR/PW/PSN--PE-FR-IWF-ATM-CE
                                ^^

> In  the special  case where  the  payload is  always IP 
> datagrams, but  the
> Mediation" can  be used  for interworking, as  long as  there
> is no  need to
> provide any sort of faithful data  link emulation.  This
> seems to be the one

I have no problem with IP-only interworking approach when
there is no available interworking function to use
(outside the pw), particularly if most of the traffic carried 
over a PW is IP. However, my questions probably best answered 
by the providers deploying pws where both attachment circuits 
are of different protocols are:
 
a) Are there applications/situations where 
   even if the payload is IP, the client requires the 
   provider not to make any assumption on the payload
   (maybe situations of regulatory scenarios)?
 
b) For the case where the provider has upgraded his l2 network 
   to MPLS/IP and the native l2 services are replaced with PWs, 
   can the provider guarantee/assume in all cases that the traffic 
   is always IP, or can he assumes that on any given PW there is
   no case where both IP and non IP traffic are being sent (since
   the upgraded service initially didn't make that assumption,
   or maybe the provider can't tell whether it is always
   IP since it doesn't control customer devices)?
 
c) Is there a situation/application even for IP only 
   interworking/payload where items like sequencing, etc 
   need to be supported as part of the service being 
   interworked?
 
Regardless what solution is provided and even in what
appropriate standard body that solution needs to be pursued
it will be good to have an overall view on what category and
percentage the interworking scenarios fall into.
 
Hamid.

---

From: Mark Seery <[email-masked]>
Date: Wed, 4 Jun 2003 22:04:53 -0700 (PDT)

Eric,

Comments in line,
Mark

--- Eric Rosen <[email-masked]> wrote:
> Shahram> Regarding Service interworking I believe
> the simplest and
> Shahram> most logical model is to do service
> interworking with MPLS
> Shahram> on both IWFs. 
> 
>> [ERIC] Fortunately, "service interworking with
MPLS" is not possible at the current time  as there 
is  such  thing (at  least  not in the  IETF)  as an 
"MPLS service". <<

MS=> Well perhaps the term is a bad one - that should
not be enough to disqualify the idea, but the point
you make below is worth discussing.

[ERIC] And hopefully things will stay that way.

MS=> Somehow I doubt it ;-)

> Shahram> The  advantage is  that each  PE needs  to
> support  a maximum  of N
> Shahram> service interworking functions (N is all
> known L2 protocols). While
> Shahram> your  proposed   model  requires  N  
> square  service  interworking
> Shahram> functions to be supported in a single PE. 
> 
>> [ERIC] There  are certain  theoretical  advantages
to having  a  sort of  "generic service"  to/from
which  all other  services could be mapped. However,if
FR/ATM interworking  on the  one hand  and ARP
mediation  on the  other hand cover 99% of the space,
there doesn't really seem to be  much need for this
generic service. <<

MS=> Well there is this emerging thing called
Ethernet; and there was Jack's note about a
requirement for ATM CES-TDM service interworking. But
to your point, FR/ATM/IP cover I would say at least
90% of the cases today (not including private line
TDM); so a lot can be achieved with the approach of
doing IWF either side of the PW, as a practical matter
today. Probably the trickier discussion is what makes
sense for tomorrow, and what makes sense for people
that want to move towards one integrated network from
an OAM, management plane, and control plane
perspective; and what volume will be achieved with
these new services.

---

From: [email-masked]
Date: Thu, 5 Jun 2003 08:53:26 +0100

Agreed Shahram.....using MPLS as a common core reduces the SIWF function
from N^2/2 to N dimension.

regards, Neil

> Sent: 04 June 2003 15:42

---

From: [email-masked]
Date: Thu, 5 Jun 2003 09:29:45 +0100

Eric,
> Shahram> Regarding Service interworking I believe the simplest and
> Shahram> most logical model is to do service interworking with MPLS
> Shahram> on both IWFs. 
> 
> Fortunately, "service interworking with MPLS" is not possible 
> at the current
> time  as there  is  such  thing (at  least  not in  the  
> IETF)  as an  "MPLS
> service".  And hopefully things will stay that way.
NH=> I can understand why you might say this.....and I can certainly see its
a good way to keep market control ;-)
> 
> Shahram> The  advantage is  that each  PE needs  to support  
> a maximum  of N
> Shahram> service interworking functions (N is all known L2 
> protocols). While
> Shahram> your  proposed   model  requires  N   square  
> service  interworking
> There  are certain  theoretical  advantages  to having  a  
> sort of  "generic
> service"  to/from which  all other  services could  be 
> mapped. 
NH=> It's not theoretical...and its also about trying to get away from the
notion that 'technology-service'....that leads to overlaid stovepipes.  If
we have a common MPLS core to which we can interwork FR/ATM (with maybe
ethernet access) it will significantly reduce our capex/opex.  If we have to
run parallel networks (which is effectively what you are advocating) then we
won't see those capex/opex savings.  Remember, there are many large
operators out there with hugh FR/ATM network deployments who are looking to
where the next generation equipment will be.  All vendors show MPLS in this
space.  But it will have to be the right type of MPLS.

I can't speak for other operators but we want to have 3 core modes - cnls,
co pkt-sw and co cct-sw.  They all do different jobs and they are all
required in our view.  What we don't want is several different technologies
effectively doing the same job.  So functional convergence of technologies
*within* each mode makes a great deal of technical and business sense.  If
for whatever reason you find this rationale is unpalatable then OK, but I do
think it has great merit if one can look at the issues dispassionately.

regards, Neil

---

From: Eric Rosen <[email-masked]>
Date: Thu, 05 Jun 2003 10:42:26 -0400

MS=> Well there is this emerging thing called Ethernet;

True,  but  there  is  no  service interworking  between  ethernet  and  p2p
technologies.   When you  want to  hook up  an ethernet  interface to  a p2p
interface  you usually  end up  having  the CE  encapsulate ethernet  frames
inside the  p2p data link so that  the higher layers see  an ethernet.  It's
difficult to see  what the alternative might be, since  you can't just "map"
a broadcast medium to  a p2p medium.  And ethernet has no  OAM to pass along
anyway; no doubt this will keep it from ever succeeding ;-)

I don't  know whether there's an  ATM-TDM interworking issue or  not, but if
there is, we can be pretty sure  that our TDM sub-group would never agree on
what needs to be done ;-)

---

From: Mark Seery <[email-masked]>
Date: Thu, 5 Jun 2003 08:27:43 -0700 (PDT)

Hi Eric,

--- Eric Rosen <[email-masked]> wrote:
> Ethernet;
> technologies.   

Challenging to be sure......

I don't think it is the broadcast vs P2P that is the
problem so much (VPLS for example), but it is really
the CNLS addressing vs CO addressing (not even a VLAN
tagged Ethernet frame ultimately uses a CNLS address)

If the P2P technology is carrying an Ethernet frame
then something can be made to work. If not, then
translating a DLCI/VC to a DA/SA MAC pair would
undoubtely be quite a challenge; unless there is a
router on each end.

> what needs to be done ;-)

Not touching that one ;-)

Mark

---

From: [email-masked]
Date: Thu, 5 Jun 2003 18:51:12 +0100

Hi Mark,  I have attempted to answer your question as briefly as I
can.....but I am not doing full justice to it wrt to all the activities
ongoing here (in BT) to address this.  

regards, Neil

> 
> Hi Neil,
> 
> --- [email-masked] wrote:
> [SNIP]
> >> I can't speak for other operators but we want to
> have 3 core modes - cnls, co pkt-sw and co cct-sw.
> They all do different jobs and they are all required
> in our view.  What we don't want is several different
> technologies effectively doing the same job.  So
> functional convergence of technologies *within* each
> mode makes a great deal of technical and business
> sense. <<
> 
> ms=> WRT this issue, I am not sure I understand the
> point you are making. 
> 
> For example, if an equipment operator was to implement
> the following:
> 
> Where the FR-IWF-ATM step was implemented in the same
> PE, why that would lead to:
> 
> -Parallel networks
> -Lack of functional convergence
> 
> If the problem is that MPLS is not perceived as truly
> CO-PKT-SW, then that of course is a problem, but
> orthogonal to this particular issue?
> 
> What exactly about this approach does not get you
> where you need to be?
> 
> I think expanding on your initial statement would aid
> our understanding greatly.

NH=> You can indeed do what you are suggesting Mark if the only concern is
FR/ATM Service I/W, ie retain network I/W wrt to MPLS for *one* of these
technologies (you show the case of FR above) and with a PW adaptation
function, and you are not overly concerned with the 'quality' of the
resulting solution.

However, one can do far better than this in our opinion.  But remember, I am
discussing what follows in the context of a large operator seeking a common
co pkt-sw core to which I feel *comfortable* in migrating my current FR/ATM
legacy networks to (ie I am looking for something which we would deem as
carrier-strength for this case), and also with one eye on future service
opportunities.  

Firstly we have to recognise why the PW functions are present.

My 1st observation is that I want all 3 modes of cnls, co pkt-sw and co
cct-sw (I mean SDH/OTNs by this).  They serve different roles, they have
quite different behaviours and I need them all.  So I am looking for
functional convergence of technologies that belong to the *same* mode.
Based on this observation, I don't need PWs to try and make IP and MPLS
cases look alike.....if IP and MPLS were indeed the same thing why would I
need MPLS at all?

My 2nd observation is wrt Seq. Nos.  These are there to address pkt
re-ordering....but I don't want to buy MPLS kit from a supplier who
re-orders pkts as a 'feature'.

My 3rd observation is that I am not overly concerned with the trivial BW
squeezing of the clients (esp when I see other technologies that create BW
wasting) and I have no intention of sending pkts over ethernet in the
network core and so have no need to pad them out.

So exactly what real value is the PW stuff providing for us?  Very little is
our view.  But it will provide us with some problems.

Adding the PW stuff creates a new problem of mapping defect indications
across the PW 'layer' that lies between the real client technology and the
MPLS server.  Moreover, if there are functions in the PW layer (like Seq.
No.s) then I need to define defects for handling these, ie entry/exit
criteria and consequent actions.  Currently this is left open-ended....as is
the case for defects in general for MPLS, at least in IETF.  This is simply
not good enough for us.  We are looking for defect detection/handling like
that described in Y.1711.....which also specifies how to measure
availability.  

And the answer is not to introduce even more functionality in the PW layer
like a MPLS PID field (a fix for the ECMP hack in mp2p) and PW OAM.

So all I am getting is a load of stuff to manage that really has no reason
to be there other than to fix problems created elsewhere.  So an
alternative/simpler answer *if* I can get the right sort of MPLS from
suppliers is to directly interwork with MPLS.  It also allows me the option
to offer an MPLS-based service interface one day (if I so choose) and it
also addresses the point Shahram made about reducing the interworking
dimension by requiring legacy protocols to interwork only with MPLS, ie MPLS
is the common core broker technology.

In summary, its simpler and I can get a carrier-strength solution this way.
Remember however, as I noted above, I am looking at this problem from a
technical/commercial perspective as a large operator seeking to reduce
capex/opex by having a sensible migratory solution to a common co pkt-sw
core.  This is probably not something IETF may want to work on...and I do
understand/accept that.

regards, Neil

---

From: Mark Seery <[email-masked]>
Date: Thu, 5 Jun 2003 11:16:16 -0700 (PDT)

Thanks Neil,

So to summarize, what you have essentially stated is
that any interworking scenario that includes PW is not
going to meet your needs?

The other problems indicated have been the N2
interworking problem which I assume is mostly an
equipment vendor problem. Curious if and how this
creates a problem for operators?

Are there any other issues raised by this approach
(excluding for the moment that PW, MP2P, etc.) does
not meet your needs?
-Do service layers need to be able to do segment OAM
in the core (i.e. network interworking might create
transparency of the core)

Thanks,
Mark

---

From: "Jack Pugaczewski" <[email-masked]>
Date: Thu, 5 Jun 2003 13:37:59 -0500

Segment and End-to-End OAM are utilized on an every day basis and a
strategic part of the fault isolation process.  More specifically, the
ability to generate an End-to-End at an intermediate node is essential.
This allows the client (or client application) to initiate the request to a
single element management system.

> Sent: Thursday, June 05, 2003 1:16 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: Mark Seery <[email-masked]>
Date: Thu, 5 Jun 2003 12:47:39 -0700 (PDT)

> PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY

Thanks Jack, 

1) Is it important that every layer be able to do a
segment OAM on every segment, or just the segments
that logically belong to that layer (i.e. as
delineated by access points of that layer)? For
example, in the following network:

 1      2        3    4     5      6        7         
CE----ATM_SW-----PE----P----PE----ATM_SW----CE

>From the perspective of the ATM layer (assume VCC, no
VPC), Is a segment between 2 and 6 or are 2-3, 3-4,
4-5, and 5-6 also considered segments (from the
perspective of your requirements as an operator).

2) When an end-to-end OAM is initiated from an
intermediate node, what is considered end-to-end? For
example, in the following network:

 1      2        3    4     5      6        7         
CE----FR_SW-----PE----P----PE----ATM_SW----CE

If an end-to-end OAM is initiated at "6" towards the
direction of "1", where would you expect the OAM to
terminate/take action?

Thanks,
Mark

---

From: Shahram Davari <[email-masked]>
Date: Thu, 5 Jun 2003 12:55:46 -0700

Mark,

1) Each layer should have segment OAM mechanism that applies only to that layer.
2) End-to-end OAM at each layer corresponds to the terminating points of that layer.

-Shahram

>Sent: Thursday, June 05, 2003 3:48 PM
>To: Jack Pugaczewski
>Cc: [email-masked]

---

From: "David Allan" <[email-masked]>
Date: Thu, 5 Jun 2003 16:33:50 -0400

If you're concatenating technologies together for SWIF, then yes the layers
terminate. Its also a pain to interwork OAM protocols as the semantics may
not match. The 17iw stuff assume we're interworking states of separate
entities to get an overall view. 

NIWF does have a better e2e story but as a pure overlay, you're just keeping
the old game alive. Deploying old edge and new core.

Didn't quite get your third comment?

cheers
Dave

> Sent: Thursday, June 05, 2003 4:19 PM
> To: Shahram Davari
> Cc: [email-masked]
> --- Shahram Davari <[email-masked]>
> wrote:
> > Mark,
> > 
> What does that mean in an SIWF scenario. Does a layer
> terminate when it hits a SIWF?
> 
> If so, then seems like a network interworking approach
> provides a better end-to-end OAM view. 
> 
> If not, then does that mean a subscriber gets an OAM
> view of the internals of a network in the X/MPLS case
> be suggested as an alternative?
> 
> Mark
> 
>

---

From: Shahram Davari <[email-masked]>
Date: Thu, 5 Jun 2003 13:40:01 -0700

>terminate when it hits a SIWF?

Yes.

>provides a better end-to-end OAM view.

Yes, but these are different ball games. You need service
interworking if Attached circuits are different.

>be suggested as an alternative?

No. The basic idea is to only map defect states between peer layers.

-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Fri, 6 Jun 2003 06:31:46 -0700

Correct.

-Shahram

>From: Lin, Zhi-Wei [mailto:[email-masked]]
>Sent: Friday, June 06, 2003 8:52 AM
>To: Shahram Davari; 'Mark Seery'; Jack Pugaczewski
>Cc: [email-masked]
>Hi all,
>Sorry to interrupt your very informative discussions, but I 
>have a question.
>In the case of the MPLS (which is our topic?) my understanding 
>is that OAMs
>are always end-to-end? "Segment" OAMs similar to ATM can be 
>created for MPLS
>simply by stacking a new MPLS header?
>
>Thanks for any clarification
>Zhi
>
>
>> Sent: Thursday, June 05, 2003 3:56 PM
>> To: 'Mark Seery'; Jack Pugaczewski
>> Cc: [email-masked]

---

From: "Lin, Zhi-Wei" <[email-masked]>
Date: Fri, 6 Jun 2003 08:52:00 -0400

Hi all,

Sorry to interrupt your very informative discussions, but I have a question.
In the case of the MPLS (which is our topic?) my understanding is that OAMs
are always end-to-end? "Segment" OAMs similar to ATM can be created for MPLS
simply by stacking a new MPLS header?

---

From: Shahram Davari <[email-masked]>
Date: Fri, 6 Jun 2003 07:18:44 -0700

>time  as there  is  such  thing (at  least  not in  the  IETF) 
> as an  "MPLS

Service is a term to indicate the service that a layer provides
to its upper layers. And MPLS provides connectivity service to
its upper layers.

>
>Shahram> The  advantage is  that each  PE needs  to support  a 
>maximum  of N
>Shahram> your  proposed   model  requires  N   square  service 
> interworking
>service"  to/from which  all other  services could  be mapped. 
>  However, if
>FR/ATM interworking  on the  one hand  and ARP Mediation  on 
>the  other hand
>cover 99% of the  space, there doesn't really seem to be  much 
>need for this
>generic service. 

If no other Access technology is used or get invented.

-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Fri, 6 Jun 2003 07:33:02 -0700

>Question for you though, is it interworking to MPLS
>that is required, or interworking to PW that is
>required.

Interworking with MPLS is required, but MPLS itself must have
some sort of adaptation layer, which could be similar to CW in
the PW.

>
>I would also not that at one of the IWFs
>RFC1483/RFC1490 interworking should be an option, what
>would you suggest in that regard?

If the core is MPLS, then I don't see the need.

>
>Also I assume you don't ever see MPLS as being as
>service interface from your response?

No, it might be.

>
>And do you see this model working also for Ethernet to
>ATM/FR interworking?

I don't know.

-Shahram

---

From: [email-masked]
Date: Sat, 7 Jun 2003 23:39:03 +0100

Tom,

If you understand G.805/809 (and therein lies the major problem) the meaning
of 'end-end' is obvious, ie it's between the trail termination points in
whatever layer network is considered.  Forget the wrong/misleading OSI
model......there is more to networking than 'one' network layer.    

regards, Neil

> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: 07 June 2003 13:32
> To: 'Lin, Zhi-Wei'
> Cc: [email-masked]
> 	I think you need to clarify what "end to end"
> means. In the way of PWE/MPLS I believe it means
> PE-PE imposition/disposition points. 
> 
> 	--Tom
> 
> > have a question. In the case of the MPLS (which is our 
> > topic?) my understanding is that OAMs are always end-to-end? 
> > "Segment" OAMs similar to ATM can be created for MPLS simply 
> > by stacking a new MPLS header?
> > 
> > > >> strategic part of the fault isolation process.  More 
> > specifically, 
> > > >> the ability to generate an End-to-End at an intermediate
> > > >> node is essential.
> direction of 
> > > >"1", where would you expect the OAM to terminate/take action?
> > > >
> > > >Thanks,
> > > >Mark
> > > >
> > > >

---

From: Akiva Sadovski <[email-masked]>
Date: Sun, 8 Jun 2003 17:44:08 +0200

Jack,
  sorry to interrupt you, but - few questions inline ...

> Sent: Thursday, June 05, 2003 10:27 PM
> To: Shahram Davari; 'Mark Seery'
> Cc: [email-masked]
> Agreed.  However, for OAM fault management interworking is 
> required.  For
> example, a Frame Relay PVC being marked as inactive should 
> map to an F5 VCC
> ATM OAM AIS condition.  In the case of OAM for loopback testing the
> interworking entity in conjunction with the element 
> management system is
> responsible for the relationship between layers.  

Can you elaborate ? What is done by interworking entity and what by
management system ?

Therefore, 
> it is possible
> to initiate Layer n OAM in one direction and Layer n+1 in the other
> direction.

  ... with the translation done by SIWF at the edge ? What are the benefits
?

> > Sent: Thursday, June 05, 2003 2:56 PM
> > >> specifically, the

---

From: "Lin, Zhi-Wei" <[email-masked]>
Date: Mon, 9 Jun 2003 08:40:42 -0400

Hi Mark,

Thanks for the info! I wasn't concentrating on the use of PW but more on the
MPLS functions. My view has always been that PW is simply an encapsulation
just like GFP ;-) 

I was confused with your statement that it is ideal to have a segment OAM.
What would drive this?

Also your point about how to identify OAM termination points is interesting.
How would you do this? Would this simply be done during the setup of the
LSP, i.e., the end-points of the LSP is by definition the trail termination?
And as such the OAM CV would use the ID of the endpoints as its source TTI?

Thanks
Zhi

> Sent: Saturday, June 07, 2003 7:50 PM
> To: Lin, Zhi-Wei
> Cc: [email-masked]
> Hi Zhi,
> Imagine a network:
>          |----------------------------|
> 
>                |----|-----|-----|      TE COS = Gold
> 
> 
> CE1----PE1----P1----P2----P3----P4----PE1----CE2
> 
> There are two end-to-end OAMs that may be desireable in this network:
> 
> 1) PE1--PE2 (the user plane for the LDP-LDP connection 
> between PE1 and PE2)
> 2) P1-P4
> 
> If you take the layer between P1 and P4 and add a label, you 
> do not reveal
> the segments you obfiscate them by creating another "layer". 
> The segments
> P1-P2, P2-P3, and P3-P4 would ideally be treated via special 
> segment OAMs,
> and the end-to-end OAM between P1 and P4 would be handled by 
> a different
> type of OAM, and end-to-end OAM.
> 
> With PW, labels are used to represent attachment circuits 
> (essentially as a
> mux field), creating another Label push:
> 
>        |--------------------------------|
> 
>          |----------------------------|
> 
>                |----|-----|-----|
> 
> 
> CE1----PE1----P1----P2----P3----P4----PE1----CE2
> 
> Creating another End-to-End OAM, the discussion then becomes 
> what is the
> termination points of this "layer". If you view PW as just a 
> mux function,
> and you create a mux field rather than pushing another label, then the
> network looks like this:
> 
>  |---------------------------------------------|
> 
>          |----------------------------|
> 
>                |----|-----|-----|      TE COS = Gold
> 
> 
> CE1----PE1----P1----P2----P3----P4----PE1----CE2
> 
> However, I suspect that the label push was used as automating 
> the way a mux
> indication is assigned to an attachment circuit. Perhaps an 
> alternative
> solution may have been to use signaling to indicate the 
> relationship between
> mux numbers and attachment circuits, and then use a mux field 
> and not push a
> label.
> 
> if you believe the OAM needs to flow to a different point in 
> the PE system
> because the PW logic is implemented in a different part of 
> the system, then
> you are back to this:
> 
>        |--------------------------------|
> 
>          |----------------------------|
> 
>                |----|-----|-----|
> 
> 
> CE1----PE1----P1----P2----P3----P4----PE1----CE2
> 
> Which brings us back to the old conversations (described previously as
> "useless" and "in-bred") about what is a layer.
> 
> Mark
> 
> Behalf Of Lin,
> Zhi-Wei
> Sent: Friday, June 06, 2003 5:52 AM
> To: 'Shahram Davari'; 'Mark Seery'; Jack Pugaczewski
> Cc: [email-masked]

---

From: Keith Knightson <[email-masked]>
Date: Mon, 9 Jun 2003 09:35:13 -0400

>model......there is more to networking than 'one' network layer.
Neil,

Oh, please.....now you are going too far....even for your high 
horses.......  :-)

And, if you were to understand IS 8648 and IS 7498  (and therein lies 
the major problem),  you would know about "sub-layers" and 
"relays"..... and how more than two entities can be distributed 
within a given layer/sub-layer to overcome the discontinuities due to 
protocol differences.

You said "There is more to networking than 'one' network layer". 
Yes, and they were called sub-layers, within the named layer in 
question. Any layer can be sub-divided into sub-layers, this is clear 
from IS 7498/X.200 and is particularly described in IS 8648.   You 
are confusing the general concept of layering  (which includes 
sub-layering) with specific religious labelling and packaging of a 
stack for a particular open system design formulated in a bygone era 
of X.25.

You say the meaning of 'end-end' is obvious.. This is clearly not the 
case....particularly since G.805 is actually wrong in this respect.

For example, with service interworking, the "end" points are not 
coincident with your so-called trails or protocol termination points. 
Service mapping implies conveying the *semantics* across a relaying 
point, i,e. beyond the point of protocol termination. Let's just 
suppose for argument's sake that some effect is common to both the 
protocols being interworked and can be mapped to provide an 
"end-to-end" effect.  It is clear that the intermediate points simply 
convey this effect by mapping. Therefore the trail termination points 
of the protocols on each side of the relay cannot be considered to be 
ends for the communication in that layer, despite the fact that each 
of the protocol is terminated at some intermediate point.  There are 
a number of peer entitities operating at the same "level" operating 
co-operatively and in tandem to provide ends beyond themselves.  Nor 
can you consider that there is higher layer trail to rperesent the 
e2e because there is no addtional protocol layer to terminate such a 
trail.  I.e. G.805 simply does not work in this case.

The whole point about services is defining their semantics, i.e 
beyond the one dimensional issue of what's on the wire, that's just 
syntax. Origination and/or Termination points do not necessarily 
dictate the end point for all communication at that particular peer 
level. They only indicate the presence of generators and receivers of 
a particular format/syntax processing.

The real question to be asked if whether the user be aware that the 
so-called service interworking is taking place as opposed to the 
so-called network interworking for any given protocol he uses between 
him (the CE) and the PE?   Suppose both SIW and NIW are involved for 
for two different paths from given CE with the same CE-PE protocol 
stack at one end, but with NIW at end and SIw at another, because 
conditions at each of the destinations are different.   All this 
should be hidden from the user, but the semantics should be the same. 
Users cannot be expected to know how the semantics might differ for 
every conceivable concoction that might be applied deep in the bowels 
of core networks or at remote access networks. BTW, it is possible to 
map OAM imperatives/notifications across a service interworking unit 
for and within a given peering arrangement.

The use of the term "layer network"in G.805/809 is also erroneous and 
not useful in this respect. Trail end-points are clearly not always 
indicative of "networks" nor "ends".  A protocol does not 
automatically beget a network. The term network also has no useful 
universal or absolute definition is also best avoided. Addtionally, 
G.805 ignores the three party semantics between user-provider-user, a 
vital ingredient in building relays which deploy service interworking 
and understanding of the service being provided. I will ignore the 
issue about the usefulness or otherwise of the term "layer" for the 
moment.

In actuality, protocols have roles. Protocols play a role according 
to context in which they are applied. They also operate between peer 
entities.  That's about all that can be said in terms of useful basic 
principles in the general context (i.e.not OSI context).

I suggest avoiding these "my-architecture/your-architecture" 
rat-holes, and simply discuss how protocols are to be stacked, and 
where, and the semantic effects required between any /all of 
designated points that can be identified. Of course, in this case, I 
agree it would be much simpler if the IETF could join the 21st 
century and  allow the use of something sensible to draw proper 
pictures to illustrate all these cases and issues more precisely, 
pictures being worth thousands of disageable and ambiguous words.

Regards

Keith

BTW it is really simple to define the difference between network 
interworking and service interworking without using the terms layer 
or network or G.805 or any other inappropriate model.

---

From: Mark Seery <[email-masked]>
Date: Mon, 9 Jun 2003 09:33:53 -0700 (PDT)

Zhi,

--- "Lin, Zhi-Wei" <[email-masked]> wrote:
[SNIP]
 
> I was confused with your statement that it is ideal

Well, anyone who has spent any time in an operations
role will know that the fundamental element of
diagnosis is isolation. Whether you are doing
break-fix, continuity checks, or performance
management, you want to know where and when things
are/are not happening. Segmentation is a form of
element isolation.

> endpoints as its source TTI?

So worth noting obviously that "termination points" is
not a term used by this organization do perhaps not
construction to spend too much time dwelling on that
term, but in essence you want to know where in the
network the action is being formed, and you want to be
able to verify that where you think it is happening,
it is actually happening. One method of verification
would be to use an address. As to where it should
happen, well some organizations would suggest that it
should happen at layer end points, and they support
this notion by defining what a layer is. In this
group, I think we are trending in the direction of it
happens where the PW code is implemented. Is this just
a semantic difference? An exercise for the reader.

Mark

---

From: "David Allan" <[email-masked]>
Date: Mon, 9 Jun 2003 12:48:47 -0400

Mark/Zhi:

One other aspect of segmentation is ability to provide arbitrary OAM
demarcation boundaries. Very useful when considering multiple organizations
providing a service.

Dave

> Sent: Monday, June 09, 2003 12:34 PM
> To: Lin, Zhi-Wei
> Cc: [email-masked]
> construction to spend too much time dwelling on that term, 
> but in essence you want to know where in the network the 
> action is being formed, and you want to be able to verify 
> that where you think it is happening, it is actually 
> happening. One method of verification would be to use an 
> address. As to where it should happen, well some 
> organizations would suggest that it should happen at layer 
> end points, and they support this notion by defining what a 
> layer is. In this group, I think we are trending in the 
> direction of it happens where the PW code is implemented. Is 
> this just a semantic difference? An exercise for the reader.
> 
> Mark

---

From: "Lin, Zhi-Wei" <[email-masked]>
Date: Mon, 9 Jun 2003 14:35:19 -0400

Hi Mark, David,
 
Thanks. But I guess my confusion is that in the MPLS, when end-to-end OAM
segments can be created on the fly, why would you need another "mode" for
segment OAM? Isn't ATM's segment OAM equivalent in the MPLS by simply
creating a new end-to-end OAM?
 
Zhi

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: Monday, June 09, 2003 12:49 PM
To: 'Mark Seery'; Lin, Zhi-Wei
Cc: [email-masked]
Subject: RE: [PWE3] PWE Service interworking 

Mark/Zhi: 

Dave 

> From: Mark Seery [ mailto:[email-masked] <mailto:[email-masked]> ] 
<https://www1.ietf.org/mailman/listinfo/pwe3>

---

From: "David Allan" <[email-masked]>
Date: Mon, 9 Jun 2003 15:13:20 -0400

HI Zhi:
 
Did not get the comparitive aspects of your previous post....
 
You are correct in nothing that you can get similar semantics (scoping the
boundaries of an OAM flow and create subnet specific behaviors) via using
label stacking, and in many multi-provider cases you would want to do so
(depending on layer isolation to impart a degree of security as your
security within a given layer is limited). Downside being you are trading 4
bytes of overhead per packet to get this (additional stack entry) as well as
creating additional control adjacencies (to effectively instantiate a new
layer). 
 
The other issue is that adding a layer at the top of the stack, and then
using OAM on that layer is not the same as testing as close to the payload
as possible (you can postulate that the coverage is usefully close until you
get into ECMP; we are figuring out how to get stuff to fate share with the
bottom label, but its a different story for the top label). IMHO segment OAM
on the bottom label would be more chatty but more authoritative in the
presence of ECMP vs. adding layers. 
 
cheers
Dave

-----Original Message-----
From: Lin, Zhi-Wei [mailto:[email-masked]] 
Sent: Monday, June 09, 2003 2:35 PM
To: Allan, David [CAR:NS00:EXCH]; 'Mark Seery'; Lin, Zhi-Wei
Cc: [email-masked]
Subject: RE: [PWE3] PWE Service interworking 

Hi Mark, David,

Zhi

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: Monday, June 09, 2003 12:49 PM
To: 'Mark Seery'; Lin, Zhi-Wei
Cc: [email-masked]
Subject: RE: [PWE3] PWE Service interworking 

Mark/Zhi: 

Dave 

> From: Mark Seery [mailto:[email-masked] <mailto:[email-masked]> ]

---

From: [email-masked]
Date: Mon, 9 Jun 2003 22:00:24 +0100

Dave,
 
And this is a powerful potential feature of MPLS.....fixed heirarchy models
don't easily allow this.
 
regards, Neil

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: 09 June 2003 17:49
To: 'Mark Seery'; Lin, Zhi-Wei
Cc: [email-masked]
Subject: RE: [PWE3] PWE Service interworking 

Mark/Zhi: 

Dave

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Tue, 10 Jun 2003 15:19:35 -0400

Mustapha,

> This is the case that requires the most attention. One of my
> customer's customers runs IPX and IP over the same FR connection.
> Also, some ISPs buy leased line service from a SP to connect their
> POPs. Today, they use FR and ATM. That one connection can carry IP
> and CLNP (for IS-IS).
> Although IP might be the dominant protocol in volume, many of the
> existing L2 VPN services have a small amount of other protocols.
> That is why if one terminates each L2 locally at a PE in service
> interworking between different link layers (e.g., FR-MPLS-Ethernet),
> then there is a need to identify multiple protocols in the same PW
> or LSP.
>

Agreed. For these cases a multiprotocol approach is required.

Hamid.

---

From: Keith Knightson <[email-masked]>
Date: Wed, 11 Jun 2003 16:13:24 -0400

At 4:33 PM -0400 5/6/03, David Allan wrote:
If you're concatenating technologies together for SWIF, then yes the 
layers terminate. Its also a pain to interwork OAM protocols as the 
semantics may not match. The 17iw stuff assume we're interworking 
states of separate entities to get an overall view.

NIWF does have a better e2e story but as a pure overlay, you're just 
keeping the old game alive. Deploying old edge and new core.

cheers
Dave

Dave,

How can any customer know whether his path at the "layer" in question 
ends on a SIWF or a NIWF?

It seems probable me that a given customer may have several paths 
from his CE using exactly the same protocol stack to the PE, and 
depending on where and who provides the last PE, may in fact have 
some paths terminating on  a SIF and some on a NIF, depending a 
variety of intervening networks and access networks. What should he 
expect the semantics of his OAM to be?     I do not think it 
reasonable for the customer to know all the technical components in 
any or all paths from him to anywhere/everywhere.

Agreed all semantics may not map or be available.  That's the price of SIFs.

Cheers

Keith

---

From: "David Allan" <[email-masked]>
Date: Wed, 11 Jun 2003 16:48:05 -0400

Hi Keith:

<snipped>
> ends on a SIWF or a NIWF?

They don't.

> variety of intervening networks and access networks. 

Yes.

> What should he 

Definitely not. IMHO depending on the techology mix, you may be able to
propagate knowledge of problems but progressing further usually means using
tools local to the failed subnetwork.

> Agreed all semantics may not map or be available.  That's the 

Yep. I've seen proposals suggesting tools can interwork at the protocol
level between SIFs such that e2e diagnostics can be performed from anywhere
in the served area. Wasn't pretty and motivated my comments.

rgds
Dave