Subject: RE: [PWE3] Draft Charter

From: [email-masked]
Date: Fri, 22 Jul 2005 11:28:54 +0100

Matthew/Danny....

>
> Danny,
> 
> The last paragraph states the following:
> 
> "Define the reqiurements for and mechanisms needed to allow
> the operation of switched virtual circuits over a PSN."
> 
> If I recall, we discussed this point on the list back in 
> March. I think that the meaning of this was related to 
> interworking between, say, ATM or Frame Relay signalling, and 
> PWE3. However, there are already a number of existing 
> specifications either in existence or in an advanced state of 
> development (e.g. in the ITU-T and the MFA Forum).
> 
> A number of people commented that this item should be 
> removed, so I was surprised to see that it is still in the 
> draft charter.
> 
> Please could you clarify the situation,
> 
> Regards, Matthew

NH=> May I take this opportunity to remind folks here of some of the
differences between the 3 networking modes.  You CANNOT create trails
(be these PVC, S-PVC or SVC in nature) in a cl-ps mode
technology.....like native IP or ethernet say.  I trust this is
intuitively obvious.

Note - you can of course create 'sessions' above a cl-ps layer network
but these operate on, and only know of and are only concerned with, the
2 end-points.....there is no knowledge/control/care over the network
between these.  This is not a bad thing at all...it's simple a
property/behaviour of the cl-ps mode.  All 3 modes are required in any
full-service operator network.  One mode should never be considered
better/worse than any of the others.  The key to unlocking complexity is
to use all 3 modes in concert wisely to tackle the full range of both
public and private network services (and I think we are still some way
from most folks really understanding and appreciating the importance of
this).

Also please note that a trail object, which is only proper to the 2 co
modes, is a very special object indeed.  Before it is created one has
'choice' of routing;  however, once created that 'choice' is no longer
available.  Indeed, the trail now can be considered as existing outside
the network in which it resides....and other than the removal of
resource, the same view is true from the other (ie network's)
perspective. 

Aside=> If you want to visualise what I am talking about here it's
this.......
Any layer network (call it N) is composed of links and nodes.  The links
are fixed (ie no routing choice) and are *pre-provided* by trails in a
lower (N-1) layer network (this is also related to the issue of
'topology on the fly' you may recall I have raised in previous mails,
however I digress).  The nodes, which in func arch terms represent the
smallest subnetwork of practical interest, are where the routing choice
exists.  Now in a co mode network when the trail is created these
routing choices are removed, ie we create fixed (logically at least)
subnetwork connections across the node.  So if the 'routing deity' later
decides it would have chosen a different route across the network to
create this trail we can (and in most case indeed must) ignore
this....once created the trail is fixed.  This is NOT the case in the
cl-ps mode.  Here the subnetwork/nodes retain routing choice on a
traffic unit (ie packet) by traffic unit basis.

Of course the above refers to the normal operating region of
failure-free conditions. If there is a failure, and for which it is
decided (by some-body/thing) to restore the trail, then this this
re-enables 'choice'.  Note that the mechanism for doing this
(restoration) will vary whether we are considering PVC (management
controlled), S-PVC (signalling delegated by management) or SVC (external
user controlled). This observation (ie about 'choice') is perhaps more
important than you may give it credit from a casual read.  From an
information theory perspective one can consider (the removal of routing
choice) as a reduction in entropy.  Further, some key properties stem
from this:

-	the trail object itself becomes a parent to the child traffic
units it carries.  This is a very important point because it allows one
to totally decouple the survivability importance (of the trail) from
any/all the traffic units it carries.  This observation is especially
crucial for network builder service (which SHOULD be the base building
block of all private services), because the 'QoS' and (relative)
'importance' of each child traffic unit carried by a trail can change
epoch by epoch. 

-	the CI (characteristic information) of a trail MUST be invariant
from its source to its sink(s).  This forms the whole essence of
providing 'integrity' to the trail and its child traffic units at the
networking level (note that this has nothing to do with malicious
attempts at security compromises.....this is purely a base networking
consideration wrt ensuring traffic/fault/perf integrity, eg things can
go wrong due to unitended/accidental human misconfig or HW/SW bugs).
This imposes 2 closely related requirements on the trail:
(i)	that it can only be p2p or p2mp in topological construction;
(ii)	that the correct sequential ordering of traffic units be
maintained at all points along the trail.
These are indeed the base defining properties of a correctly functioning
co mode network, ie they are the essence of the networking contract the
co mode must provide to its clients.

So....SVCs have no real networking meaning if by 'PSN' this also covers
the cl-ps mode, or indeed forms of the co-ps mode that violate what is
noted above.  Note you cannot easily violate these properties in the
co-cs mode as the nature of the label here prevents most types of
architectural abuse.

Note - If we talk about 'SVCs' we are only considering one possible form
of trail invocation method in a co mode network....and this really means
an external client acting across a UNI which, IMO, is really only
relevant when considering public network services (I think some folks
are starting to misuse the terms 'SVCs').  There are of course PVCs and
S-PVCs that have much value too.

Of course this cannot stop folks doing the wrong thing (and there is
already plenty of evidence of that).  However, folks (esp operators)
should be aware that the consequence of not heeding stuff like I am
talking about above is that hard/complex or intractable problems will be
created for topics like traffic, performance and fault management.  And
ultimately this represents a large (mainly opex) cost that is pushed
towards us operators.

regards, Neil

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