Subject: Koleyni and Bocci drafts

From: Jim Harford <[email-masked]>
Date: Wed, 19 Jun 2002 22:06:05 -0400

I have not seen any negative comments on the recently submitted Koleyni and 
Bocci drafts.  Are we to assume that the WG agrees that these drafts should 
be adopted as working text?

Jim Harford

---

From: "Walsh, Thomas D (Tom)" <[email-masked]>
Date: Thu, 20 Jun 2002 10:03:59 -0400

Hi Jim,

I think your statement is quite premature.  The cut off for new Internet
Drafts has not passed for the Yokohama meeting, nor the cutoff for updated
drafts. Last time I looked there were other views; not just those contained
in the Bocci and Koleyni drafts.

On the other hand, if your message was intended to solicit negative
comments, then let me express one now.  It is premature to adopt either the
Koleyni or Bocci drafts as working group documents at this time.  After all
the new drafts are available it would be appropriate to revisit your
question.

Regards,

Tom Walsh

-----Original Message-----
From: Jim Harford [mailto:[email-masked]]
Sent: Wednesday, June 19, 2002 10:06 PM
To: [email-masked]
Subject: [PWE3] Koleyni and Bocci drafts

Jim Harford

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

---

From: "Khalid Ahmad" <[email-masked]>
Date: Fri, 21 Jun 2002 10:36:28 -0400

Colleagues,

from the emails I have seen to this topic, I did not see any negative
comments to the Bocci and Koleyni drafts, and more importantly there have
been no technical issues raised.

In the email I sent some weeks ago summarizing some of the discussion
points, it was evident that there are different applications that are being
addressed here, and there is support for all of them.  These are:

1.  General cell based ATM/MPLS encap mechanism which enables multiplexed or
port mode transport as well.  This is described in the Martini draft
(updated version sent recently).

2.  Efficient (or compressed) cell based ATM/MPLS encap mechanism where
redundant VPI/VCI info is not needed to be transported for applications
which want to maximise efficiency.  This is described in the Koleyni AS
draft.

3.  Frame mode for AAL5 SDU encap mechanism for applications which require
efficient transport of AAL5 frames and may not need stringent OAM
transparency. This is described in the Martini drafts.

4.  Frame mode for AAL5 PDU encap mechanism for applications which require
stringent transparency and the complete AAL5 protocol control info to be
transported.  This is described in the Bocci AS draft.

The comments and discussions I saw indicated interest in all of these
applications and I would stress they are not mutually exclusive nor
technically conflicting.

Therefore it would seem perfectly appropriate to include all the above
drafts in the WG for consideration in the Yokohama meeting.  Excluding any
would simply be unfair and not in the interests of an open discussion. 

It seems Toms only "negative" comment in response to Jims question below is
to say it is premature at this stage.  

I would suggest that a more constructive way forward is to thoroughly
discuss all the above applications/mechanisms from both technical and
requirement perspectives in Yokohama meeting so folks are clear about the
issues involved.

Regards,
Khalid

-----Original Message-----
From: Walsh, Thomas D (Tom) [mailto:[email-masked]]
Sent: Thursday, June 20, 2002 10:04 AM
To: 'Jim Harford'; [email-masked]
Subject: RE: [PWE3] Koleyni and Bocci drafts

Hi Jim,

Regards,

Tom Walsh

-----Original Message-----
From: Jim Harford [mailto:[email-masked]]
Sent: Wednesday, June 19, 2002 10:06 PM
To: [email-masked]
Subject: [PWE3] Koleyni and Bocci drafts

Jim Harford

---

From: "Walsh, Thomas D (Tom)" <[email-masked]>
Date: Fri, 21 Jun 2002 11:04:30 -0400

Hi Khalid,
 
I agree all drafts should be included in the discussion.  As I said, since
the deadline is still open,  we don't yet know the full set of drafts on the
topic.  
 
My comment was directed toward Jim Harford's comment.  It is premature for
Jim to claim the WG agrees to make these WG drafts. 
 
Tom

-----Original Message-----
From: Khalid Ahmad [mailto:[email-masked]]
Sent: Friday, June 21, 2002 10:36 AM
To: Walsh, Thomas D (Tom); 'Jim Harford'; [email-masked]
Subject: RE: [PWE3] Koleyni and Bocci drafts

Colleagues, 

Regards, 
Khalid 

-----Original Message----- 
From: Walsh, Thomas D (Tom) [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, June 20, 2002 10:04 AM 
To: 'Jim Harford'; [email-masked] 
Subject: RE: [PWE3] Koleyni and Bocci drafts 

Hi Jim, 

Regards, 

Tom Walsh 

-----Original Message----- 
From: Jim Harford [ mailto:[email-masked] <mailto:[email-masked]>
] 
Sent: Wednesday, June 19, 2002 10:06 PM 
To: [email-masked] 
Subject: [PWE3] Koleyni and Bocci drafts 

Jim Harford 

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

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

---

From: [email-masked]
Date: Fri, 21 Jun 2002 16:20:41 +0100

Hi Khalid, see below (hope you had a nice holiday).  regards, Neil

-----Original Message-----
From: Khalid Ahmad [mailto:[email-masked]]
Sent: 21 June 2002 15:36
To: Walsh, Thomas D (Tom); 'Jim Harford'; [email-masked]
Subject: RE: [PWE3] Koleyni and Bocci drafts

Colleagues, 

NH=> Well, I have raised this point in the past, and will continue to so,
that the defect handling in *all* the drafts I have seen to date is either
inappropriate (ie layer violations or such) or (more usally) missing.  So as
far as I am concerned they are all still not fit for purpose.  Having said,
I am working though this with John Rutemiller and there should a draft soon
that is likely to get my/BT support.
<snipped to end NH>

---

From: "Khalid Ahmad" <[email-masked]>
Date: Fri, 21 Jun 2002 11:30:08 -0400

Hi Tom,
 
I had the understanding from some earlier email dicussions (related to the
MIB drafts, etc.) that adopting a draft as a WG draft was simply an enabler
to more wider discussion of the contents of that draft, and no way signified
agreement on the actual text.
 
This was implied by folks who are much more conversant with IETF processes
than I am, but it seems like a perfectly reasonable way to progress the
work.  It was in that sense I understood Jims question.
 
In any case I understand now all drafts to this topic will be discussed in
the meeting, since Danny has recently amended the agenda.  This is fine by
me.
 
Regards,
Khalid

-----Original Message-----
From: Walsh, Thomas D (Tom) [mailto:[email-masked]]
Sent: Friday, June 21, 2002 11:05 AM
To: Ahmad, Khalid [CAR:CS40:EXCH]; Walsh, Thomas D (Tom); 'Jim Harford';
[email-masked]

Hi Khalid,

 
Tom

-----Original Message-----
From: Khalid Ahmad [mailto:[email-masked]]
Sent: Friday, June 21, 2002 10:36 AM
To: Walsh, Thomas D (Tom); 'Jim Harford'; [email-masked]
Subject: RE: [PWE3] Koleyni and Bocci drafts

Colleagues, 

Regards, 
Khalid 

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

Hi Jim, 

Regards, 

Tom Walsh 

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

Jim Harford

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 21 Jun 2002 11:38:52 -0400

Hi,

>MIB drafts, etc.) that adopting a draft as a WG draft was simply an 
>enabler to more wider discussion of the contents of that draft, and no way 
>signified agreement on the actual text.

         Yes, that is generally how WG documents work at the IETF. By adopting
a draft, the WG agrees to the general approach and to work on the contents
of the draft.  The contents of the draft when it is first adopted is in no
way set in stone.

         --Tom

>the meeting, since Danny has recently amended the agenda.  This is fine by me.
>
>Regards,
>Khalid
>
>
>the deadline is still open,  we don't yet know the full set of drafts on 
>the topic.
>
>points, it was evident that there are different applications that are 
>being addressed here, and there is support for all of them.  These are:
>1.  General cell based ATM/MPLS encap mechanism which enables multiplexed 
>or port mode transport as well.  This is described in the Martini draft 
>which want to maximise efficiency.  This is described in the Koleyni AS draft.
>It seems Toms only "negative" comment in response to Jims question below 
>is to say it is premature at this stage.
>From: Walsh, Thomas D (Tom) 
>[<mailto:[email-masked]>mailto:[email-masked]]
>From: Jim Harford [<mailto:[email-masked]>mailto:[email-masked]]
><https://www1.ietf.org/mailman/listinfo/pwe3>https://www1.ietf.org/mailman/listinfo/pwe3 
>
>
><https://www1.ietf.org/mailman/listinfo/pwe3>https://www1.ietf.org/mailman/listinfo/pwe3 
>

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.

---

From: "Khalid Ahmad" <[email-masked]>
Date: Fri, 21 Jun 2002 11:55:43 -0400

Hi Neil,

yes, thanks I had great vacation(although the weather could have been better
!), and I agree with you we need to understand the defect handling/OAM
interworking issue clearer for the ATM/MPLS case.

I am still not so clear what means layer violation in this context, since in
my understanding the layer network modeling does not specifically address
interworked connections.

In my understanding this aspect is still open area of study and I hope we
can clarify it in ITU-T functional modeling context.  In any case I look
forward to your drafts with John R, and we should also discuss in Japan
meetings.

Regards,
Khalid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 21, 2002 11:21 AM
To: Ahmad, Khalid [CAR:CS40:EXCH]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] Koleyni and Bocci drafts

-----Original Message-----
From: Khalid Ahmad [mailto:[email-masked]]
Sent: 21 June 2002 15:36
To: Walsh, Thomas D (Tom); 'Jim Harford'; [email-masked]
Subject: RE: [PWE3] Koleyni and Bocci drafts

Colleagues,

---

From: [email-masked]
Date: Fri, 21 Jun 2002 17:30:02 +0100

Hi Khalid,
-----Original Message-----
From: Khalid Ahmad [mailto:[email-masked]]
Sent: 21 June 2002 16:56
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]

<snipped>

NH=> This is where a given technology (layer network) makes certain
assumptions/demands of either it's client layers or its server layers, and
thereore creates inter-layer linkages which hamper development/scope/usage
of technologies .....and in this context I mean wrt to data-plane
fault-detection/handling mecahnisms.  In Jeremy's orginal draft we had a
very obvious layer violation of asking L1 SDH/Sonet FDI to proxy for not
being able to handle this at the ATM layer in port mode....John/I are
discussing a way to handle this....not perfect but more clean.  Asking IP's
ICMP to proxy for missing MPLS fault handling is another layer violation.
The former is  a server layer violation and the latter is a client layer
violation.  That's the sort of issues I meant...it's simply bad
network/protocol architecture.  However, for most cases this area is simply
not adequately addressed in any of the drafts.    
regards, Neil
<snipped to end NH>

---

From: "Khalid Ahmad" <[email-masked]>
Date: Fri, 21 Jun 2002 12:47:19 -0400

Hi Tom,

many thanks for this clarification on the process.

Regards,
Khalid

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Friday, June 21, 2002 11:39 AM
To: Ahmad, Khalid [CAR:CS40:EXCH]
Cc: Walsh, Thomas D (Tom); Walsh, Thomas D (Tom); 'Jim Harford';
[email-masked]

         Hi,

>signified agreement on the actual text.

         Yes, that is generally how WG documents work at the IETF. By
adopting
a draft, the WG agrees to the general approach and to work on the contents
of the draft.  The contents of the draft when it is first adopted is in no
way set in stone.

         --Tom

me.
draft.

---

From: "Khalid Ahmad" <[email-masked]>
Date: Fri, 21 Jun 2002 13:20:20 -0400

Hi Neil,

thanks for the clarification.  Yes, I agree that for the two cases you cite
(port/ SDH and ICMP/MPLS) there is an obvious inconsistancy. The ITU-T work
on Recommendation Y.1711 will help in the case of MPLS defect handling
functions, so we need that as basis.

My point was more general. In my understanding layer network functional
modeling (a la G.805 / I.326)does not address interworking connectivity, and
there is currently no accepted functional model for ATM/MPLS interworked
connections for defect handling and consequent actions to layer management
(in the sense of Rec. I.732 for ATM case).

At one stage, Mina and I did some work on a detailed functional model for
ATM/MPLS interworking based on I.732 representation (and I think John R was
also involved ), but we never got round to submitting it. I think it would
be useful to have one, so we can clearly see where any layer violations
occur. 

We will think on it.

Regards,
Khalid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 21, 2002 12:30 PM
To: Ahmad, Khalid [CAR:CS40:EXCH]; [email-masked];

Hi Khalid,
-----Original Message-----
From: Khalid Ahmad [mailto:[email-masked]]
Sent: 21 June 2002 16:56
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]

<snipped>

---

From: "Khalid Ahmad" <[email-masked]>
Date: Fri, 21 Jun 2002 14:34:08 -0400

Hi Neil,

thinking further on the two examples of layer violation you mention below,
it seems to me the fundamental issue you are alluding to here is related to
the general OAM principle that defect handling/alarm suppression should be
propagated upwards (not downwards) in a layer model.

I seem to recall this principle is embodied in the ITU-T M. series (M.3000,
3030 etc.) recs., and is certainly followed in the SDH /OTN/ATM functional
models. I would assume MPLS would also need to follow this general
principle.

In the case of interworked connectivity, where OAM functions may differ on
either side of the IWF entity, consequent actions related to encapsulation
or mapping of OAM layer management functions needs to be defined.  

But I would assume the same general OAM principle would apply: Fault
management indications propagate upwards to the next layer, and not
downwards to the server layer.

Am I right in assuming this?

Regards,
Khalid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 21, 2002 12:30 PM
To: Ahmad, Khalid [CAR:CS40:EXCH]; [email-masked];

Hi Khalid,
-----Original Message-----
From: Khalid Ahmad [mailto:[email-masked]]
Sent: 21 June 2002 16:56
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]

<snipped>

---

From: [email-masked]
Date: Sat, 22 Jun 2002 08:35:05 +0100

Hi Khalid,

-----Original Message-----
From: Khalid Ahmad [mailto:[email-masked]]
Sent: 21 June 2002 19:34
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]

Hi Neil, 
thinking further on the two examples of layer violation you mention below,
it seems to me the fundamental issue you are alluding to here is related to
the general OAM principle that defect handling/alarm suppression should be
propagated upwards (not downwards) in a layer model.
NH=> Well yes, I would hope that is obvious to everyone.....if a failure
occurs at layer X in a given technology then:
-	there must be some way to tell the higher layer client networks of
the affected layer X trail *not* to raise alarms (otherwise we can get
massive alarms storms that may be both organisationally and geographically
disjoint from the true failure source.....which would be a nightmare for Ops
people)
-	there must be no impact on lower layer networks as they are still
working fine....and trying to 'turn-on' their defect handling functions to
proxy for such functionality missing in the affected higher layer is simply
not acceptable (and besides confusing Ops people again it might invoke
unecessary prot-sw, and in general it simply won't work properly....as the
trails in question will rarely be span-congruent, ie a link connection in
layer N = trail in layer N-1....this is how we construct a client layer
topology).

I seem to recall this principle is embodied in the ITU-T M. series (M.3000,
3030 etc.) recs., and is certainly followed in the SDH /OTN/ATM functional
models. I would assume MPLS would also need to follow this general
principle.
NH=> Well it will if manufacturers want operators (like BT) to adopt MPLS
more widely and if it is to realise its potential as a L2 convergence
technology.  In trad operators like BT we have huge sunk investments in
ATM/SDH (and these platforms are still growing heathily) so stds
bodies/manufacturers would be wise to take careful note of this.....esp in
the current climate of our industry.  Operators like BT will demand the
behaviour I am alluding to above for XoverMPLS (and that's why many wanted,
and helped develop, Y.1711 )......this is not rocket science or something
weird, this is pretty obvious/basic stuff and is exactly how the network
technologies you mention function today.

In the case of interworked connectivity, where OAM functions may differ on
either side of the IWF entity, consequent actions related to encapsulation
or mapping of OAM layer management functions needs to be defined.
NH=> Yes.  Its quite important to understand the relationships involved
however.  A simple/true client/server (ie full encapsulation) relationship
is quite different to true protocol-conversion......sometimes badly termed
(IMO) as 'network' and 'service' interworking respectively.  In the former
case the client trails span across the lower server layer and are fully
transparent to the lower server layer, whilst in the latter case the trails
terminate at the IWF (and its something else/higher that goes 'end-end'), eg
the AAL5 mode is close to this latter model.  The required defect handling
behaviour is very different in these 2 cases, eg in the true client/server
case a failure of the server must result in some form of FDI to the
client(s), whilst in the prot-conv case a failure of the 'middle' technology
trail (ie between IWFs) must *not* result in FDI to the layer network trails
either side of the IWF but only to the higher trails that are common (and
span both) technologies......in the case of AAL5 an FDI function has never
been specified (AFAIK), but even just recognising this stops us doing the
wrong things at the lower layers.
   
NH=> Yes of course Khalid.....see my first set of comments above.

regards, Neil

---

From: [email-masked]
Date: Sat, 22 Jun 2002 08:35:02 +0100

Hi Khalid,

-----Original Message-----
From: Khalid Ahmad [mailto:[email-masked]]
Sent: 21 June 2002 18:20
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]

Hi Neil, 
thanks for the clarification.  Yes, I agree that for the two cases you cite
(port/ SDH and ICMP/MPLS) there is an obvious inconsistancy. The ITU-T work
on Recommendation Y.1711 will help in the case of MPLS defect handling
functions, so we need that as basis.
NH=> Obviously I agree.  Operators will require *something* like
Y.1711.....and whatever we do it will have to provide similar functionality
to Y.1711 (though Y.1711 is about as simple as you can get based on plenty
of experience on this topic).  I know of several manufacturers who are
implementing this and we will have some in our labs for testing later this
year.
 
My point was more general. In my understanding layer network functional
modeling (a la G.805 / I.326)does not address interworking connectivity, and
there is currently no accepted functional model for ATM/MPLS interworked
connections for defect handling and consequent actions to layer management
(in the sense of Rec. I.732 for ATM case).
NH=> Agreed.  People are working on this however.  Maarten Vissers, who is
pretty hot on this area as you know, is already looking at it.  We too have
people who are looking at it.  However, I think the principle of not
requiring the data-plane fault management mechanisms of technology/layer X
to be dependent on the data-plane fault management mecahnisms of a
(different) technology/layer Y (either client or server to X) should be
obvious in itself, and no stds bodies worthy of the name ought to sanction
such dependancies.....in other words, one does not need functional models to
see/agree-with the truth of this observation.

regards, Neil
<snipped to end NH>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 24 Jun 2002 11:58:32 +0200

Khalid, Neil,

G.805 03/2000 contains a section 5.5 on layer network interworking. This
describes what is referred to in FR/ATM interworking as "service interworking".
The other "interworking" case referred to as "network interworking" isn't a real
interworking case... it is a straight client/server case.

So, if an ATM VP is transported as is over an MPLS trail, then MPLS is just
another Transmission Path layer, and all ATM requirements for TP/ATM_A_So and
TP/ATM_A_Sk in I.732 apply to MPLS/VP_A. ATM VP is then a client layer of the
MPLS layer.

       -------------------------------------------
       |                  VP_C                   |
       -------------------------------------------
	|||||||		 |||||||
	TP/VP_A		MPLS/VP_A
	   |		    |
	 TP_TT		 MPLS_TT
	   |		    |	     ||||||||||||||||||
	        	----------------------------------
	    		|           MPLS_C               |
			----------------------------------
	    			|||||||||||||||||||

If ATM VC is transported as is over an MPLS trail, then the MPLS is just another
version of the ATM VP layer. ATM VC is then a client layer of the MPLS layer.
The ATM VC requirements for VP/VC_A_So and VP/VC_A_Sk in I.732 apply to
MPLS/VC_A.

       -------------------------------------------
       |                  VC_C                   |
       -------------------------------------------
	|||||||		 |||||||
	VP/VC_A		MPLS/VC_A
	   |		    |
	 VP_TT		 MPLS_TT
	   |		    |	     ||||||||||||||||||
	TP/VP_A		----------------------------------
	   |		|           MPLS_C               |
	 TP_TT		----------------------------------
	   |			|||||||||||||||||||

If ATM VP is continued as an MPLS signal (case of service interworking), then
the ATM VP characteristic information is to be continued as MPLS characteristic
information as described in 5.5/G.805. This implies that the VP OAM is converted
into MPLS OAM and the VP payload is continued as MPLS payload (and vice versa).

	|---------VP<>MPLS(VC)---------|
	||--------VP<>MPLS(VC)--------||
	|||-------VP<>MPLS(VC)-------|||
	||||------VP<>MPLS(VC)------||||
	|||||-----VP<>MPLS(VC)-----|||||
	||||||----VP<>MPLS(VC)----||||||
        |||||||---VP<>MPLS(VC)---|||||||
	|||||||			 |||||||
	TP/VP_A		----------------------------------
	   |		|           MPLS_C               |
	 TP_TT		----------------------------------
	   |			|||||||||||||||||||

If ATM VC is continued as an MPLS signal (case of service interworking), then
the ATM VC characteristic information is to be continued as MPLS characteristic
information as described in 5.5/G.805. This implies that the VC OAM is converted
into MPLS OAM and the VC payload is continued as MPLS payload (and vice versa).

	|---------VC<>MPLS(AAL)---------|
	||--------VC<>MPLS(AAL)--------||
	|||-------VC<>MPLS(AAL)-------|||
	||||------VC<>MPLS(AAL)------||||
	|||||-----VC<>MPLS(AAL)-----|||||
	||||||----VC<>MPLS(AAL)----||||||
        |||||||---VC<>MPLS(AAL)---|||||||
	|||||||			  |||||||
	VP/VC_A		----------------------------------
	   |		|           MPLS_C               |
	 VP_TT		----------------------------------
	   |			|||||||||||||||||||
	TP/VP_A
	   |
	 TP_TT

Regrads,

Maarten

> Khalid Ahmad wrote:
> (port/ SDH and ICMP/MPLS) there is an obvious inconsistancy. The ITU-T work on
> Recommendation Y.1711 will help in the case of MPLS defect handling functions,
> so we need that as basis.
> 
> connections for defect handling and consequent actions to layer management (in
> the sense of Rec. I.732 for ATM case).
> 
> also involved ), but we never got round to submitting it. I think it would be
> useful to have one, so we can clearly see where any layer violations occur.
> 
> We will think on it.
> 
> Regards,
> Khalid
>

---

From: "Khalid Ahmad" <[email-masked]>
Date: Mon, 24 Jun 2002 13:04:40 -0400

Hi Neil,

yes, I agree with your comments re the OAM interworking principles.  While
it seems clear that the OAM IW may differ in the case of "network" and
"service" IW in general, there are commonalities.  This became apparent when
we were considering the case of FR/ATM IW in I.555 etc.

The basic client/server model is necessary but not sufficient.  One stil has
to consider the question of what is the overall maintainence entity being
managed.  One possibility is the end-end interworked connection and not just
the individual segments.

Regards,
Khalid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, June 22, 2002 3:35 AM
To: Ahmad, Khalid [CAR:CS40:EXCH]; [email-masked];

Hi Khalid,

-----Original Message-----
From: Khalid Ahmad [mailto:[email-masked]]
Sent: 21 June 2002 19:34
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]

Hi Neil, 

   

regards, Neil

---

From: "Khalid Ahmad" <[email-masked]>
Date: Mon, 24 Jun 2002 13:28:27 -0400

Hi Maarten,

thanks for your clarifications, but I have difficulty with your statement
that ..."network" IW isnt "real" interworking...it is a straight
client/server case.  I dont know what this means, but I do know that when
connectivity spans two (or more) different technologies, we generally refer
to it as interworking.

The modeling you depict below is useful in representing the interworking
between ATM and MPLS, but it does not change the basic distinction that was
identified between what is called network interworking and service
interworking in the sense of the I.500 series recommendations.

I think we are not just talking about multiplex hierarchies here, but
different packet mode technologies.

I am of course in favour of modeling this more precisely as you are
proposing, but the underlying mechanisms do not change, I hope!

Regards,
Khalid

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, June 24, 2002 5:59 AM
To: Ahmad, Khalid [CAR:CS40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [PWE3] Koleyni and Bocci drafts

Khalid, Neil,

G.805 03/2000 contains a section 5.5 on layer network interworking. This
describes what is referred to in FR/ATM interworking as "service
interworking".
The other "interworking" case referred to as "network interworking" isn't a
real
interworking case... it is a straight client/server case.

So, if an ATM VP is transported as is over an MPLS trail, then MPLS is just
another Transmission Path layer, and all ATM requirements for TP/ATM_A_So
and
TP/ATM_A_Sk in I.732 apply to MPLS/VP_A. ATM VP is then a client layer of
the
MPLS layer.

If ATM VC is transported as is over an MPLS trail, then the MPLS is just
another
version of the ATM VP layer. ATM VC is then a client layer of the MPLS
layer.
The ATM VC requirements for VP/VC_A_So and VP/VC_A_Sk in I.732 apply to
MPLS/VC_A.

If ATM VP is continued as an MPLS signal (case of service interworking),
then
the ATM VP characteristic information is to be continued as MPLS
characteristic
information as described in 5.5/G.805. This implies that the VP OAM is
converted
into MPLS OAM and the VP payload is continued as MPLS payload (and vice
versa).

If ATM VC is continued as an MPLS signal (case of service interworking),
then
the ATM VC characteristic information is to be continued as MPLS
characteristic
information as described in 5.5/G.805. This implies that the VC OAM is
converted
into MPLS OAM and the VC payload is continued as MPLS payload (and vice
versa).

Regrads,

Maarten

> connections for defect handling and consequent actions to layer management
(in
> also involved ), but we never got round to submitting it. I think it would
be

---

From: [email-masked]
Date: Mon, 24 Jun 2002 22:09:09 +0100

Hi Maarten.....see in-line...regards, Neil

> Sent: 24 June 2002 10:59
> To: Khalid Ahmad
NH=> Not sure who came up with these terms but they are really poor at
conveying the real arch behvaiour of the 2 cases.  There is prot-conv and
client/server I/W for the data-plane, and similar considerations also apply
for the control-plane.  Restricting attention to data-plane, in both
prot-conv and client/server cases one *must* take dynamic defect handling
into account...but they are quite different (see my recent posting to Khalid
on this).
> TP/ATM_A_Sk in I.732 apply to MPLS/VP_A. ATM VP is then a 
NH=> Correct.  But it still requires that MPLS defects get mapped to correct
ATM VP/VC FDI at LSP trail term points.
NH=> Yes
NH=> This is *not* yet defined......though it does offer up some interesting
evolution issues.
> into MPLS OAM and the VP payload is continued as MPLS payload 
NH=> I agree the payload should be carried over transparently.....in fact
this 'payload' represents the common end-end trail that spans both ATM/MPLS
regions.  This could be AAL5 for example. However, the ATM cell level OAM
has no relevance to the MPLS OAM (these are kept disjoint since at this
level the network trails are peers).  Also see my response to Khalid.
<snipped to end NH>

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 25 Jun 2002 12:09:45 +0200

Khalid,

> Khalid Ahmad wrote:
> 
> Hi Maarten,
> 
> thanks for your clarifications, but I have difficulty with your statement that
> ..."network" IW isnt "real" interworking...it is a straight client/server
> case.  I dont know what this means, but I do know that when connectivity spans
> two (or more) different technologies, we generally refer to it as
> interworking.

The reason I stated this is that in the transport world of SDH we transport e.g.
a VC-11 via a VC-3 and via a VC-4; when doing so we do not speak about
interworking despite that the VC-3  trail is terminated, the VC-11 extracted and
then mapped/muxed into the VC-4 trail.

For the case of ATM and MPLS, a set of ATM VP signals arrives over e.g. a VC-4
trail. This VC-4 trail is terminated, the ATM VP signals are extracted and then
mapped/muxed into a MPLS trail. Why should this be called interworking? A
similar case in which ATM VP signals arrive via a VC-4 trail and leave via a
VC-4-4c trail isn't referred to as interworking either. In both cases, the
server layer trail is different (VC-4/MPLS, VC-4/VC-4-4c).

> interworking in the sense of the I.500 series recommendations.

The modeling is to support this basic distinction.

> I am of course in favour of modeling this more precisely as you are proposing,
> but the underlying mechanisms do not change, I hope!

No change of the underlying mechanisms. 

Network interworking is:
- terminating server trail (e.g. VC-4), 
- demuxing the client signals (e.g. ATM VP), 
- cross connecting the individual client signals (e.g. ATM VP), 
- muxing these client signals (e.g. ATM VP), 
- generating new server trail (e.g. MPLS).
This includes that a (server trail) signal fail results in individual client
signal AIS/FDI indications.

Service interworking is:
- converting trail type 1 into trail type 2 (e.g. ATM VP <-> MPLS)
- including continuation of trail type 1 OAM/OH as trail type 2 OAM/OH (and vice
versa) (e.g. ATM VP OAM continued as MPLS OAM, and vice versa)
- including continuation of trail's payload as one stream, no individual client
signals are recognised (e.g. stream of ATM VC signals).
I.e. the trail isn't terminated, it is continued in a different format. A signal
fail condition now interrupts to (hybrid e.g. "ATM VP-MPLS") trail and is
indicated by means of the appropriate trail's AIS/FDI indication (e.g. ATM VP
AIS/MPLS FDI). Note that if MPLS trail in this case terminates, the individual
ATM VC signals (in this example) become available and the MPLS FDI signal must
continue as ATM VC AIS signals.

Regards,

Maarten

> on

---

From: "Khalid Ahmad" <[email-masked]>
Date: Tue, 25 Jun 2002 16:08:42 -0400

Hi Maarten,

well, as I mentioned before, in the ATM/MPLS (or other)interworking case we
are not talking about SDH multiplex heirarchies, but about various types of
protocol conversion between different packet modes.  So use of the word
'interworking' seems perfectly legitimate to me (although I know some people
dont like it) !

For folks not so familiar with ITU-T SG 15 transmission terminology, I would
point out that the term "Trail" = "Connection".  Maartens comments should be
read with this translation in mind.

For folks not so familiar with ITU-T SG 13 ATM terminology, I would point
out that the terms "VC" or "VP" are not defined as far as ATM is concerned.
I think they mean "VCC" (or "VPC"). Also the terms VC level, or VP level,
have significance in I.732 context.  

Also VC Link (VCL) and VP Link (VPL) are defined as basic entities in ATM.

Sorry to be so pedantic, but its difficult enough to follow this stuff even
if we dont get all our terminology mixed up !

Regards,
Khalid

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, June 25, 2002 6:10 AM
To: Ahmad, Khalid [CAR:CS40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked];

Khalid,

> thanks for your clarifications, but I have difficulty with your statement
that
> two (or more) different technologies, we generally refer to it as

The reason I stated this is that in the transport world of SDH we transport
e.g.
a VC-11 via a VC-3 and via a VC-4; when doing so we do not speak about
interworking despite that the VC-3  trail is terminated, the VC-11 extracted
and
then mapped/muxed into the VC-4 trail.

For the case of ATM and MPLS, a set of ATM VP signals arrives over e.g. a
VC-4
trail. This VC-4 trail is terminated, the ATM VP signals are extracted and
then
mapped/muxed into a MPLS trail. Why should this be called interworking? A
similar case in which ATM VP signals arrive via a VC-4 trail and leave via a
VC-4-4c trail isn't referred to as interworking either. In both cases, the
server layer trail is different (VC-4/MPLS, VC-4/VC-4-4c).

> I am of course in favour of modeling this more precisely as you are
proposing,

Network interworking is:

Service interworking is:
- converting trail type 1 into trail type 2 (e.g. ATM VP <-> MPLS)
- including continuation of trail type 1 OAM/OH as trail type 2 OAM/OH (and
vice
versa) (e.g. ATM VP OAM continued as MPLS OAM, and vice versa)
- including continuation of trail's payload as one stream, no individual
client
signals are recognised (e.g. stream of ATM VC signals).
I.e. the trail isn't terminated, it is continued in a different format. A
signal
fail condition now interrupts to (hybrid e.g. "ATM VP-MPLS") trail and is
indicated by means of the appropriate trail's AIS/FDI indication (e.g. ATM
VP
AIS/MPLS FDI). Note that if MPLS trail in this case terminates, the
individual
ATM VC signals (in this example) become available and the MPLS FDI signal
must
continue as ATM VC AIS signals.

Regards,

Maarten

and
the
layer.
then
then