Subject: RE: PWE Service interworking

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

Sasha,

--- Sasha Vainshtein <[email-masked]> wrote:
> 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.

I agree, Shahram got it right (even mention one
letter.number standard), though curious about how he
sees PW playing in all this.

> 
> 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.

MS=> See below as well as my response to Shahram

> 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?
> 

MS=> No, you did not miss something. This is in
essence one of the concerns I was raising when I
previously asked whether encap authors had considered
the service interworking case - though clearly I had
not formulated or articulated my thoughts properly.
This is I think also the same as the concern which has
sometimes been articulated as "..every encap author
doing their work independent of the others.." i.e. no
generalized format for interworking encaps.

So it is one of those things like inter-AS work, it is
good to put it off because it helps you to break down
the problem, but it is bad to put to off because as a
result, you don't actuallt see the long-term problem
for what it is.

Mark

---

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

Then what group/organization is going to take on the interworking and all of
the issues ?

PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY

> -----Original Message-----
> 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]
> Subject: RE: [PWE3] PWE Service interworking
>
>
> Shahram, Mark and all,
> 1. I agree with Shahram that the model he has proposed
>    "explanation email". To me, this makes it preferable.
>
>       	The PSN can transport PDUs for multiple services,
>    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)
> 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: Wednesday, June 04, 2003 4:42 PM
> > To: 'Mark Seery'; [email-masked]
> > Subject: RE: [PWE3] PWE Service interworking
> >
> >
> > 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
> >
> >
> > >-----Original Message-----
> > >From: Mark Seery [mailto:[email-masked]]
> > >Sent: Tuesday, June 03, 2003 5:01 PM
> > >To: [email-masked]
> > >Subject: Re: [PWE3] PWE Service interworking
> > >
> > >
> > >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
> > >=====================
> > >
> > >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
> > >_______________________________________________
> > >pwe3 mailing list
> > >[email-masked]
> > >https://www1.ietf.org/mailman/listinfo/pwe3
> > >
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>