Subject: RE: Re: I-D ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt

From: [email-masked]
Date: Wed, 19 Jan 2005 20:37:25 -0000

Hi Dave, 
David McDysan wrote 19 January 2005 16:29
> 
> Neil,
> 
> This would certainly be an issue for manual provisioning of 
> PWs. When PEs use IP routing then the pre-provisioned 
> existence of these lower layer connections is confirmed 
> periodically by in-band routing protocol message exchange.
NH=> I sincerely hope not!  That is, we must not use the control-plane
to determine whether the data-plane is working.  This is a fundamental
OAM requirement in both the co-ps and co-cs modes.  Further, when we
have a co-cs mode network (ie GMPLS case) the control-plane MUST be run
OOB (at least logically, but maybe also physically) wrt to the in-band
traffic.  But let me come back on the main point of this thread......

The key words in your para above are *pre-provisioned*.  And I agree
with you on this.....one cannot create 'topology on the fly' as basic
physics prevents this.

There are 2 cases here wrt MPLS and GMPLS and they are quite different.
However, in all cases the functional architecture rule of nested layer
networks holds, ie a client layer link-connection (ie the 'line' we draw
between adjacent nodes in some layer network) is supported by a trail in
a lower layer network...this is the essence a 'truth' of topology
creation and it's a relationship that recurses to the duct.  Now let's
look at the 2 cases in a bit more detail:

MPLS - this is a digital wrapper in the data-plane, ie 'just add a label
and create a lower level LSP at will'.  Each LSP however does NOT create
a new layer network.  Those familiar with the functional arch modelling
of MPLS will probably also realise that each LSP, no matter where it
appears in a nested stack of LSPs, belongs to the SAME layer network
(perhaps not so easy to visualise?).  It's not the IP layer network
however despite using IP structured addresses for LSPs....just like
using IP structured addresses for the access points of a SDH VC4 layer
network does not make the SDH VC4 layer network part of the IP layer
network!  However, there is still something not quite right here...all
LSPs SHOULD use the SAME access point addressing no matter how they are
created (be it via signalling protocol X, Y or Z or NMS manual
provisioning).  This is because THIS address belongs to the data-plane
and it should be agnostic to the control-plane used.  Not the case in
MPLS.  This issue becomes rather important for (OAM) Connectivity
Verification when there are misconnectivity defects between LSPs created
by different means.
  
The fact there is a routing process that is now common to both the IP
and MPLS layer networks has some interesting consequences.  It means
these layer networks cannot be functionally decoupled...which might be
considered 'good' if the client is only ever IP, but this might not be
considered 'good' if:
-	the client is not (just) IP and one is simply wanting to use
MPLS as a co-ps convergence transport technology....PWs are a case in
point here;
-	one wants to lease a 'network builder' service off some other SP
but yet wants complete functional isolation (for
commercial/security/whatever reasons).....and to address this we are
going to have to interpose a functional breakwater, by using a PW say.

GMPLS - this is nothing at all like MPLS (despite what one hears).  Here
the data-plane is NOT a wrapper but a well defined SDH or OTN frame
structure for example.  The fact we are dealing with a co-cs mode here
also means that:
-	there are no QoS classes.  This is a actually a 'very good'
feature....esp for network builder services and the carriage of large
traffic (any type) aggregates;
-	the control/management-plane is forced OOB wrt traffic...again a
'very good' feature for security, resilience design  and stability of
this rather important part of the system;
-	one cannot violate the allowed connectivity trail constructs, ie
only p2p and p2mp allowed...again a 'very good' feature;
-	and finally, coming back to the main point of this thread, EACH
layer network is functionally decoupled from the other layer networks.
So when we have, for example, a SDH VC12 and VC4 layer network these
might use exactly the same functional components (for addressing,
signalling, routing, PM, whatever...and this is 'good' per se wrt to
functional re-use) BUT they operate in separate spaces....and to make
this quite clear, if I have a VC12 access point with address X this
obviously cannot be connected to a VC4 access point which also has
address X....the addresses live in different spaces as we are dealing
with 2 functionally decoupled layer networks.  This is also a 'very
good' feature for lots of other reasons including scaling and the
commercial separation of different parties in a client/server
relationship.

And all this is a forced consequence of the co-cs mode itself...it is
not a 'design choice' of GMPLS.  So although GMPLS is nothing at all
like MPLS some folks still talk loosely about routing across nested
co-cs layer networks..... but the fact remains there MUST be something
pre-provisioned at some level as you quite rightly observed yourself.
You can go down 1 layer and do a sort-of client-driven UNI SVC dial-up
in the immediate server WITHOUT having access to the server layer's
routing function (see Note) but this assumes the link-connections in
THAT server are already in place....you can't recurse this desire to
create topology on the fly right down to the duct!

Note - This is rather like making a PSTN 64k call...and its also rather
reminiscent of the old ATM SVC cut-though stuff that folks said was no
good....yet seems it's OK here?

So, MPLS is nothing like GMPLS.  In GMPLS we can consciously avoid the
problems of a wrapper because co-cs layer networks don't use wrappers.
However, one cannot avoid these consequences in MPLS (at least as-is).

regards, Neil

> 
> Dave 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of [email-masked]
> > Sent: Sunday, December 19, 2004 4:39 PM
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]; 
> > [email-masked]; 
> > [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]; 
> > [email-masked]
> > Subject: RE: [PWE3] Re: I-D 
> > ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt
> > 
> > 
> > Hi Chris,
> > > 
> > > Hi-
> > > I think we are missing a specific USE CASE from section 
> 5. Consider 
> > > the case where we have each PE pair run a client control plane 
> > > function. This control plane function drives creation 
> (and deletion) 
> > > of corresponding PW segments between each PE pair. Rather then 
> > > terminate and process the PW payload at each intermediate PE 
> > > (between the source and target U-PEs), we splice the 
> preceding and 
> > > succeeding PW segments together ... so that the data plane at the 
> > > intermediate
> > > PE(s) becomes a PW label swap operation.
> > > 
> > I believe you are, perhaps not intentionally, raising a very
> > important point here that has troubled me and many folks in 
> > BT for a long time.  I can summarise this as follows:
> > 
> > When we have a topology of nodes and links in some layer
> > network that we wish to route a path across, there is an 
> > (unconscious?) assumption that the link-connections (ie the 
> > 'things' that connect adjacent nodes
> > together) in THIS layer network really exist, ie they are 
> > ALREADY provisioned in some manner between the nodes in THIS 
> > layer network. However, these link-connections are provided 
> > by trails (ie end-end
> > paths) in some LOWER layer network (eg E1 PDH or VC12 SDH 
> > trails).  In turn, the link connections of this lower layer 
> > network are provided by trails in an EVEN LOWER lower layer 
> > layer network (eg SDH VC4).  This behaviour (ie a client 
> > layer link-connection is provided by a server layer trail) 
> > recurses until we hit the duct.
> > 
> > We can restate this in a different way (and I am tailoring
> > this for the PW case, but it can be generalised to any case 
> > of nested layer
> > networks):
> > 
> > -	For the client of the PW to work it requires a level N (MH PW)
> > LSP to be in place
> > -	For the level N (MH PW) LSP to work it requires a level N-1 LSP
> > to be in place (for EACH link/segment of the MH PW LSP as per
> > the recursion principle noted previously)
> > -	For the level N-1 LSP to work it requires a level N-2 LSP to be
> > in place (for EACH link/segment of the level N-1 
> > LSP).....this can continue for as many LSPs as there are 
> > nested, but let's stop the LSP nesting here
> > -	For the level N-2 LSP to work it requires a (let's say) SDH VC4
> > path to be in place...again for EACH of its link connections, 
> > but let's take this recursive/general requirement to be 
> > as-read from now on
> > -	For the SDH VC4 path to work its requires a STM MS/RS path to be
> > in place
> > -	For the STM MS/RS path to work it requires a fiber to be in
> > place
> > -	For the fiber to work it requires a duct to be in place.
> > -	For the duct to be in place it requires we get a back-hoe out
> > and dig some trenches!
> > 
> > In other words we cannot create 'topology on the fly'......a
> > level or pre-provisioning is a key requirement/assumption 
> > here.  But yet in MPLS this assumes this is indeed possible 
> > (a similar issue occurs in GMPLS when folks talk of 'TE 
> > links' and 'FAs').  Clearly this is a nonsense. It's not a 
> > problem in MPLS as-is *provided* we only ever have 2 levels 
> > of LSP AND  the top level LSP is not actually a true 
> > networked LSP but merely a p2p 1-hop entity where the label 
> > proxies for a client identifier function (which is precisely 
> > what we find with rfc2547 VPNs and SH PWs).  However, for MH 
> > PWs each link-connection here (ie between PW switching 
> > capable nodes) requires a 'regular' lower level LSP to be in 
> > place before traffic can be sent, or indeed MH PW LSP routes 
> > to be calculated with any valid sense...and this requires 
> > even lower level trails to be in place, etc, etc, until we 
> > get to the duct.
> > 
> > I think you are assuming here Chris that the (PW) client
> > control-plane (or more accurately the client layer network 
> > across ALL planes) is independent of the server MPLS (PW) 
> > control-plane (network)....and this is a 'good thing' as one 
> > can can now functionally decouple the client (whatever it is) 
> > and server (MPLS) layer networks.  Can't do this in MPLS per 
> > se however......currently there is no good way of creating a 
> > 'functional breakwater' between 2 MPLS layer networks except 
> > by PWs and some other technology.  As I noted, this is not a 
> > problem when we only have a single layer network in MPLS and 
> > a higher level LSP is not really a 'networked LSP' but a 
> > 1-hop client ID proxy.  MH PWs start to change this picture 
> > however.....and so does client/server i/w between 2 operators 
> > A and B say, who both have MPLS networks and where operator A 
> > wants to lease transport capacity off operator B but neither 
> > operator wants to functionally peer with each other.
> > 
> > I think we have some interesting issues brewing here.
> > 
> > regards, Neil
> > 
> > 
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> 
>

---

From: David McDysan <[email-masked]>
Date: Wed, 19 Jan 2005 11:28:41 -0500

Neil,

This would certainly be an issue for manual provisioning of PWs. When PEs
use IP routing then the pre-provisioned existence of these lower layer
connections is confirmed periodically by in-band routing protocol message
exchange.

Dave 

> > I think we are missing a specific USE CASE from section 5.
> > Consider the case where we have each PE pair run a client 
> > control plane function. This control plane function drives 
> > creation (and deletion) of corresponding PW segments between 
> > each PE pair. Rather then terminate and process the PW 
> > payload at each intermediate PE (between the source and 
> > target U-PEs), we splice the preceding and succeeding PW 
> > segments together ... so that the data plane at the intermediate

---

From: David McDysan <[email-masked]>
Date: Wed, 19 Jan 2005 11:28:41 -0500

Recommend that the essence of Chris' comment be preserved in the document by
stating in the document that an (important, principal?) S-PE function is a
PW label swap operation. This could be added to the explanatory sentence in
the paragraph with Figure 2.

Dave

> Behalf Of dimitri papadimitriou
> Sent: Sunday, December 19, 2004 6:09 PM
> To: Chris Metz
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Alik Shimelmits; [email-masked]; 
> [email-masked]; Luca Martini; 
> [email-masked]; [email-masked]; Sasha 
> Vainshtein; [email-masked]; 
> [email-masked]; PWE3 WG (E-mail); 
> [email-masked]; [email-masked]; Sharon Galtzur; 
> Ping Pan; [email-masked]; [email-masked]; 
> Subject: Re: [PWE3] Re: I-D 
> PW segment definition (which is not a SH-PW) was meant to 
> deliver such 
> capability since S-PE are agnostic to both PW payload its associated 
> control so that only ingress/egress U-PEs have to terminate 
> and process 
> such payload
> 
> note: the confusion comes from the following sentence where (SH-PW) 
> appears in parenthis
> "     - Multi-hop PW (MH-PW).  A static or dynamically 
> configured set of
>         two or more contiguous PW segments (SH-PW) that behave and
>         function as a single point-to-point PW. Each end of a MH-PW by
>         definition MUST terminate on a U-PE."
> 
> also a SH-PW is constituted by a single PW segment and a MH-PW is 
> constituted by more than one PW segment (one between the ingress U-PE 
> and the S-PE, one between each S-PE pair and one between the 
> last S-PE 
> and the egress U-PE)
> 
> Chris Metz wrote:
> > Hi-
> > I think we are missing a specific USE CASE from section 5. Consider 
> > function. This control plane function drives creation (and 
> deletion) 
> > (between the source and target U-PEs),
> > we splice the preceding and succeeding PW segments
> > together ... so that the data plane at the intermediate
> > Cheers ...
> > .

---

From: [email-masked]
Date: Thu, 20 Jan 2005 09:36:35 -0000

BT's requirements are U-PEs may be in a private address space. And for
security reasons the U-PEs should not know each other's IP address. 

These may sound like extreme requirements but note that:
- The U-PEs are not part of the Internet so do not qualify for Internet
Addresses.
- We have to protect our critical national infrastructure from all
reasonable threats (who's to say one of the U-PEs isn't located in
Afghanistan?).

Peter.
> From: Chris Metz [mailto:[email-masked]] 
> Sent: 19 January 2005 23:07
> To: David McDysan
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; 'Alik Shimelmits'; [email-masked]; 
> [email-masked]; 'Luca Martini'; 
> Willis,PJ,Peter,CXH R; Spencer,R,Richard,XDE R; 'Sasha 
> Vainshtein'; [email-masked]; 'PWE3 WG 
> (E-mail)'; [email-masked]; Harrison,N,Neil,IKM1 R; 'Sharon 
> Galtzur'; 'Ping Pan'; [email-masked]; [email-masked]; 
> At 11:28 AM 1/19/2005 -0500, David McDysan wrote:
> >I recommend that the knowledge of a remote U-PE IP address 
> (or at least 
> >a prefix associated with a domain) be not only mentioned in the use 
> >cases section, but also be stated as a mandatory (i.e., SHALL) 
> >requirement in the routing section.
> 
> Hey Dave-
> I don't quite see how it should be a mandatory requirement 
> for the local (source) U-PE to learn the IP address of the 
> remote (target) U-PE. At a minimum the U-PE or any PE leading 
> up to and including the "penultimate PE" needs the IP address 
> of the next_hop PE.
> 
> If we route the PW setup based on the /32 of the remote U-PE 
> we might bypass the desired intermediate S-PEs, no?
> 
> 
> >Based upon other discussion on this thread, also suggest that use of 
> >other identifiers
> 
> .. and the IP address (or prefix) identifying the remote U-PE ...
> 
> 
> >  (and associated authentication) for use in routing be stated as a 
> >desirable (SHOULD) requirement in the routing section.
> 
> Thanks ...
> 
> 
> 
> >Dave
> >
> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of dimitri papadimitriou
> > > Sent: Sunday, December 19, 2004 6:34 PM
> > > To: Chris Metz
> > > [email-masked]; Luca Martini; [email-masked]; 
> > > [email-masked]; Sasha Vainshtein; 
> > > [email-masked]; [email-masked]; 
> > > PWE3 WG (E-mail); [email-masked]; 
> [email-masked]; Sharon 
> > > Galtzur; Ping Pan; [email-masked]; [email-masked];
> > > per section 5.2.1. of PW control: "The Attachment 
> Identifier must be 
> > > unique in the context of the PE router in which the Forwarder 
> > > resides. The combination <PE router, AI> must be globally unique."
> > >
> > > therefore, either the PE router is used (leaving AC 
> selection being 
> > > a local process) or both are explicitly specified as part of the 
> > > request or one identifies the ACs using their mapping in 
> the CP as 
> > > IP addresses
> > > since a reachable point can be translated with an IP 
> prefix (at the
> > > control plane level) whereas the corr. data plane 
> end-point does not
> > > have to terminate IP packets
> > >
> > > Chris Metz wrote:
> > >
> > > > At 03:51 PM 12/14/2004 -0700, Luca Martini wrote:
> > > > <snip>
> > > >
> > > >
> > > >>>    1. I think that the following statement in the "Use
> > > Cases" section
> > > >>>       requires clarification: "*At a minimum PW control
> > > >>>       channel establishment requires knowledge of and
> > > reachability to
> > > >>>       the remote (ultimate) PE IP address*". I understand that
> > > >>>       *reachability* of the remote ultuimate PE IP 
> address may be
> > > >>>       problematic in some cases; but do we really
> > > envision the case
> > > >>>       when a PE can be set up without the one of the 
> ultimate PEs
> > > >>>       possessing any *knowledge* about IP address of 
> its remote 
> > > >>> peer?
> > > >
> > > >
> > > > Yes ... especially if the MH-PW setup scheme is created in
> > > such a way
> > > > so that the source U-PE does not need to know the IP address of 
> > > > the remote U-PE. This may be for variety of reasons including 
> > > > security, scale, etc.
> > > >
> > > > We would need to include TAI that identifies the 
> desired AC on the 
> > > > remote U-PE.
> > > >
> > > > Cheers ...
> > > >
> > > > <snip>
> > > >

---

From: David McDysan <[email-masked]>
Date: Fri, 21 Jan 2005 09:42:43 -0500

Let me try to restate the proposed requirement more clearly.

In the case of a MH-PW, the protocol SHALL support explicit identification
of the remote U-PE using an IPv4/IPv6 address. Note that this case is
supported for a SH-PW using the current protocol. 

Note that this does not preclude other names/identifiers/addresses, such as
a private address a URI or something else (Suggest that others propose text
for these schemes. I suggest that the requirements should cover this simple
case, and requirements for other cases be added. 

Dave

> Behalf Of Chris Metz
> Sent: Wednesday, January 19, 2005 6:07 PM
> To: David McDysan
> [email-masked]; [email-masked]; 'Alik Shimelmits'; 
> [email-masked]; [email-masked]; 
> [email-masked]; 'PWE3 WG (E-mail)'; 
> [email-masked]; 'Sharon Galtzur'; [email-masked]; 
> 'Ping Pan'; 'Sasha Vainshtein'; [email-masked]

---

From: David McDysan <[email-masked]>
Date: Fri, 21 Jan 2005 09:42:43 -0500

I view these as an additional valid requirement. 

MCI's requirement is for IPv4/IPv6 addressability of the remote U-PE for use
within the MCI network.

Dave

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, January 20, 2005 4:37 AM
> To: [email-masked]; [email-masked]
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> BT's requirements are U-PEs may be in a private address 
> space. And for security reasons the U-PEs should not know 
> each other's IP address. 
> 
> - The U-PEs are not part of the Internet so do not qualify 
> for Internet Addresses.
> - We have to protect our critical national infrastructure 
> from all reasonable threats (who's to say one of the U-PEs 
> isn't located in Afghanistan?).
> 
> Peter.
> [email-masked]; 
> > > > > At 03:51 PM 12/14/2004 -0700, Luca Martini wrote: <snip>
> > > > >
> > > > >

---

From: David McDysan <[email-masked]>
Date: Tue, 25 Jan 2005 09:51:30 -0500

Trimming distro to PWE3. 

A few responses in line below related to the MH-PW requirements discussion.

Dave

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, January 19, 2005 3:37 PM
> To: [email-masked]; [email-masked]; [email-masked]
> NH=> I sincerely hope not!  That is, we must not use the 
> control-plane to determine whether the data-plane is working. 

I disagree. "Control plane" has determined whether data plane is working has
done sucessfully in packet switched networks for decades.

>  This is a fundamental OAM requirement in both the co-ps and 
> co-cs modes.  

In my experience with packet switched networks, ATM VPC/VCC style continuity
verification OAM detects a small set of failures that a control plane
overlay does not. If the control plane is not reliably establishing "data
plane" forwarding relationships, then the problem is usually with the
implementation, not the architecture.

> Further, when we have a co-cs mode network (ie 
> GMPLS case) the control-plane MUST be run OOB (at least 
> logically, but maybe also physically) wrt to the in-band 
> The key words in your para above are *pre-provisioned*.  And 
> I agree with you on this.....one cannot create 'topology on 
> the fly' as basic physics prevents this.
> 
> There are 2 cases here wrt MPLS and GMPLS and they are quite 
> different. However, in all cases the functional architecture 
> rule of nested layer networks holds, ie a client layer 
> link-connection (ie the 'line' we draw between adjacent nodes 
> in some layer network) is supported by a trail in a lower 
> layer network...this is the essence a 'truth' of topology 
> creation and it's a relationship that recurses to the duct.  
> Now let's look at the 2 cases in a bit more detail:
> 
> MPLS - this is a digital wrapper in the data-plane, ie 'just 
> add a label and create a lower level LSP at will'.  Each LSP 
> however does NOT create a new layer network.  Those familiar 
> with the functional arch modelling of MPLS will probably also 
> realise that each LSP, no matter where it appears in a nested 
> stack of LSPs, belongs to the SAME layer network (perhaps not 
> so easy to visualise?).  It's not the IP layer network 
> however despite using IP structured addresses for 
> LSPs....just like using IP structured addresses for the 
> access points of a SDH VC4 layer network does not make the 
> SDH VC4 layer network part of the IP layer network!  However, 
> there is still something not quite right here...all LSPs 
> SHOULD use the SAME access point addressing no matter how 
> they are created (be it via signalling protocol X, Y or Z or 
> NMS manual provisioning).  This is because THIS address 
> belongs to the data-plane and it should be agnostic to the 
> control-plane used.  Not the case in MPLS.  This issue 
> becomes rather important for (OAM) Connectivity Verification 
> when there are misconnectivity defects between LSPs created 
> by different means.
>   
> The fact there is a routing process that is now common to 
> both the IP and MPLS layer networks has some interesting 
> consequences.  It means these layer networks cannot be 
> functionally decoupled...which might be considered 'good' if 
> the client is only ever IP, but this might not be considered 
> 'good' if:
> MPLS as a co-ps convergence transport technology....PWs are a 
> case in point here;
> commercial/security/whatever reasons).....and to address this 
> we are going to have to interpose a functional breakwater, by 
> using a PW say.
> 
> GMPLS - this is nothing at all like MPLS (despite what one 
> hears).  Here the data-plane is NOT a wrapper but a well 
> defined SDH or OTN frame structure for example.  The fact we 
> are dealing with a co-cs mode here also means that:
> feature....esp for network builder services and the carriage 
> of large traffic (any type) aggregates;
> 'very good' feature for security, resilience design  and 
> stability of this rather important part of the system;
> layer network is functionally decoupled from the other layer 
> networks. So when we have, for example, a SDH VC12 and VC4 
> layer network these might use exactly the same functional 
> components (for addressing, signalling, routing, PM, 
> whatever...and this is 'good' per se wrt to functional 
> re-use) BUT they operate in separate spaces....and to make 
> this quite clear, if I have a VC12 access point with address 
> X this obviously cannot be connected to a VC4 access point 
> which also has address X....the addresses live in different 
> spaces as we are dealing with 2 functionally decoupled layer 
> networks.  This is also a 'very good' feature for lots of 
> other reasons including scaling and the commercial separation 
> of different parties in a client/server relationship.
> 
> And all this is a forced consequence of the co-cs mode 
> itself...it is not a 'design choice' of GMPLS.  So although 
> GMPLS is nothing at all like MPLS some folks still talk 
> loosely about routing across nested co-cs layer networks..... 
> but the fact remains there MUST be something pre-provisioned 
> at some level as you quite rightly observed yourself. You can 
> go down 1 layer and do a sort-of client-driven UNI SVC 
> dial-up in the immediate server WITHOUT having access to the 
> server layer's routing function (see Note) but this assumes 
> the link-connections in THAT server are already in 
> place....you can't recurse this desire to create topology on 
> the fly right down to the duct!
> 
> Note - This is rather like making a PSTN 64k call...and its 
> also rather reminiscent of the old ATM SVC cut-though stuff 
> that folks said was no good....yet seems it's OK here?
> 
> So, MPLS is nothing like GMPLS.  In GMPLS we can consciously 
> avoid the problems of a wrapper because co-cs layer networks 
> don't use wrappers. However, one cannot avoid these 
> consequences in MPLS (at least as-is).
> 
> regards, Neil
> 
> 
> > 
> > Dave
> > 
> > > Of [email-masked]
> > > important point here that has troubled me and many folks 
> in BT for a 
> > > long time.  I can summarise this as follows:
> > > 
> > > When we have a topology of nodes and links in some layer network 
> > > that we wish to route a path across, there is an
> > > We can restate this in a different way (and I am 
> tailoring this for 
> > > the PW case, but it can be generalised to any case of nested layer
> > > networks):
> > > 
> > > to be in place (for EACH link/segment of the MH PW LSP as per the 
> > > recursion principle noted previously)
> > > In other words we cannot create 'topology on the 
> fly'......a level 
> > > or pre-provisioning is a key requirement/assumption here. 
>  But yet 
> > > in MPLS this assumes this is indeed possible (a similar 
> issue occurs 
> > > in GMPLS when folks talk of 'TE links' and 'FAs').  
> Clearly this is 
> > > a nonsense. It's not a problem in MPLS as-is *provided* 
> we only ever 
> > > have 2 levels of LSP AND  the top level LSP is not actually a true
> > > control-plane (or more accurately the client layer network across 
> > > ALL planes) is independent of the server MPLS (PW) control-plane 
> > > (network)....and this is a 'good thing' as one can can now 
> > > functionally decouple the client (whatever it is) and 
> server (MPLS) 
> > > layer networks.  Can't do this in MPLS per se 
> however......currently 
> > > there is no good way of creating a 'functional 
> breakwater' between 2 
> > > MPLS layer networks except by PWs and some other 
> technology.  As I 
> > > noted, this is not a problem when we only have a single layer 
> > > network in MPLS and a higher level LSP is not really a 'networked 
> > > LSP' but a 1-hop client ID proxy.  MH PWs start to change this 
> > > picture however.....and so does client/server i/w between 2 
> > > operators A and B say, who both have MPLS networks and where 
> > > operator A wants to lease transport capacity off operator B but 
> > > neither operator wants to functionally peer with each other.
> > >

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 25 Jan 2005 10:46:04 -0500

On Jan 25, 2005, at 9:51 AM, David McDysan wrote:

> I disagree. "Control plane" has determined whether data plane is 
> working has done sucessfully in packet switched networks for decades.

	I think that might be because control plane messages
might have been following the same path as data plane
messages. In those cases the control plane will usually
detect failures; however, once you break the two apart,
all bets are off.

> implementation, not the architecture.

	Or with "fat fingers". *)  Many of the operators I have
talked to about troubles scenarios have told me that
upwards of %80 of faults are caused by mis-configuration.
So I would say that you are both correct in that
what is really needed is both data plane and control
plane OAM, and specifically the combination of both
to verify each other's view of the world.  This seems
to cover most of the cases.

>> when there are misconnectivity defects between LSPs created

	Although I don't quite still understand the requirement
for different addressing, I do agree that mis-configuration
is a major cause of defects (see above).

	--Tom

---

From: [email-masked]
Date: Tue, 25 Jan 2005 18:39:31 -0000

Thanks Tom....some remarks in-line.  

Thomas D. Nadeau wrote 25 January 2005 15:46
> >>> This would certainly be an issue for manual provisioning of PWs. 
> >>> When PEs use IP routing then the pre-provisioned 
> existence of these 
> >>> lower layer connections is confirmed periodically by 
> in-band routing 
> >>> protocol message exchange.
NH=> You may like to observe that most co-cs mode networks (like the
PSTN and SDH for example) have a packet-switched
control/management-plane network.  This does not, and indeed cannot,
proxy for the OAM in the *traffic* data-plane.  The same argument can be
applied to co-ps mode networks if these are using OOB
control/management.
> detect failures; however, once you break the two apart,
NH=> This is a normal behaviour in a cl-ps mode network.
> 
> >>  This is a fundamental OAM requirement in both the co-ps and co-cs 
> >> modes.
> >
NH=> I agree.  One does not need many misconnected instances to cause a
bad PR event for an operator.  Of course, when one is dealing with the
co-cs mode this is a forced requirement...as there are 2 disjoint
networks (and using different modes) that are working in the same
overall network system.
> >> GMPLS case) the control-plane MUST be run OOB (at least logically, 
> >> but maybe also physically) wrt to the in-band traffic.  But let me 
> >> come back on the main point of this thread......
> >>
> >> different. However, in all cases the functional 
> architecture rule of 
> >> nested layer networks holds, ie a client layer link-connection (ie 
> >> the 'line' we draw between adjacent nodes in some layer 
> network) is 
> >> supported by a trail in a lower layer network...this is 
> the essence a 
> >> 'truth' of topology creation and it's a relationship that 
> recurses to 
> >> the duct. Now let's look at the 2 cases in a bit more detail:
> >>
> >> MPLS - this is a digital wrapper in the data-plane, ie 'just add a 
> >> label and create a lower level LSP at will'.  Each LSP 
> however does 
> >> NOT create a new layer network.  Those familiar with the 
> functional 
> >> arch modelling of MPLS will probably also realise that 
> each LSP, no 
> >> matter where it appears in a nested stack of LSPs, belongs to the 
> >> SAME layer network (perhaps not so easy to visualise?).  
> It's not the 
> >> IP layer network however despite using IP structured addresses for
NH=> Tom, not sure if I get your question correctly, but let me give a
couple of answers to what I think you might be alluding to:
-	The reason we have different addressing instances in each layer
network is that we can't connect together access points belonging to
different layer networks, eg even if the VC12 and VC4 layers in SDH use
exactly the same addressing structure I can't connect a VC12 access
point to a VC4 access point and create a meaningful network trail.  I
can extrapolate this to the access points of all the different layer
networks, eg ATM, FR, PDH, etc.  Worth noting of course that the access
points of many layer networks don't have well-defined addressing
structures.  If you want to know more about what I am talking about here
have a look at chapters 3 and 4 of Reid/Sexton 'Broadband Networking'.
-	The CV function is a common theme in all 3 modes.  It 'comes for
free' in the cl-ps mode by virtue of the SA in each/every packet, though
I suspect most folks never think about it like this...this is also why
there is no 'merging' in the cl-ps mode, only muxing.  However we have
to consciously add it with the co-cs and co-ps modes to verify we have
got (and maintain) correct connectivity.  In the co-cs mode the frame
structure is the natural places to put this (cf J0 byte in SDH VC4).  In
the co-ps mode we have to define the period of insertion.  We then build
the defect definitions around this in terms of entry/exit criteria and
consequent actions (2 key ones being traffic suppression and, where
appropriate, FDI insertion to stop any higher layer alarms).  The reason
we need a common SA for all the trails in a *given* layer network is so
that when misconnectivity defects occur we not only have the same (SA)
processing rule in all cases, but the SA itself carries meaningful
information to identify the offending trail....so it helps diagnosis.

regards, neil
> both the IP 
> >> these layer networks cannot be functionally 
> decoupled...which might 
> >> be considered 'good' if the client is only ever IP, but this might 
> >> not be considered 'good' if:
> hears).  
> >> Here the data-plane is NOT a wrapper but a well defined SDH or OTN 
> >> frame structure for example.  The fact we are dealing with a co-cs 
> >> mode here also means that:
> stability of 
> >> networks. So when we have, for example, a SDH VC12 and VC4 layer 
> >> network these might use exactly the same functional 
> components (for 
> >> addressing, signalling, routing, PM, whatever...and this is 'good' 
> >> per se wrt to functional
> this quite 
> >> clear, if I have a VC12 access point with address X this obviously 
> >> cannot be connected to a VC4 access point which also has address 
> >> X....the addresses live in different spaces as we are 
> dealing with 2 
> >> functionally decoupled layer networks.  This is also a 'very good' 
> >> feature for lots of other reasons including scaling and the 
> itself...it is 
> >> co-cs layer networks..... but the fact remains there MUST be 
> >> something pre-provisioned at some level as you quite 
> rightly observed 
> >> yourself. You can go down 1 layer and do a sort-of 
> client-driven UNI 
> >> SVC dial-up in the immediate server WITHOUT having access to the
> >> Note - This is rather like making a PSTN 64k call...and its also 
> >> rather reminiscent of the old ATM SVC cut-though stuff that folks 
> >> said was no good....yet seems it's OK here?
> >>
> >> So, MPLS is nothing like GMPLS.  In GMPLS we can consciously avoid 
> >> the problems of a wrapper because co-cs layer networks don't use 
> >> wrappers. However, one cannot avoid these consequences in MPLS (at 
> >> least as-is).
> >>
> >> regards, Neil
> >>
> >>
> >>>
> >>> Dave
> >>>
> >>>> [email-masked]; [email-masked]; [email-masked]; 
> >>>> [email-masked]; [email-masked]; [email-masked];
> >>>> together) in THIS layer network really exist, ie they 
> are ALREADY 
> >>>> provisioned in some manner between the nodes in THIS 
> layer network. 
> >>>> However, these link-connections are provided by trails 
> (ie end-end
> LSP).....this can 
> >>>> continue for as many LSPs as there are nested, but let's 
> stop the 
> >>>> LSP nesting here
> >>>> path to be in place...again for EACH of its link 
> connections, but 
> >>>> let's take this recursive/general requirement to be as-read from 
> >>>> now on
> >>>> networked LSP but merely a p2p 1-hop entity where the 
> label proxies 
> >>>> for a client identifier function (which is precisely 
> what we find 
> >>>> with rfc2547 VPNs and SH PWs).  However, for MH PWs each 
> >>>> link-connection here (ie between PW switching capable nodes) 
> >>>> requires a 'regular' lower level LSP to be in place 
> before traffic 
> >>>> can be sent, or indeed MH PW LSP routes to be calculated 
> with any 
> >>>> valid sense...and this requires even lower level trails to be in 
> >>>> place, etc, etc, until we get to the duct.
> >>>>

---

From: [email-masked]
Date: Wed, 26 Jan 2005 13:52:02 -0000

Hi Scott...good to have your comments on this.  Please see my response
below.

Scott W Brim wrote 26 January 2005 10:30
> On 1/25/2005 13:39, [email-masked] allegedly wrote:
>  >> There are 2 cases here wrt MPLS and GMPLS and they are 
> quite  >> different. However, in all cases the functional 
> architecture rule  >> of nested layer networks holds, ie a 
> client layer link-connection  >> (ie the 'line' we draw 
> between adjacent nodes in some layer  >> network) is 
> supported by a trail in a lower layer network...this is  >> 
> the essence a 'truth' of topology creation and it's a 
> relationship  >> that recurses to the duct. Now let's look at 
> the 2 cases in a bit  >> more detail:  >>  >> MPLS - this is 
> a digital wrapper in the data-plane, ie 'just add a  >> label 
> and create a lower level LSP at will'.  Each LSP however does 
> functional  >> arch modelling of MPLS will probably also 
> realise that each LSP, no  >> matter where it appears in a 
> nested stack of LSPs, belongs to the  >> SAME layer network 
> (perhaps not so easy to visualise?).  It's not  >> the IP 
> layer network however despite using IP structured addresses  
> >> for LSPs....just like using IP structured addresses for 
> the access  >> points of a SDH VC4 layer network does not 
> make the SDH VC4 layer  >> network part of the IP layer 
> network!  However, there is still  >> something not quite 
> right here...all LSPs SHOULD use the SAME  >> access point 
> addressing no matter how they are created (be it via  >> 
> signalling protocol X, Y or Z or NMS manual provisioning).  
> This is  >> because THIS address belongs to the data-plane 
> and it should be  >> agnostic to the control-plane used.  Not 
> the case in MPLS.  This  >> issue becomes rather important 
> for (OAM) Connectivity Verification  >> when there are 
> misconnectivity defects between LSPs created by  >> different means.
> 
> Neil,
> 
> The IP addresses are used for control messages.  The control messages 
> themselves refer to LSP endpoints (and intermediate points for 
> MH-PWs), and do so in terms of TAIs.  In this particular use of MPLS 
> -- multi-hop pseudowires -- TAIs are the layer network endpoint 
> identifiers.  Also, unlike single-hop pseudowires, multi-hop 
> pseudowires do create a new layer network with trails based on 
> concatenated PWs.
NH=> In principle you are partly correct but not completely.  But I
suspect many folks won't recognise the importance or relevance of what
you are saying (or probably what I will now say on this).  I have been
making the following points for a long time (though it often feels like
I am banging my head on wall here, but lets have one more go)....that
is:
-	when we are dealing with SH PWs the top-level 'LSP' is not a
networked entity....its job is purely to recover from any lower layer
merging due to LDP mp2p or PHP (both these create a merging behaviour);
-	so here the top-level label is more like part of an adaptation
function (noting that in a simple client/server case one does not need
more than a single server trail);
-	move to MH PWs however and the situation is now very different.
Now we do have networked LSP entities *at 2 levels*.  In fact the server
LSPs (however instantiated) are the trails that create/support the
link-connections of the top MH PW LSP.
-	this illustates the digital wrapper behaviour of MPLS (which is
latent when we have only a single networked level, and so has not been
really noticed to date) and exposes the 'topology on the fly' problem,
ie you cannot compute a route across the topology that will be used for
the MH PW LSP *until* all the link-connections in this topology are
in-place, ie the server layer LSPs need to be created/installed 1st
(noting that this requirement recurses all the way down to the duct for
all client_link-connection/server_trail paired relationships);
-	But because MPLS is a digital wrapper each level of LSP does
*not* create a new layer network (so this is where we disagree).  MPLS
itself however is a layer network (in that it is not part of the IP
layer network or the SDH VC4 layer network or whatever).....in other
words LSPs should have distinct addresses and they do get them, but they
are different dependent on the signalling used (which is not right
either for OAM CV considerations as I pointed out to Tom in a
prior/snipped part of this thread).
-	This is also why (for the inter-provider case) we cannot create
a simple client/server relationships between 2 functionally decoupled
MPLS layer network belonging to 2 different parties.....the only way to
do this is to insert a PW which provides a 'functional breakwater'.

Now let me come back on the data-plane and control-plane (and indeed
management-plane) addressing issue.  In co-ps and co-os mode networks
one can have an OOB control/management-plane network (and there are very
good reasons, inc security and stability/resilience design, for
requiring this).....in fact for the co-cs mode case this is not even an
option, it's a forced requirement due to the nature of the co-cs mode.
This means that in the *same* networking system there are 2 different
data-plane networks working in concert, ie one data-plane carries
traffic (including *all* planes of any clinet layer networks) and the
other data-plane carries control and management protocols.   Note also
that although the traffic data-plane may be co-cs or co-ps in nature the
control/management data-plane is usually cl-ps in nature (though it will
run in its own co-cs or co-ps partition....go look at how SDH works if
you need a practical example).  Both these data-plane networks have a
set of functional components that define/control/manage them (though
they are very different in behaviour)...and in particular they have a
set of access points (which need an addressing scheme) that are NOT
related to each other in terms of creating connectivity between them.

Now let me briefly remark on Tom's observation (that appeared in
different mail response) about using IP addresses.  Sure we can use
IP-structured addressing for the access points in all layer networks
(all modes, including taking the points wrt OOB I made above) but the
key point is that when we are dealing with *different* layer networks
these addresses exist in different spaces, ie we cannot have arbitrary
connectivity between them.  And referring back to my point wrt the co-cs
and co-ps modes and OOB control/management, this is a very good thing
wrt to imposing strong security.

regards, neil	
> Scott

---

From: David McDysan <[email-masked]>
Date: Wed, 26 Jan 2005 13:27:31 -0500

Hi Neil,

Suggest that this thread would be more constructive if we could focus on
specific proposed requirements. A few remarks in-line below toward this end.

Dave

> Sent: Wednesday, January 26, 2005 8:52 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Hi Scott...good to have your comments on this.  Please see my 
> response below.
> 
>  >> There 
> > are 2 cases here wrt MPLS and GMPLS and they are quite  >> 
> different. 
> > However, in all cases the functional architecture rule  >> 
> of nested 
> > layer networks holds, ie a client layer link-connection  >> (ie the 
> > 'line' we draw between adjacent nodes in some layer  >> network) is
> NH=> In principle you are partly correct but not completely.  
> But I suspect many folks won't recognise the importance or 
> relevance of what you are saying (or probably what I will now 
> say on this).  I have been making the following points for a 
> long time (though it often feels like I am banging my head on 
> wall here, but lets have one more go)....that
> is:
> networked entity....its job is purely to recover from any 
> lower layer merging due to LDP mp2p or PHP (both these create 
> a merging behaviour);
> function (noting that in a simple client/server case one does 
> not need more than a single server trail);

As was suggested earlier on this thread, an Annex mapping the IETF
terminology to G.805/G.809 would be instructive and you may find that this
object is more productive in putting a hole in the wall instead of your
head. :)

> Now we do have networked LSP entities *at 2 levels*.  In fact 
> the server LSPs (however instantiated) are the trails that 
> create/support the link-connections of the top MH PW LSP.
> latent when we have only a single networked level, and so has 
> not been really noticed to date) and exposes the 'topology on 
> the fly' problem, ie you cannot compute a route across the 
> topology that will be used for the MH PW LSP *until* all the 
> link-connections in this topology are in-place, ie the server 
> layer LSPs need to be created/installed 1st (noting that this 
> requirement recurses all the way down to the duct for all 
> client_link-connection/server_trail paired relationships);
> *not* create a new layer network (so this is where we 
> disagree).  MPLS itself however is a layer network (in that 
> it is not part of the IP layer network or the SDH VC4 layer 
> network or whatever).....in other words LSPs should have 
> distinct addresses and they do get them, but they are 
> different dependent on the signalling used (which is not 
> right either for OAM CV considerations as I pointed out to 
> Tom in a prior/snipped part of this thread).
> a simple client/server relationships between 2 functionally 
> decoupled MPLS layer network belonging to 2 different 
> parties.....the only way to do this is to insert a PW which 
> provides a 'functional breakwater'.

To me, the above description seems to assume an OOB and/or manual
configuration of the LSPs. As such, suggest that you strive to state these
requirements in that context. However, I believe there is also the "in-band"
IP-based control/management approach that some providers will want to
deploy. I believe there is a need for these to interoperate, and a PW
switching point may be able to support this need.

> management-plane) addressing issue.  In co-ps and co-os mode 
> networks one can have an OOB control/management-plane network 
> (and there are very good reasons, inc security and 
> stability/resilience design, for requiring this).....in fact 
> for the co-cs mode case this is not even an option, it's a 
> forced requirement due to the nature of the co-cs mode. This 
> means that in the *same* networking system there are 2 
> different data-plane networks working in concert, ie one 
> data-plane carries traffic (including *all* planes of any 
> clinet layer networks) and the
> that although the traffic data-plane may be co-cs or co-ps in 
> nature the control/management data-plane is usually cl-ps in 
> nature (though it will run in its own co-cs or co-ps 
> partition....go look at how SDH works if you need a practical 
> example).  Both these data-plane networks have a set of 
> functional components that define/control/manage them (though 
> they are very different in behaviour)...and in particular 
> they have a set of access points (which need an addressing 
> scheme) that are NOT related to each other in terms of 
> creating connectivity between them.

Not sure what you are looking for in terms of MH-PW requirements in terms of
addressing. 

> 
> Now let me briefly remark on Tom's observation (that appeared 
> in different mail response) about using IP addresses.  Sure 
> we can use IP-structured addressing for the access points in 
> all layer networks (all modes, including taking the points 
> wrt OOB I made above) but the key point is that when we are 
> dealing with *different* layer networks these addresses exist 
> in different spaces, ie we cannot have arbitrary connectivity 
> between them.  

I agree that IP addresses could be used and have proposed that be added to
the MH-PW requirements draft. It appears that you agree. 

Just because different network elements have addresses from the same family
does not mean that the IP-based signaling protocols will allow arbitrary
connectivity. I am also open to including requirements for other
architectures and operational models. 

Are you thinking of using address/name space segregation to constrain
connectivity between one or more OOB management systems, which may not have
the checks on connectivity specified in the IP-based signaling protocols? If
so, it would be helpful to state a requirement in this way.

> And referring back to my point wrt the co-cs 
> and co-ps modes and OOB control/management, this is a very 
> good thing wrt to imposing strong security.
> 

Suggest that some text be included for the security section discussing the
security advantages and disadvantages of out-of-band versus in-band
control/management.

---

From: David McDysan <[email-masked]>
Date: Wed, 26 Jan 2005 13:27:31 -0500

Scott,

Are you impliying that the TAI contains information on which a routing
decision can be made, or only that it (in combination with the node's (IP)
address) is a globally unique PW endpoint identifier?

Dave

> Behalf Of Scott W Brim
> Sent: Wednesday, January 26, 2005 5:30 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: [email-masked]
Date: Thu, 27 Jan 2005 06:51:02 -0000

Dave....against your remark please see below....

> From: David McDysan [mailto:[email-masked]]
> Sent: 26 January 2005 17:53
> To: Harrison,N,Neil,IKM1 R; [email-masked]
> Cc: [email-masked]
> Tom, Neil,
> A few comments in line below.
> 
> Dave
> 
> > From: [email-masked] [mailto:[email-masked]] Thomas
> > D. Nadeau wrote 25 January 2005 15:46

> > proxy for the OAM in the *traffic* data-plane.  The same argument 
> > can be applied to co-ps mode networks if these are using OOB 
> > control/management.
> 
> DM: Most packet switched networks use "inband" control and avoid the 
> additional complexity of needing to confirm that the data plane 
> connections are congruent with the control plane configuration. An SS7

> continutity check is an example of such additional complexity that is 
> necessary with out-of-band control.
NH=> No one is suggesting this.  When we come to to look at
short-holding *public* SVCs (under customer/UNI control) I think we are
entering a different (service) ball game which impacts many things wrt
how such services are specified/monitored (and priced)....say compared
to S-PVC based network builder services, which are the foundation of
private services and whose topology is long-holding.  Like the attitude
towards the 3 network modes, a '1 size fits all' approach is flawed.

> Regarding advancing the MH-PW
> requirements work, I suggest adding a requirement that the 
> protocol be able to support "in-band" as well as 
> "out-of-band" control. I would look for service providers 
> advocating "out-of-band" control to articulate the associated 
> requirements in greater detail.
NH=> I agree folks should indeed do this....the requirements are pretty
obvious and compelling IMO.  I mean, why on Earth should the *internal*
protocols that determine network control and management be exposed to
hacking when there is no good reason for this?  Only a fool or a madman
would argue against this IMO.

> I plan to focus on 
> requirements the "in-band" control for PW and MPLS. 
> Hopefully, there will be some overlap in requirements for 
> "in-band" and "out-of-band," but I expect that there will 
> also be differences.
NH=> OK....so we trade complexity(?) of OOB for complexity of security
IB?....Hmmm.  I'm not just talking control-plane here but also
management-plane.  So I'm not sure this is even a valid/useful argument.
But you will have NO CHOICE when it comes to the major transport
technologies (which are all co-cs mode) since these FORCE OOB.....like
it or not.  The GMPLS folks have had to come to terms with this....not
saying I agree with all their concepts (in fact I am not impressed by
the reluctance to embrace more rigorous functional architecture
descriptions and the use of woolly concepts such as 'TE links' that
imply an ability to create topology on the fly that is 'sold' in this
stuff).  Folks need to get on the page of the the 3 modes being
different (and for real/good reasons) and how func arch allows one to
describe/understand networks (esp for developing management information
models).  Living in a single/flat network view of the world might work
fine for some stuff (like public Internet) but it for sure does not
address the bigger service vista of major operators IMO.

regards, Neil
<snipped to end as there was nothing new after this>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 27 Jan 2005 05:00:06 -0500

On Jan 26, 2005, at 12:52 PM, David McDysan wrote:

>> NH=> You may like to observe that most co-cs mode networks
>> (like the PSTN and SDH for example) have a packet-switched
>> control/management-plane network.  This does not, and indeed
>> cannot, proxy for the OAM in the *traffic* data-plane.  The
>> same argument can be applied to co-ps mode networks if these
>> are using OOB control/management.
>
> connections
> are congruent with the control plane configuration. An SS7 continutity 
> check
> is an example of such additional complexity that is necessary with
> out-of-band control. Regarding advancing the MH-PW requirements work, I
> suggest adding a requirement that the protocol be able to support 
> "in-band"
> as well as "out-of-band" control. I would look for service providers
> requirements
> in greater detail. I plan to focus on requirements the "in-band" 
> control for
> PW and MPLS. Hopefully, there will be some overlap in requirements for
> "in-band" and "out-of-band," but I expect that there will also be
> differences.
>
>>>
>>> might have been following the same path as data plane messages. In
>>> those cases the control plane will usually detect failures;
>> however,
>>> once you break the two apart, all bets are off.
>>>> In my experience with packet switched networks, ATM VPC/VCC style
>>>> continuity verification OAM detects a small set of failures that a
>>> control plane
>>>> overlay does not. If the control plane is not reliably
>> establishing
>>>> "data
>> talked to
>>> about troubles scenarios have told me that upwards of %80 of faults
>>> are caused by mis-configuration. So I would say that you are both
>>> correct in that what is really needed is both data plane and control
> Tom, could you please say a little more about what you mean by "control
> plane OAM?"

	I mean things that pertain to the maintenance and monitoring
of the control plane.  An example of this would be if you
were using targeted LDP to signal the MH-PW, you would want
control plane to able to signal/relay certain status messages
from the MH PW.   You might want to check that if the
control plane hasn't sent back these messages, that the
data plane actually jives with this "up" status, for example.

	--Tom

>
>> NH=> I agree.  One does not need many misconnected instances
>> to cause a bad PR event for an operator.  Of course, when one
>> is dealing with the co-cs mode this is a forced
>> requirement...as there are 2 disjoint networks (and using
>> different modes) that are working in the same overall network system.
>>>
>> logically,
>>>>> LSPs....just like using IP structured addresses for the access
>>>>> points of a SDH VC4 layer network does not make the SDH
>> VC4 layer
>>>>> network part of the IP layer network!  However, there is still
>>>>> something not quite right here...all LSPs SHOULD use the SAME
>>>>> access point addressing no matter how they are created
>> (be it via
>>>>> signalling protocol X, Y or Z or NMS manual
>> provisioning).  This is
>>>>> because THIS address belongs to the data-plane and it should be
>>>>> agnostic to the control-plane used.  Not the case in MPLS.  This
>>>>> issue becomes rather important for (OAM) Connectivity
>> Verification
>> NH=> Tom, not sure if I get your question correctly, but let
>> me give a couple of answers to what I think you might be alluding to:
>> network is that we can't connect together access points
>> belonging to different layer networks, eg even if the VC12
>> and VC4 layers in SDH use exactly the same addressing
>> structure I can't connect a VC12 access point to a VC4 access
>> point and create a meaningful network trail.  I can
>> extrapolate this to the access points of all the different
>> layer networks, eg ATM, FR, PDH, etc.  Worth noting of course
>> that the access points of many layer networks don't have
>> well-defined addressing structures.  If you want to know more
>> about what I am talking about here have a look at chapters 3
>> and 4 of Reid/Sexton 'Broadband Networking'.
>> free' in the cl-ps mode by virtue of the SA in each/every
>> packet, though I suspect most folks never think about it like
>> this...this is also why there is no 'merging' in the cl-ps
>> mode, only muxing.  However we have to consciously add it
>> with the co-cs and co-ps modes to verify we have got (and
>> maintain) correct connectivity.  In the co-cs mode the frame
>> structure is the natural places to put this (cf J0 byte in
>> SDH VC4).  In the co-ps mode we have to define the period of
>> insertion.  We then build the defect definitions around this
>> in terms of entry/exit criteria and consequent actions (2 key
>> ones being traffic suppression and, where appropriate, FDI
>> insertion to stop any higher layer alarms).  The reason we
>> need a common SA for all the trails in a *given* layer
>> network is so that when misconnectivity defects occur we not
>> only have the same (SA) processing rule in all cases, but the
>> SA itself carries meaningful information to identify the
>> offending trail....so it helps diagnosis.
>>
>> regards, neil
>>>
>>> 	--Tom
>>>
>>>
>>>>>
>>>>> server layer's routing function (see Note) but this assumes the
>>>>> link-connections in THAT server are already in
>> place....you can't
>>>>> recurse this desire to create topology on the fly right
>> down to the
>>>>> duct!
>>>>>
>>>>>>> network are provided by trails in an EVEN LOWER lower
>> layer layer
>>>>>>> network (eg SDH VC4).  This behaviour (ie a client layer
>>>>>>> link-connection is provided by a server layer trail) recurses
>>>>>>> until we hit the duct.
>>>>>>>
>>>>>>> [email-masked] https://www1.ietf.org/mailman/listinfo/pwe3
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 27 Jan 2005 05:02:58 -0500

> architectures and operational models.

	Exactly. There are already mechanisms in place for security
of LDP sessions which can be re-used.  WRT segreation of
OOB management systems, this again has existing authentication/
security mechanisms that could be re-used.

> security advantages and disadvantages of out-of-band versus in-band

	Good idea.

	--Tom

---

From: [email-masked]
Date: Thu, 27 Jan 2005 10:38:17 -0000

Tom/Dave,

<snipped>

> > Tom, could you please say a little more about what you mean by 
> > "control plane OAM?"
> 
> 	I mean things that pertain to the maintenance and 
> monitoring of the control plane.  An example of this would be 
> if you were using targeted LDP to signal the MH-PW, you would 
> want control plane to able to signal/relay certain status messages
NH=> Might be useful to expand on this a bit...for example:

-	all protocols need their own OAM.  For example, a signalling
protocol should devote considerable attention to the handling of
'exception events', ie when things don't work as planned such as when
messges get lost/corrupted and/or timers expire.

This has nothing to do with any data-plane that *this* protocol is
running on, or indeed the traffic data-plane.  Folks don't think about
stuff like this as 'OAM' IMO, but it is.

We can generalise this observation to all such protocols, ie each
protocol/function needs to look after itself.  And of course, such
issues should be second nature to folks in IETF for routing protocols.
But there is more to networking than just routing........

-	in the cl-ps mode it has been traditional that all protocols
funnel down the same data-plane...so its quite natural to understand why
folks relied on (say) the routing protocol to say something about the
nature of the link-connections that connected adjacent nodes.  Noting
that since a link-connection is supported by a lower level trail, and
that this recurses to the duct, this says something about the the whole
stack being 'up' and working.

-	when we consider the co-cs mode we are forced to run the
control/management protocols OOB wrt to the traffic.  This implies that
there are at least 2 data-plane networks in the same networking
system....and even within a node they have differenmt HW/SW processing.
This means you simply cannot use routing (or signnaling) protocols to
proxy for knowing when the traffic data-plane is working or not.
Further, the design of the 2 data-plane networks is quite different (esp
for survivability considerations).

-	the co-ps mode lies somewhere between the cl-ps and co-cs modes.
I have some views on what the right/ideal co-ps mode network should look
like, but this is not for discussion here.  All I want to point out is
that it is not the same as either the cl-ps mode or the co-cs mode (and
these are not the same either).  The differences are manifested in many
ways.  I have already mentioned that the co-cs mode forces an OOB
approach for control/management.  But the defects are different too.  We
can only have 'breaks' in the cl-ps mode.  In the co-cs mode we can have
both breaks and swaps (but constrained to exist only between exactly
alike trail entities).  In the co-ps mode we can have breaks, swaps (any
entities) and various mibranching/mismerging cases.  I have explained in
past mails why the above is and also why there is a common CV function
that runs across all 3 modes....however its execution is different in
the 3 modes, as are the defects and their definitions in terms of
entry/exit criteria and consequent actions.

None of this is rocket science....in fact its all obvious IMO and common
sense.  But it does require folks stand back and understand that when we
are dealing with 3 different network modes trying to force a '1 size
fits all' approach is not a good idea.

regards, neil

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 27 Jan 2005 07:12:06 -0500

On Jan 27, 2005, at 5:38 AM, [email-masked] wrote:

> -	all protocols need their own OAM.

	I agree, but would extend this a bit. For complete
solutions where multiple protocols are required to work together,
the solutions should also be constructed such that OAM
from both can be leveraged (either online or offline).

> For example, a signalling

	I do. :P

> proxy for knowing when the traffic data-plane is working or not.

	This is very true. You need to test each independently and
then compare results.  Both may lie, so it is important
to not rely on one or the other alone.

	--tom

---

From: David McDysan <[email-masked]>
Date: Thu, 27 Jan 2005 10:50:51 -0500

> From: Thomas D. Nadeau [mailto:[email-masked]] 
> > Tom, Neil,
> >
> (like the 
> >> proxy for the OAM in the *traffic* data-plane.  The same 
> argument can 
> >> be applied to co-ps mode networks if these are using OOB 
> >> control/management.
> >
> > continutity check
> messages. In 
> >>> plane OAM, and specifically the combination of both to 
> verify each 
> >>> other's view of the world.  This seems to cover most of the cases.
> >

If you mean using (something like) VCCV to confirm data plane "liveliness"
state of the PW and comparing this with the state determined by the control
signaling protocol then I agree. I think there are some additional
requirements related to MH-PW that were mentioned on this thread that relate
to being able do this on a SH PW segment basis of a MH PW in support of at
least diagnostics and also performance measurement that I believe should be
stated as a requirement.

Snipped to the end.

---

From: David McDysan <[email-masked]>
Date: Thu, 27 Jan 2005 10:50:51 -0500

Neil,

I agree that the modes can be different.  In particular circuit switched
networks need to be OOB.

However, what I would like to discuss is specific MH-PW requirements, and
not general architectural considerations. 

Dave

> Sent: Thursday, January 27, 2005 1:51 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> > > > > A few responses in line below related to the MH-PW 
> requirements 
> > > > > discussion.
> > > > >
> > > > > Dave
> > > >
> > > > >> Hi Dave,
> short-holding *public* SVCs (under customer/UNI control) I 
> think we are entering a different (service) ball game which 
> impacts many things wrt how such services are 
> specified/monitored (and priced)....say compared to S-PVC 
> based network builder services, which are the foundation of 
> private services and whose topology is long-holding.  Like 
> the attitude towards the 3 network modes, a '1 size fits all' 
> approach is flawed.
> 
> NH=> I agree folks should indeed do this....the requirements 
> are pretty obvious and compelling IMO.  I mean, why on Earth 
> should the *internal* protocols that determine network 
> control and management be exposed to hacking when there is no 
> good reason for this?  Only a fool or a madman would argue 
> against this IMO.
> 
> > I plan to focus on
> NH=> OK....so we trade complexity(?) of OOB for complexity of 
> security IB?....Hmmm.  I'm not just talking control-plane 
> here but also management-plane.  So I'm not sure this is even 
> a valid/useful argument. But you will have NO CHOICE when it 
> comes to the major transport technologies (which are all 
> co-cs mode) since these FORCE OOB.....like it or not.  The 
> GMPLS folks have had to come to terms with this....not saying 
> I agree with all their concepts (in fact I am not impressed 
> by the reluctance to embrace more rigorous functional 
> architecture descriptions and the use of woolly concepts such 
> as 'TE links' that imply an ability to create topology on the 
> fly that is 'sold' in this stuff).  Folks need to get on the 
> page of the the 3 modes being different (and for real/good 
> reasons) and how func arch allows one to describe/understand 
> networks (esp for developing management information models).  
> Living in a single/flat network view of the world might work 
> fine for some stuff (like public Internet) but it for sure 
> does not address the bigger service vista of major operators IMO.
> 
> regards, Neil

---

From: [email-masked]
Date: Fri, 28 Jan 2005 10:22:09 -0000

Tom...

Wrt your mail 28 January 2005 06:49

<snipped>
> > requirements related to MH-PW that were mentioned on this 
> thread that 
> > relate
> > to being able do this on a SH PW segment basis of a MH PW 
> in support 
> > of at
> 	This is something we should talk about when we
> can get together next (with Luca).  We figured out
> how to do a lot of this already, just haven't
> released it.
> 
> 	--Tom
NH=>  Well, I'm not convinced this has been 'figured out' to what I
think are the key requirements to be met.  Let me list some and you can
tell me how well they are satisfied:

1	In any client/server relationship (and PWs are for sure this)
one wants the management of the server to be independent of the
client.....so that we can use the same (server) processing in all cases.
Note functional re-use/simplification is a key goal to reduce complexity
and opex (noting this plays through from NE to NMS/OSS efficacy).  

2	In any client/server relationship the most basic requirement of
all is client (all planes) transparency over the server....or putting it
another way, complete functional decoupling of the client and the server
layer networks (this is NOT a specific OAM issue of course, its the most
basic yet most important network arch requirement per se, but it does
impact OAM).

4	There are 2 major types of OAM:  (i) 'always on' defect
detection/handling and (ii) 'on-demand' diagnostics, PM.  The former
must be sorted before we can sensibly consider the latter, and the
former must be simple/complete.....noting that the requirements to be
met are NOT identical for each network mode.

3	The defects that can affect each of the 3 network modes are
different.  If we are dealing with MPLS as the server there should be
breaks, swaps and mismerging defects specified in terms of clear
entry/exit criteria and consequent actions....see next item.

4	Defect detection/handling needs to be in the traffic data-plane
and unidirectional.  In particular, consequent actions need to be taken
at the trail sink.  This is vital so that p2p and p2mp constructs can be
handled similarly/scalably.  2 key consequent actions (if the client is
co) are (i) traffic suppression and (ii) FDI insertion to stop alarm
storms.  The precise syntax of FDI depends on the client technology.

5	The activation/deactivation of the defect detection/handling
aspects of OAM must be done in concert with however the trail is
set-up/taken-down (this can be via signalling or management).

6	Before we can progress to PM we must have a clear definition of
the available state...as PM measurements (at least for any SLA purposes)
are only valid when the trail is in the available state.

Note - Defects, availability and PM need to be standardised in order to
have a common basis of specification for interworking and apportionment
(of impairments) to tandemed operator domains.

7	If either direction of a bi-directional trail enters the
unavailable state any PM measurements should be stopped for both
directions.

8	It should be possible to observe the defect/availability status
of both directions from a single end.

Note that Y.1711 was designed to meet the above requirements wrt basic
defect detection/handling in the most simple way possible IMO.  The
above are not rocket-science nor are they unreasonable IMO....in fact I
think they are rather simple and obvious requirements.  Can you assure
me that all these requirements can be met with some alternative OAM
proposals? 

Maybe Dave doesn't care about some/any of this in his network....maybe
others don't either, and I must admit I have been rather disappointed
with the inputs (mainly lack of) that I have seen other operators on the
topic of OAM in general in this forum.  This does seem to be a
persistent malaise of the operator community that they only seem to
get-wise about stuff like OAM 'after the event'...when its usually too
late to do much about it.  OAM considerations should not be some
afterthought, they should be designed-in to the architecture from t=0.

regards, Neil