RE: [PWE3] New PWE3 Charter Items: SPVC Interworking

[neil.2.harrison at bt.com]

Hi Mustapha,

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

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

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
> 
> Mustapha.
> ------------
> neil.2.harrison@bt.com wrote:
> > 
> > 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
> 

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3