Subject: New PWE3 Charter Items: SPVC Interworking

From: George Swallow <[email-masked]>
Date: Thu, 19 Feb 2004 13:27:03 -0500

I'd like to see us add SPVC interworking to our charter.  

In talking to a fair number of service providers I've gotten the message
that deploying PWE3 is a bit of a non-starter without a reasonable
migration plan.  I think we would be foolish to leave this piece to some
other organization or to vendor proprietary means.

....George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

---

From: John Drake <[email-masked]>
Date: Thu, 19 Feb 2004 10:41:21 -0800

Good idea

> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: Thursday, February 19, 2004 10:27 AM
> To: [email-masked]
> Subject: [PWE3] New PWE3 Charter Items: SPVC Interworking
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: George Swallow <[email-masked]>
Date: Thu, 19 Feb 2004 13:56:36 -0500

For those of you who weren't at the last IETF, what I'm talking aabout
is covered in draft-swallow-pwe3-spvc-iw-00.txt.

The issue is that service providers which offer Frame Relay and ATM SPVC
services would like a smooth means of migrating users to MPLS/PWE3.
During the transition there will be the need to connect access circuits
which have one end attached to the existing FR/ATM net and the other to
a PWE3 PE.  The providers would like a more elegant solution than just a
static splice.  This is needed to simplify configuration and operations
and to provide robustness during the transition.  Some providers are
looking at transitions that will occur over a period of years.

...George

---

From: "Monique Morrow (mmorrow)" <[email-masked]>
Date: Fri, 20 Feb 2004 08:10:48 +0100

Fully support this!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
George Swallow (swallow)
Sent: 19 February 2004 19:27
To: [email-masked]
Subject: [PWE3] New PWE3 Charter Items: SPVC Interworking

....George

---

From: [email-masked]
Date: Fri, 20 Feb 2004 10:21:32 +0000

George,

I agree with this, but I think that we need to be careful to scope this
problem appropriately.

I agree that the scenario that you describe in your draft, which is also
addressed by draft-watkinson-l2vpn-pnni-psn-framework-00.txt, is very
important in the transition and is not yet being fully addressed by other
bodies. In this case, the SPVC terminates on the PME.  There is new work to
be done here.

However, this should be distinguished from the case where there are SPVCs
extending between ATM networks on either side of the PSN. Here, the SPVC
(and incidentally SVCs) can terminate in the ATM networks on either side,
and not necessarily on the PME. ATM routing (PNNI) can also be
transparently extended between the ATM networks on either side. This has
been specified at the ATM Forum, and is described in
draft-bocci-l2vpn-pnni-mpls-iw-00.txt. This works for all of the different
ATM PW types that PWE3 has described. I don't think there is anything new
that PWE3 needs to do here.

Best regards,

Matthew

|---------+--------------------------->
|         |           George Swallow  |
|         |           <[email-masked]|
|         |           om>             |
|         |           Sent by:        |
|         |           pwe3-admin@ietf.|
|         |           org             |
|         |                           |
|         |                           |
|         |           19/02/2004 18:56|
|         |                           |
|---------+--------------------------->
  >-------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                               |
  |        To:                                                                                                                    |
  |        cc:      [email-masked], [email-masked]                                                                              |
  |        Subject: Re: [PWE3] New PWE3 Charter Items: SPVC Interworking                                                          |
  >-------------------------------------------------------------------------------------------------------------------------------|

...George

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 20 Feb 2004 09:57:16 -0500

I don't think we should add SPVC interworking to the charter:

a)	It is a significant departure from the current, narrow scope of PWE3

b) 	The ATM Forum and the MPLS Frame Relay Alliance are already working on issues related to ATM-MPLS Control Plane Interworking.

You write: "I think we would be foolish to leave this piece to some other organization". Personally, I think it is more foolish, and harmful, to address the same issue in two different standards organizations, if you can avoid it.

Peter

> Sent: Thursday, February 19, 2004 1:27 PM
> To: [email-masked]

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Fri, 20 Feb 2004 12:08:19 -0500

George,

> In talking to a fair number of service providers I've gotten 
> the message that deploying PWE3 is a bit of a non-starter 
> without a reasonable migration plan.  

I do agree that this item is of practical significance and needs 
to be addressed here or elsewhere. 

Though to be honest since this is about control
plane "Interworking", and since we had previous history in 
pwe3 and l2vpn wgs on similar items related to "Interworking", 
I am not sure that this time this item will be considered within the 
scope of ietf. 

Actually this is a good opportunity for the ADs/IESG to clarify
what forms of interworking (data/control) are actually within scope
of ietf, what forms are clearly outside the scope
(for reasons outside pwe3 wg for example). 

> I think we would be 
> foolish to leave this piece to some other organization or to 
> vendor proprietary means.
> 

Humm...to be fair I think some other organization started looking
at these migration and interworking problems because there was
a belief that they are needed in practice (for example as part 
of a reasonable migration plan) but they were considered out 
of scope within the ietf. 

Hamid.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 20 Feb 2004 12:29:09 -0500

I agree with Hamid's concern.

IESG must determine first if 'interworking'
as such is within IETF scope or not.

/himanshu

> From: Hamid Ould-Brahim [mailto:[email-masked]]
> Sent: Friday, February 20, 2004 12:08 PM
> To: George Swallow; [email-masked]
> Subject: RE: [PWE3] New PWE3 Charter Items: SPVC Interworking
> 
> 
> George,
> 
> > 
> >

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Sun, 22 Feb 2004 16:09:18 -0600

I also support this.

Jerry

-----Original Message-----
From: George Swallow [mailto:[email-masked]]
Sent: Thursday, February 19, 2004 1:27 PM
To: [email-masked]
Subject: [PWE3] New PWE3 Charter Items: SPVC Interworking

....George

---

From: [email-masked]
Date: Mon, 23 Feb 2004 16:31:40 -0000

> the message

We have discussed the topic of service interworking extensively within BT, and we agree that it is an important facet of a service providers migration plan towards a converged multi-service core network. Service interworking must consider all aspects of the data-plane, control-plane and NMS/OSS for all the technologies considered (and it is therefore more far-reaching than just S-PVC considerations).

However, we do not believe the IETF is the appropriate forum for conducting this work.  Our reasons for saying this are that draft-alvestrand-ietf-mission-00.txt states:
"The mission of the IETF is to produce high quality, relevant technical and engineering documents that influence the way people design, use and manage the Internet in such a way as to make the Internet work better."

It then defines the scope of the Internet as:
"protocols and practices for which secure and scalable implementations are expected to have wide deployment and interoperation on the Internet, or to form part of the infrastructure of the Internet."  

We therefore believe that the general interworking of technologies such as FR, ATM, ethernet, SDH, etc:
-	is not applicable to the Internet,
-	will not have wide deployment on the Internet, and
-	will not form part of the infrastructure of the Internet

Therefore the topic of service interworking is out of scope of the IETF and thus also out of scope of the PWE3 WG.

Ben

-- 
Ben Niven-Jenkins
IP Networking Specialist, BT Exact

e-mail: [email-masked]
tel: +44(0) 1473 648225
fax: +44(0) 1473 620109

pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, UK

BT Exact is a trademark of British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 23 Feb 2004 19:13:22 +0200

I concur with that.

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: Scott W Brim [mailto:[email-masked]]
> Sent: Monday, February 23, 2004 7:06 PM
> To: [email-masked]
> Subject: Re: [PWE3] New PWE3 Charter Items: SPVC Interworking
> 
> 
> On Mon, Feb 23, 2004 04:31:40PM -0000, 
> [email-masked] allegedly wrote:
> > We therefore believe that the general interworking of 
> technologies such as FR, ATM, ethernet, SDH, etc:
> > Therefore the topic of service interworking is out of scope 
> of the IETF and thus also out of scope of the PWE3 WG.
> 
> My personal opinion: I think interworking had better be in 
> scope or the
> IETF will leaving it out rather soon.  Issues in interworking of FR,
> ATM, etc. are not IETF issues ... except where they imply requirements
> for IETF technology, including pseudowires.  That includes 
> this case.  I
> would not want the IETF to decide how to translate service parameters
> between pseudowire client technologies (and it hasn't), but
> establishment and management of pseudowires goes far beyond that.
> Finally, because of the IETF's long history with Ethernet, it should
> continue to be involved there as well.
>

---

From: [email-masked]
Date: Tue, 24 Feb 2004 17:00:37 -0000

> > the general interworking of technologies such as FR, ATM, ethernet, SDH

> Certainly the  interworking of these  technologies with each other  would be
> out of scope of the IETF.

> I think what  is being discussed though is the interworking  of one of these
> technologies, at a network boundary,  with a PWE3-based emulation of itself.
> That's a bit more difficult to  rule out based on abstract considerations of
> the IETF mission.

Why would the group responsible for the *emulation* of a particular network technology, be better suited to work on the interworking of that technology with an "emulation of itself", than the group actually responsible for the *design & development* of that technology?

Richard

---

From: [email-masked]
Date: Wed, 25 Feb 2004 10:04:41 -0000

Mustapha,
> Mustapha Aissaoui wrote 24 February 2004 20:00
 
> Scott and Richard,
> both the ATM Forum and IETF should be interested in this 
> work. There are
> hopefully enough experts of both ATM and IP/MPLS who attend 
> the PWE3 working
> group to have this work done here. I do not think it is worth 
> debating which
> body should own it as long as there is a liaison and 
> communication between
> the two bodies. If the IESG decides that this is out of scope 
> of the IETF,
> then we should take it to the ATM Forum.
NH=> I think its bigger than this.  We want to see a stronger respect for the functional architecture principles of G.805/809.  There are many reasons we want this, but a key one is that these func arch models form the bedrock of the network management information models for our NMS/OSS.  So its quite important to us.

Further, we believe that generic arch principles for client/server i/w (aka network i/w) and peer-partition i/w (aka service i/w) should be defined 1st irrespective of the specific technologies involved.  The arch principles are not the same in these 2 i/w cases.  Further, these relationships are affected by (i) the networking mode of the technology considered, ie whether cl-ps, co-ps, or co-cs, and (ii) how well a given technology is functionally specified.

Just taking the simpler client/server case for now, this is what we believe must hold here:
(i)	client and server layers must be independent in all aspects of the data and control planes.  This is required since the client and server layer networks can be owned by different parties.
(ii)	the client (all aspects) must be transparent to the server layer.  Some folks also refer to this as 'the principle of minimum intervention'. 
(iii)	defects detected at the trail termination point of the server layer network must be mapped to a FDI (Forward Defect Indication), in whatever syntax is relevent to the client, at the server->client adaptation function and for all clients affected.  This is to inform client that the defect is not in their layer network and thus stops alarm storms in clients.

We don't believe the current PWE3 drafts on client/server relationships meet the above requirements.....I can provide an extensive list of stuff we feel is wrong here, and we have raised these issues on the lists in the past but they have been ignored.

The original driver for the PWE3 work was from SPs who did not have native ATM, FR, etc technology networks but who, nevertheless, wanted to offer their carriage as services to customers over either an IP or MPLS server layer network.  Well, that's OK I guess, but when it gets a bit more serious such that MPLS (not PWs please note) is being touted as the convergence technology for most SPs (inc BT) then (i) we want to make sure MPLS is correctly/adequately functionally specified and (ii) that the X/MPLS i/w relationships are correctly specified.

In particular, we don't think any single SDO should try and claim 'ownership' of this topic.  And as noted, we want to start from a basis of respecting G.805/809 func arch principles.

regards, Neil

---

From: [email-masked]
Date: Wed, 25 Feb 2004 16:52:03 -0000

> I support this topic to become a part of the charter, as we 
> have heard the
> similar concerns from the carriers.
> 

As the justification for this work to be added to the PWE3 charter is that 'service providers/carriers' are asking for it, why aren't the same service providers/carriers voicing public support for the work on the list?  Where are the service provider/carrier requirements that dictated the proposed solution (or do they remain in private like the SPs themselves)?

As stated previosuly, I am (and BT is) against this work being added to the PWE3 charter.

Ben

---

From: Mustapha Aissaoui <[email-masked]>
Date: Wed, 25 Feb 2004 13:46:12 -0500

Neil,
I believe the best place to do the overal architecture work is in
ITU. 
What we are talking here about is the signaling interworking of
PNNI/AINI and LDP for SPVCs mainly. This can be used in both the
network interworking and the service interworking models as
explained in draft-watkinson-l2vpn-pnni-psn-framework-00.txt.

Mustapha.
------------

---

From: [email-masked]
Date: Thu, 26 Feb 2004 12:06:49 -0000

Hi Mustapha,

Mustapha Aissaoui wrote 25 February 2004 18:46
> I believe the best place to do the overal architecture work is in

NH=>I agree, as this is where the func modelling expertise resides.  G.805/809 are much more important than some people realise .....at least judging from the reaction I often notice when folks come across this stuff for the first time.  Our NMS/OSS experts recognise these are the backbone of good management information modelling, and thus NE/NMS specifications and re-use of OSS components, eg see the work in TMF that is based on G.805/809.  However, G.805/809 are generic for the 3 networking modes and technology specific derivatives are produced as required.  One of my colleagues has the editorship for MPLS (which is proving a very interesting exercise) and Maarten Vissers (now with you guys in Alcatel) is doing ethernet.

> However, 

NH=> In simple client/server i/w (aka network i/w) the control-planes of both the client and the server layers are independent with no i/w at all.  Further, the data-plane of the client is the *same* at both ends and must be *transparently* carried over the server data-plane....or that is what should happen at least!   

In peer-partition i/w the arch rules are different......below represents the current consensus of folks in BT on this....but this needs further work as you will see, and we are addressing this:

-	all the CI (characteristic information) of each peer server layer trail data-plane should be terminated at the iwf.....so that means no OAM functions and no 'features' are mapped between peer server layer data-plane partitions.  This is important for many reasons.  For example:
	*  We may wish to interwork between 2 technologies belonging to different modes, eg ethernet (cl-ps) and ATM (co-ps) say (but you can think of many other pairs).  There is clearly no signalling i/w in this example.
	*  There is no 'congestion semantic' in MPLS or ethernet but there is in FR and ATM (though these are quite different in syntax).  So there is no possible general 'feature' i/w here.
	*  Because PWE3 does not recognise MPLS as a layer network in its own right we don't have i/w with MPLS LSPs directly but rather a forced client/server i/w with PWs on a client specific basis.  This is a mistake in our view for several reasons, but that is what has happened and is now something some folks are going to have to live with.  This means there will be (at least) O(N^2) possible mapping relationships in the data-plane...PW compression of clients makes this larger as well as creating additional defect management issues at the iwf for the functional arch changes this results in.  Further, the so-called 'port-mode' in some of these PW cases means absolutely nothing in Func Arch terms and will be very problematical to manage correctly.  In the case of OAM there *may* be some semantic relationships of *some* functions; but even if there is, in most cases the syntax will be very different (the exception to this is ATM I.610 OAM and MPLS Y.1711 OAM where, because functional convergence of the base OAM for defect detection/handling was considered early on, one can get simple/harmonised semantic and syntax mappings....see Y.1712).  However, this is a special case of arch compliant ATM/MPLS OAM i/w, and the correct general method of defect handling in our view is as defined in the next bullet.  Further, note that even if one could relay a defect mapping via some FDI semantic from one peer partition to another peer partition and so on down the chain, when one gets to the last partition you still need to 'do something' with this wrt the the higher layer entity, so one might have as well have done it right at the outset in the peer server layer partition where the defect originated.

-	defects occuring in any server layer partition and detected at its data-plane trail termination point must be mapped to the appropriate client layer data-plane FDI signal.   Note that this client layer data-plane is common to all the lower peer layer partitions.....in other words this has the previous simple client/server relationship to each of lower server layer partitions.  Now a clear understanding/specification of what this common end-end higher entity is is a critical issue....and this should be nailed down 1st, eg AAL5 + rfc2684 is a possible candidate.  But AALs are missing even basic OAM functionality.....but so are all other possible candidates here.  Seems there is some work to do IMO on this issue.

-	the nature of the control-plane i/w between the peer server layer partitions is a function of the 2 modes involved, the addressing, signalling (if present) and routing protocols (if present) used in each peer partition and the i/w policy (in theory different parties could be involved each side of the iwf).  In other words, this starts to look very much like an I-NNI or an E-NNI specification.  Clearly having a greater degree of functional convergence here can be beneficial (eg same base signalling protocol in each peer server partition say when this is appropriate).  Note also the crucial relationship between the peer-partition OAM spans and the nature of the signalling.  This needs further study IMO as its corect handling is not immediately obvious to me.....though the principle wrt to data-plane CI termination at the iwf noted above is correct in our view and should be retained (else its going to become a right lash-up).

Aside - We would expect any vendor who is serious about doing this stuff right to provide us with solutions where the internal/sensitive control-plane protocols (and for sure management-plane protocols) are logically OOB wrt to data-plane carrying the traffic....so please don't overlook that.  And this is one reason why Ben said (in an earlier mail) we'd rather this work was not done in IETF as we simply don't understand *who* this stuff is aimed at...is is the Internet (but seems no fit here)?  ISPs (more likely)?  or operators like BT (though seems not on evidence to date)?  If it is us however, then please start with G.805/809 and work from that.  This is not meant to be disrespectful to IETF, its just that our requirements are not the same as the Internet or ISPs.  Hope folks can understand that.

So I don't agree with you if you think the same arch model (even just for the signalling component) is applicable to these 2 cases, and I also don't think its right to home-in on the signalling facet without a proper understanding of how the other facets (like defect detection/handling in the data-plane) relate to this.....though I can start to imagine someone cooking-up some awful hybrid of client/server data-plane i/w with some horrible OAM mapping lash-up and peer control-plane i/w if we are not vigilant here.  This is why I'd like to get the arch rules for this stuff agreed 1st before folks rush off into solution mode.  Please draw out the func models of what you are proposing here, we for sure will when defining how we want this stuff to i/w.

However, I'll go and have a look what the draft you mentioned actually says now and, after consultation with folks here, let you know what we think of it.

regards, Neil
> > NH=> I think its bigger than this.  We want to see a 
> stronger respect for the functional architecture principles 
> of G.805/809.  There are many reasons we want this, but a key 
> one is that these func arch models form the bedrock of the 
> network management information models for our NMS/OSS.  So 
> its quite important to us.
> > 
> > Further, we believe that generic arch principles for 
> client/server i/w (aka network i/w) and peer-partition i/w 
> (aka service i/w) should be defined 1st irrespective of the 
> specific technologies involved.  The arch principles are not 
> the same in these 2 i/w cases.  Further, these relationships 
> are affected by (i) the networking mode of the technology 
> considered, ie whether cl-ps, co-ps, or co-cs, and (ii) how 
> well a given technology is functionally specified.
> > 
> > (i)     client and server layers must be independent in all 
> aspects of the data and control planes.  This is required 
> since the client and server layer networks can be owned by 
> different parties.
> > (ii)    the client (all aspects) must be transparent to the 
> server layer.  Some folks also refer to this as 'the 
> principle of minimum intervention'.
> > (iii)   defects detected at the trail termination point of 
> the server layer network must be mapped to a FDI (Forward 
> Defect Indication), in whatever syntax is relevent to the 
> client, at the server->client adaptation function and for all 
> clients affected.  This is to inform client that the defect 
> is not in their layer network and thus stops alarm storms in clients.
> > 
> > We don't believe the current PWE3 drafts on client/server 
> relationships meet the above requirements.....I can provide 
> an extensive list of stuff we feel is wrong here, and we have 
> raised these issues on the lists in the past but they have 
> been ignored.
> > 
> > The original driver for the PWE3 work was from SPs who did 
> not have native ATM, FR, etc technology networks but who, 
> nevertheless, wanted to offer their carriage as services to 
> customers over either an IP or MPLS server layer network.  
> Well, that's OK I guess, but when it gets a bit more serious 
> such that MPLS (not PWs please note) is being touted as the 
> convergence technology for most SPs (inc BT) then (i) we want 
> to make sure MPLS is correctly/adequately functionally 
> specified and (ii) that the X/MPLS i/w relationships are 
> correctly specified.
> > 
> > In particular, we don't think any single SDO should try and 
> claim 'ownership' of this topic.  And as noted, we want to 
> start from a basis of respecting G.805/809 func arch principles.
> > 
> > regards, Neil
>

---

From: Peter Willis <[email-masked]>
Date: Fri, 27 Feb 2004 09:37:26 +0000

> > similar concerns from the carriers.

It may be that some carriers have expressed requirements for SPVC interworking 
to be addressed (but why aren't they making their opinion known on this 
list?). I would guess that these carriers have not specifically asked for 
SPVC interworking to be developed in the IETF PWE3 WG. I have heard several 
carriers express the opposite - that they prefer the standards not to be 
developed in the IETF.

It is perhaps a reflection of these carriers' sentiments that we are not 
hearing their voices on the PWE3 list?

Peter Willis,
Office of the BT Group CTO.

---

From: "Monique Morrow (mmorrow)" <[email-masked]>
Date: Fri, 27 Feb 2004 11:27:13 +0100

Peter,

You and I know that this assertion is untrue; however, I do see a
requirement to clarify the group's working scope in this context.
Currently, there are service providers who are implementing pseudowire
mechanisms and would like to extend capabilities to network interworking
constructs. Actually these carriers are more concerned about providing a
resolution to their problem and less concerned as to which standards
body should own it.  

Once again, I do agree that clarity is required as network services
evolve.

Regards,

Monique

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Willis
Sent: 27 February 2004 10:29
To: Eric Rosen (erosen)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] New PWE3 Charter Items: SPVC Interworking 

>  Further,  if the  interworking  in question  is going  to
> affect what runs on the IP side  (which seems likely, as no one will
want to
> change the legacy side), then one may need to go where the IP
expertise is.  

I see plenty of IP expertise in the other standards bodies and forums.
Indeed 
Cisco sends many of its people to the other standards bodies and forums
- are 
you saying those people Cisco send to both the IETF and the other bodies
are 
not IP experts?

Peter Willis,

---

From: Chris Metz <[email-masked]>
Date: Fri, 27 Feb 2004 06:32:43 -0800

Couple of comments on this subject:

- One could argue there is precedence. IETF has been, by necessity 
recognizing and working with non-IP encaps and even signaling. Recall
Classical IPoATM (1577/2225) where routers interacted with ATMARP servers 
to move ATM addresses around so that an SVC could be setup.
We did it because operators ran IP and they wanted to dynamically support 
IP connectivity over SVCs.

- w/ spvc interworking we again have an ATM signaling message hitting a 
router where it is terminated. The router then processes this message and uses
PWE3 protocols (not ATM protocols) to complete the setup that supports the 
service the operator requires.

- You see the same faces at the different standards body meetings and there 
is both formal and informal cross-pollination of ideas which is good.

- IETF does have too narrow a constitution. We need to recognize that the 
Internet and its underlying protocol machinery is and will do more then just
move IP packets, it is moving bits that are part of revenue-generating 
services (L3, L2, voice, whatever) offered by providers. PWE3 whether we 
like it or not is a fundamental building block of this Internet bit-moving, 
money-making, convergence machine :-)

- We want to get it right. To that extent, those working on PWE3 should be 
"forced" (bad choice of words, I know, how about encouraged) to understand 
the critical aspects of what is required to support a L2 service ... so 
that it works as well as it can with the PWE3 stuff.

I can appreciate the arguments that say spvc iw does not belong in the 
IETF. But I also want to make sure that those building PWE3 boxes and the 
operators who are
and will deploy it have a solution  that works.

Let's do it in PWE3.

---

From: [email-masked]
Date: Fri, 27 Feb 2004 14:55:25 -0000

Chris,
> is both formal and informal cross-pollination of ideas which is good.

<snip>

> - We want to get it right.

When migrating to a multi-service core a service provider has to be certain that the solution they are deploying is 'right' and 'correct', as most of their business will rely on that multi-service core.  Any problems with the migration path deloyed, or any additional opex introduced by unnecessary complexity or violation of defined networking architectural principles (i.e. G.805/G.809) will in the long run cost the service provider dearly.

For e.g. (and I don't want to digress into a debate on this) managing a MPLS network is expensive and arguably more expensive than it should really be.  IMO this is in some part due to network architectural violations and the fact that things like OAM were not considered/designed in from day 1.

IMO, the issue is not that the IETF does not have the technical ability to address the problem, but that the IETF's consitution/modus operandi does not allow/encourage solutions to these sorts of problems that are 'right' and 'correct' straight out of the box so that they address the requirements of service providers (particularly traditional telco service providers like BT).

Ben

---

From: Eric Rosen <[email-masked]>
Date: Fri, 27 Feb 2004 10:38:02 -0500

> I see plenty of IP expertise in the other standards bodies and forums. 

It's one thing  for an organization to have a smattering  of experts in some
subject,  it's quite another  for it  to be  a center  of expertise  in that
subject. 

> are you saying those people Cisco send  to ... the other bodies are not IP
> experts? 

Heavens.  Of course everybody from Cisco is an IP expert! :-) Unfortunately,
the  presence of  people from  Cisco is  not a  sufficient condition  for an
organization's being a center of IP expertise.

> Office of the BT Group CTO

:-)

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 27 Feb 2004 18:50:17 -0500

Neil,

I hope that you can help me understand what the practical implictions are of some of your generic statements. Please see below.

Peter

> 
> NH=> In simple client/server i/w (aka network i/w) the 
> control-planes of both the client and the server layers are 
> independent with no i/w at all.  

Mustapha's email addressed control plane interworking between ATM and MPLS. In that context, how should I interpret your statement? Are you saying that the only valid way of carrying ATM over MPLS is the following: establish a Pseudo Wire that carries multiple VPs in such a way that ATM signaling and routing information is carried transparently over that PW and the establishment of new VPs or VCs through that PW should be done in such a way that it doesn't require any additional signaling in the MPLS plane? This would exclude any form of 1-1 encapsulation where VC or VP setup necessarily triggers PW setup.

> 	*  Because PWE3 does not recognise MPLS as a layer 
> network in its own right we don't have i/w with MPLS LSPs 
> directly but rather a forced client/server i/w with PWs on a 
> client specific basis.  This is a mistake in our view for 
> several reasons, but that is what has happened and is now 
> something some folks are going to have to live with.  This 
> means there will be (at least) O(N^2) possible mapping 
> relationships in the data-plane

As a generic statement this sounds reasonable, but when you look at the specifics of existing protocols, I don't think it holds.

The MPLS-FR Alliance has recently examined Service Interworking in-depth. One of the conclusions was that you can't do generic (i.e. payload-independent) service interworking between Ethernet on the one hand and Frame Relay or ATM on the other. (This was explained in detail in a contribution by Rao Cherukuri and Ali Sajassi.) As a result, the MPLS-FR Alliance decided that Service Interworking can only be done in very specific cases:

1) Between Frame Relay and ATM, according to FRF.8

2) In case of end-to-end transport of Ethernet traffic (i.e. where ATM and FR use bridge-mode encapsulation)

3) In case of end-to-end transport of IP traffic (i.e. where ATM and FR use routed-mode encapsulation)

Of these, (2) can hardly be considered as Service Interworing in the traditional sense of the word. It is essentially a variant of network interworking of Ethernet over ATM or FR. (3) is more complicated due to IP specific issues that have been identified by Himanshu Shah and Ali Sajassi in earlier drafts, but still it is not Service Interworking in the traditional sense of the word.

The same holds for MPLS: it would be possible to define SI between FR and MPLS or ATM and MPLS. However, it is not possible to define generic (payload-independent) Service Interworking between Ethernet and MPLS.

Therefore, your statement about the service interworking between N different protocols reduces to a statement about Frame Relay and ATM only. For N=2, it seems that PW emulation of ATM (or FR) over MPLS in conjunction with FRF.8  is a more pragmatic approach than the alternative that you propose: SI between ATM and MPLS followed by SI of MPLS to FR.

Am I missing something?

---

From: [email-masked]
Date: Sat, 28 Feb 2004 15:39:44 -0000

Chris,

Chris Metz observed 27 February 2004 14:33

<snipped>
> - IETF does have too narrow a constitution.
NH=> I am not sure IETF has a useful constitution at all these days.  IMO (i) 'rough consensus and running code' and (ii) '1 man/woman 1 vote' worked fine back in the 60s/70s when the Internet was still a big experiment.  But we operators can't afford 'rough consensus and running code', we need network solutions that are properly architected up-front.  IETF does stds after stuff has been built.  Further, if one is a dominant vendor in that environment, then it could be argued that the IETF modus operandi starts to look more like a 'stds laundering service'.

<snip>
> - We want to get it right.
NH=> That is not the impression we get.  We get the impression of lumbering from one kludge to the next.

> To that extent, those working on 
> PWE3 should be 
NH=> You make the assumption here that PWE3 is already 'right'.  It's not.  However, PWE3 stuff per se is not the real problem....it is a symptom of a deeper problem.....see later.
> IETF.
> But I also want to make sure that those building PWE3 
> boxes and the 
> operators who are
NH=> So do we.....so let's start with the right architectural mindset.

Now let me try and explain why you have seen certain views expressed by my colleagues here in BT on this thread....some of whom, it has to be said, would prefer the solution that PWE3 was shut down:

-	PWE3 is a symptom of a deeper issue.....MPLS is simply not IP.  Just like GMPLS (eg SDH) is not MPLS.  IP uses a cl-ps forwarding paradigm (ie each pkt must have network significant DA/SA), MPLS uses co-ps forwarding (ie pkts only contain a link-connection signficant label) and GMPLS uses co-cs forwarding (ie fixed BW labelled slots in time/frequency/space). If MPLS does not offer something different to IP then why on earth do we need it?

-	A mp2p construction and a PHP 'feature' breaks the arch rules of the co-ps mode....that is just a fact.  Add proprietary ECMP to the brew and one has now created a complex set of both technical and commercial traffic/fault/QoS problems for operators to try and deal with......and if any of you saw my recent posting (originally on the l3vpn list) to Chris Lewis regarding QoS in VPNs I explained some of the additional issues that need to be considered here.  Sure you can do mp2p and PHP but this does not make them a sensible thing to do.  Nearly all the problems with MPLS stem from these arch violations of the co-ps mode (though there are also some functional deficiences in MPLS as-is...see later)  If you want true any-any behaviour and if similiar less-strong traffic/perf-SLAs are acceptable then use a proper IP cl-ps server layer since this does not suffer from the problems LDP does.  When we use a co-ps mode we should ensure it adds real value and not just problems.  In any case, we must have conformance to G.805/809 func arch requirements, as ultimately these determine the efficacy of the management information models that one creates for a given technology. I can point you at our NMS/OSS folks if you want chapter/verse on why this is so critically important to us.

-	MPLS is not singular, ie each different method of signalling LSPs creates different MPLS networks.  MPLS has no consistent access point addressing.....and these don't belong to the IP layer network even if they are based on the same v4 (or v6) format.  To illustrate this, observe that one cannot 'legally' connect a LDP LSP access point to a RSVP-TE LSP access point.....though one can now have misconnectivity defects between such LSPs please note.  This is no different, in principle, to observing that one cannot connect a VC_4 access point to a VC_12 access point in SDH.....they simply belong to different layer networks.

-	It should be a no-brainer requirement for a serious network operator that all internal/sensitive control and management protocols must be logically (at least) OOB wrt to the customer traffic in the core network.  This aspect seems not to have been considered at all for MPLS.

-	The original intent of the PWE3 work was to allow a SP who was not able to offer native ATM and FR services to get a slice of the ATM and FR market.....the remit has expanded since then.  It was not written to facilitate network convergence *from* FR, ATM to MPLS for operators like BT.....noting that this is not even true any longer as the convergence seems to be to PWs (not MPLS) and these are not the same thing....see later.

-	Since MPLS is not the same as IP, then there is no forced requirement for the XoverMPLS and XoverIP adaptation functions to be the same.  Further, if we did XoverSDH for arguments sake, this would also require a different adaptation.

-	Most, if not all, the fields in the Martini CW are serving no useful purpose.  Let me elaborate on this (I will ignore the ECMP hack here, save to note this is also a consequence of breaking the arch rules, ie load-spreading should be constrained to lie within a single layer network).

If one compresses a client one loses client layer transparency.  This creates management problems.  If one drew out the G.805 func arch of what is going one here one would see artifical/partial trail termination functions created at the i/w point (and there are varying spins on this depending on the client involved and the degree of compression being used). When folks draw 'cloud diagrams' however they seem to overlook the fact that there is also a similar C/S relationship between MPLS (or whatever) and some underlying server layer like SDH, ie in G.805 terms, 'a client layer link-connection is formed by trails in a server layer'.  Fortunately the C/S relationships here respect the arch rules, so folks forget about them and they are taken for granted.....esp the fact that the server layer has well-defined and independent (of the client) OAM and defect handling, though this is invariably heavily relied on.  In principle however, the C/S relationhip between MPLS (as a client) say and SDH (as a server) is no different to that between ATM and MPLS say....and so the same arch rule should be used, ie G.805.

Seq Nos are not required in an architecturally valid co-ps technology. Moreover, they should not even occur in a generalised adaptation function (cf RTP and AAL1 which are *specific application* adaptation functions).  However, if Seq Nos remain then they cannot be left 'open-ended' wrt behaviour under persistent abberation, ie a defect condition must be specified with entry/exit criteria and consequent actions.  And as a more general observation here, there are no defects specified in any IETF drafts/rfcs for any of the flavours of MPLS....this may be consistent with the IETF mindset (ie 'we don't do services') but this is unacceptable to us.  Please see Y.1711 for what we want here.

The 'port-mode' that appears in some adaptations for some clients has no architectural meaning. This will create fault management problems, eg one cannot map a server layer defect to the appropriate FDI of all/each of the clients supported.  It should be removed from wherever it occurs.

-	PWs are not a sensible convergence network solution for operators......but that is where PWE3 seem to be heading now, ie a PW ignores its underlying transport....which can be IP (cl-ps) or MPLS (co-ps).  This is not acceptable as they have (or at least should have, if arch compliant) different behaviours.

-	A PW is a X/IP or X/MPLS client->server adaptation function.....it is *not* a networked entity whereas an LSP is.  Further, if 2 MPLS networks form a client/server (C/S) relationship and each network is owned by a different party, it is clear we have an LSPoverLSP case and not a PWoverPW case.  A key corollary of this is that all the stuff that defines a layer network must be associated with the LSP entity and *not* the PW enity, eg OAM, signalling, etc.

-	we need a simple adaptation to LSPs for the general C/S case.  The PID word could be used as a basis for this and the Martini CW deprecated.  

-	We know precisely what we require for C/S i/w.....this is implicitly embodied in G.805/809 already. We do not as yet have any agreed arch rules for peer-partition i/w.  We need these agreeing 1st before embarking on specific solutions. See my recent response to Mustapha Aissaoui on this where we give our best current view on what this should be.

I hope you can now see why we don't regard PWs as a suitable convergence solution.  There are arch problems with PWs per se, but there are also more fundamental arch problems with MPLS.  These things need fixing in our view, else it would seem that MPLS (not PWs) will not be able to assume a core convergence role that so many folks hoped it would......and IMO that would be a real pity and a lost opportunity.

regards, Neil

---

From: [email-masked]
Date: Sat, 28 Feb 2004 15:39:37 -0000

Peter...

> From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
> Sent: 27 February 2004 23:50
> To: Harrison,N,Neil,IKR2 R; [email-masked]
> Cc: [email-masked]; Spencer,R,Richard,XGH5 R; [email-masked]
> I hope that you can help me understand what the practical 
> implictions are of some of your generic statements. Please see below.
NH=> I can try.....
> Mustapha's email addressed control plane interworking between 
> ATM and MPLS. In that context, how should I interpret your 
> statement? Are you saying that the only valid way of carrying 
> ATM over MPLS is the following: establish a Pseudo Wire
NH=> PWs are not MPLS however....LSPs are networked entities PWs are adaptation functions.  All the functional components of a layer network should be associated with the networked entity....in MPLS this an LSP.  A PW can have either IP or MPLS as a server layer network.....these are not the same.  PWs therefore have no real networking context....other than the fact they are some form of adaptation.  This is not a good road PWE3 have set off down.  

> that 
> carries multiple VPs in such a way that ATM signaling and 
> routing information is carried transparently over that PW and 
> the establishment of new VPs or VCs through that PW should be 
> done in such a way that it doesn't require any additional 
> signaling in the MPLS plane? This would exclude any form of 
> 1-1 encapsulation where VC or VP setup necessarily triggers PW setup.
NH=> In a strict C/S case that is right.  If I carry ATM over SDH I would never expect an ATM SVC demand to trigger a VC4 set-up say in SDH. This principle is also why the GMPLS peer-model was never sensible (I assume its effectively dead now?).  I mean, even from the most simple case of different SPs owning the client and server layer networks one can see this is a nonsense.
> As a generic statement this sounds reasonable, but when you 
> look at the specifics of existing protocols, I don't think it holds.
NH=> We want to stop re-doing past mistakes.
> 
> The MPLS-FR Alliance has recently examined Service 
> Interworking in-depth. One of the conclusions was that you 
> can't do generic (i.e. payload-independent) service 
> interworking between Ethernet on the one hand and Frame Relay 
> or ATM on the other. (This was explained in detail in a 
> contribution by Rao Cherukuri and Ali Sajassi.) 
NH=> I know Rao and Ali and this is wise counsel.....and this is why I remarked in my previous mail that whilst we can do OAM mapping between I.610 ATM and Y.1711 OAM, this is only possible because both the semantics and syntax (and even their derived dependent defect definitions) are closely aligned (see Y.1712 where this is now specified).  This was not 'chance' either, it was designed it to be this way.....though Y.1711 is much simpler and superior to I.610 (despite the misinformation I keep seeing from some parties on Y.1711).  However, for the general case this will not be possible....and in fact you will end-up with a right lash-up IMO. 

> As a result, 
> the MPLS-FR Alliance decided that Service Interworking can 
> only be done in very specific cases:
Be very careful here.  We have been vigorously discussuing this topic in BT for some time.  Never forget that one of the things most operators want to get away from is the notion that 'service<=>technology'.  That is, we have sold FR services, we have sold ATM services, etc.  So to date we have ended-up selling features of specific technologies and we have also ended-up with lots of disjoint stovepipe networks.....and its not just these, but the whole NMS/OSS stack that goes with them....and that is a killer!  If you see the key point here then when you look at the peer-partition i/w rules I set down in my reply to Mustapha hopefully it will make more sense, ie terminate all CI at the IWF, eg no OAM mapping (so, for example, we would disagree with Tom's OAM message mapping draft....also see my previous comment above for the one possible MPLS_I.610/ATM_Y.1711 exception to this), no 'feature' (like CLP) mappings.

It may be that we *never* migrate existing stoveipes to a common core....simply because of the complexities this will create and the true costs of doing this migration (don't overlook the crucial NMS/OSS aspects in this).  However, we still need to get the basic C/S case right (and I implore folks to understand/respect G.805 here) and we also need to properly understand the peer-partition i/w case since there will be cases of interfacing different peer networking technologies (same or different modes).  As a long-term goal we have a concept I christened here of 'functional covergence'......and this is all about stopping replacing technology X with technology Y (and thus a wholesale functional component change out, inc NMS/OSS), but instead focussing on moving to best-of-breed functions for some target cl-ps, co-ps and co-cs technology.....the networking problem for each technology belonging to the same mode is largely the same.  We very strongly don't agree with folks who think all the services we need to offer can be done in a single mode....I tried to explain some of this in my response to Chris Lewis wrt 'QoS in VPNs', and these wider points really ought to be considered along side this stuff as its all related.  
> 1) Between Frame Relay and ATM, according to FRF.8
NH=> Now, can you see that this is a product of an old mindset where 'technology=service'?  I can for sure understand *why* those who did this did it like this......it made sense then and still does where we sell 'FR and ATM services'.  But we want to get away from this notion of 'selling technology' over the long-term.  So continuing to foster this same view is not a good idea IMO.  Note also that in FRF8 there is the option *not* to do the 'feature mappings'......not sure who put that in there, but maybe they were way ahead of the game even back then.
> 
> 2) In case of end-to-end transport of Ethernet traffic (i.e. 
> where ATM and FR use bridge-mode encapsulation)
NH=> Yes, but this is pure C/S....this ought to be simple *if* you respect the rules.
> 
> 3) In case of end-to-end transport of IP traffic (i.e. where 
> ATM and FR use routed-mode encapsulation)
NH=> Again its simple clinet/server....here the client is IP.
> 
> Of these, (2) can hardly be considered as Service Interworing 
> in the traditional sense of the word. It is essentially a 
> variant of network interworking of Ethernet over ATM or FR. 
> (3) is more complicated due to IP specific issues that have 
> been identified by Himanshu Shah and Ali Sajassi in earlier 
> drafts, but still it is not Service Interworking in the 
> traditional sense of the word.
NH=> Agreed.
> 
> The same holds for MPLS: it would be possible to define SI 
> between FR and MPLS or ATM and MPLS. However, it is not 
> possible to define generic (payload-independent) Service 
> Interworking between Ethernet and MPLS.
NH=> Oh yes I know.....this one is really giving me headaches.  If you recall what I said to Mustapha there was one point that some folks may easily have missed (clearly you haven't) as to its true importance/significance...so let me repeat it.  *Before* one should even think about peer-partition i/w of the functional components of >=2 server layer networks, you have to have a very clear understanding of the 'thing' that is the common client layer entity of all the lower peer partitions.  Now this has some deep implications that I probably don't want to get into here.....and in any case we have not come to any firm views as to what this should be yet. However, its on our agenda to sort because it is pivotal to some of our other ideas for an alternative services arch. 
> 
> Therefore, your statement about the service interworking 
> between N different protocols reduces to a statement about 
> Frame Relay and ATM only. For N=2, it seems that PW emulation 
> of ATM (or FR) over MPLS in conjunction with FRF.8  is a more 
> pragmatic approach than the alternative that you propose: SI 
> between ATM and MPLS followed by SI of MPLS to FR.
NH=> Yes, I can see what you are saying, ie no SI for either ATM or FR with MPLS, just C/S case.  However, one still needs the right C/S approach here...and specically we do not need the notion of PWs for this at all if the server is only arch compliant MPLS and we have client transparency.  
> Am I missing something?
NH=> Don't think so.