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

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 26 Jan 2005 04:51:06 -0500

[snip]

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

	That sounds fine to me as long as we use IP-based addresses.
The operator is free to segregate their IP address space
as necessary to make distinctions.  What I want to avoid are
making up new addressing schemes.

	--Tom

---

From: Scott W Brim <[email-masked]>
Date: Wed, 26 Jan 2005 05:30:13 -0500

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

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.

Scott

---

From: David McDysan <[email-masked]>
Date: Wed, 26 Jan 2005 12:52:35 -0500

Tom, Neil, 

A few comments in line below.

Dave

> From: [email-masked] [mailto:[email-masked]] 
> Thomas D. Nadeau wrote 25 January 2005 15:46
> > On Jan 25, 2005, at 9:51 AM, David McDysan wrote:
> > 
> > > Trimming distro to PWE3.
> > >
> > > A few responses in line below related to the MH-PW requirements 
> > > discussion.
> > >
> > > Dave
> >
> > >> 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.
> > >
> > > I disagree. "Control plane" has determined whether data plane is 
> > > working has done sucessfully in packet switched networks
> > for decades.
> 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.

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

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

Tom, could you please say a little more about what you mean by "control
plane OAM?"

> 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.
> > 
> > >> 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.
> > >>
> > >> 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:
> > >>
> > >> 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 
> > >> when there are misconnectivity defects between LSPs created
> > >> by different means.
> > 
> 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
> > 
> > 
> > >>
> > >> 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
> > >>>>
> > >>>
> > >>>
> > >>
> > >
> > >
> > > _______________________________________________
> > > pwe3 mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/pwe3
> > >
> > 
>