Subject: PW functional model and its OAM [was: FCS retention in PWE3]

From: [email-masked]
Date: Thu, 11 Dec 2003 12:45:15 +0100

Stewart,

> VCCV is the only method that has been formally accepted bt the PWE3
> WG for further study. If you think that Y.1711 is more appropriate,
> please write a draft explaining how this works in the PWE3 context and
> why it is better. The WG will then decide the way forward through
> our normal process.

The G.805/G.809 based functional model for an Ethernet over MPLS 
connection will [likely] contain: an MPLS/ETH_A (adaptation) function that 
is connected to an MPLS_TT (trail termination) function:

                   |
                   O ETH_FP (flow point, see G.8010)
                   |
           ----------------
            \ MPLS/ETH_A /  Encapsulation of ETH MAC frame
             ------------   into MPLS packet payload
                   |
                   O MPLS_AP (access point)
                   |
              -----------
               \MPLS_TT/    Y.1711 OAM (e.g. CV, BDI, FDI)
                \     /
                 \   /
                  \ /
                   |
                   O MPLS_TCP (termination connecction point)
                   |
       other MPLS functions, or
       Server/MPLS_A function
 
The MPLS/ETH adaptation function encapsulates the ETH MAC frames into the 
MPLS packet payload (PW). The MPLS trail termination function is the 
endpoint of the MPLS Maintenance Entity (i.e. trail) and has associated 
with it MPLS OAM to perform pro-active fault management (e.g. using Y.1711 
MPLS-CV, MPLS-BDI, MPLS-FDI) or on-demand fault localisation for the 
network connection (X-to-Y in figure below).

On-demand fault localisation OAM (e.g. loopback/ping, traceroute) may also 
be sourced/sinked in MPLS test trail termination functions (centralised 
function in a node), which may be connected to the MPLS serial compound 
link connection (between ingress and egress PE: K-to-L in figure below). 
In this case the connections through the first and last fabrics ((a) in 
MPLS connection functions in figure below) are not monitored.

             Ingress PE
<-------------------------------->
              -----------
               \  MPLS /  on-demand
                \ Test/   MPLS OAM
                 \   /
                  \ /
                   |
    pro-act.       O
    MPLS OAM       |
     |\     -----------   |\
     |M\    |   (b)|  | K | \
     |P \ X |      \  |-O-|  |     MPLS
  -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
     |S /   |  (a)    |-O-|  |             |
     | /    |         |   | /              |
     |/     -----------   |/               |
         MPLS Conn. funct.                 |
                                           |
                                           |
         MPLS Conn. funct.                 |
     |\     -----------   |\               |
     |M\    |         | L | \              |
     |P \ Y |  (a)    |-O-|  |     MPLS    |
  -O-|L  -O-|---------|-O-|  |-O- NETWORK -|
     |S /   |       / |-O-|  |
     | /    |   (b)|  |   | /
     |/     -----------   |/
    pro-act.       |
    MPLS OAM       O
                   |
                  / \
                 /   \
                / MPLS\   on-demand
               /  Test \  MPLS OAM
              -----------
<--------------------------------> 
              Egress PE

Based on the functional model of a pseudowire, the presence of Y.1711 as 
MPLS OAM standard and the default allocation of certains types of [MPLS] 
OAM to [MPLS] trail termination functions, one may conclude that Y.1711 is 
already an existing alternative in the fault management and performance 
monitoring of a MPLS based pseudowire (which is a client layer-network 
link supported by a MPLS trail).

Regards,
Maarten

---------------------------------------------------------------------
Maarten Vissers
Network and Product Strategy - Optical Networks Division
Alcatel SEL AG 
Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
Mobile: +31 65 141 8140
Email:[email-masked]

Stewart Bryant <[email-masked]>
Sent by: [email-masked]
01-12-2003 11:31
Please respond to stbryant

        To:     [email-masked]
        cc:     [email-masked]
        Subject:        Re: [PWE3] FCS retention in PWE3

[email-masked] wrote:

> Stwart,
> 
> In general I agree with you.  But what you are actually saying 
> here is that we want independent OAM in each layer network (simply
> has to be independent....one reason being that we want the *same*
> OAM solution in the server irrespective of its client). 

Independent yes. Same depends on whether there are any differences
in the requirement that suggest otherwise, but I agree same would
be a good thing.

> But please note this:
> -              a PW is not a layer network, ie we do not network/switch 
PW entities;

I am not sure about this. Logically what we are doing is to recurse
back to a lower layer, over which we could run for example a new IGP.
In as much as we network/switch wires, we network/switch PWs.

> -              an LSP is a layer network, ie we do network/switch LSP 
entities;
> -              why can't we use Y.1711 OAM on the top level p2p LSP?

VCCV is the only method that has been formally accepted bt the PWE3
WG for further study. If you think that Y.1711 is more appropriate,
please write a draft explaining how this works in the PWE3 context and
why it is better. The WG will then decide the way forward through
our normal process.

> -              Y.1711 is sparse/simple/complete, ie all defects are 
defined 
         with entry-exit criteria and consequent actions.....it even
         defines availability and does so in order it can be used a
         single-ended way, ie behaviour of both directions can be
         observed from 1 end.

> -              MPLS and ATM OAM layer I/W is already defined in 
Y.1712.....
         and again its really simple.

         I thought that we were talking about Ethernet here?
> 
> None of this is done (and in some cases is not appropriate) for 
> the VCCV approach. 

I which case the VCCV team need to either provide these or explain
why they are not needed.

> 
> So what is wrong with this solution?

There is no WG draft describing the applicability of Y.1711 to PWE3.
If you want that solution, then you have to run the normal IETF
process to get it adopted, which will involve writing a draft,
getting it accepted by the WG, and going through a point by point
analysis of the advantages and disadvantages of Y.1711 and VCCV.

Regards

Stewart

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

---

From: [email-masked]
Date: Thu, 11 Dec 2003 14:39:34 -0000

Thanks Maarten....that seems pretty-well spot-on.  And yes, your diagrams clearly show that the PW is an adaptation function that lies above the MPLS layer network.  So VCCV and Y.1711 are not operating in the same space and thus it is technically incorrect to try and compare them.....that is:
-	VCCV is defining some OAM function that is specific to a PW adaptation function (rather odd architecturally however...also see Note);
-	whilst Y.1711 is generic and operates in the MPLS layer network irrespective of the client.

Note - In the draft draft-ietf-pwe3-satop-00.txt one will also find some specific client/PW case OAM functions....here for a certain type of TDM client, ie the 'L' and 'R' bits.

The key point however, is that MPLS OAM should be generic irrespective of the client, and it should not be a function of the client adaptation function but only of the MPLS trail termination function as Maarten correctly identifies below.

So, if one is to compare Y.1711 to anything it should be to LSP-Ping say.  However, I see these as complimentary functions;  and its clear from what Maarten writes below he shares this view.

regards, Neil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: 11 December 2003 11:45
> To: [email-masked]
> Cc: [email-masked]
> Subject: [PWE3] PW functional model and its OAM [was: FCS retention in
> PWE3]
> 
> 
> Stewart,
>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 11 Dec 2003 10:54:34 -0500

Neil,

You seem to suggest that VCCV is has client-specific elements. I don't see that. Could you explain what in the VCCV draft is client-specific?

Thanks,

Peter

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, December 11, 2003 9:40 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [PWE3] PW functional model and its OAM [was: FCS 
> retention
> in PWE3]
> 
> 
> Thanks Maarten....that seems pretty-well spot-on.  And yes, 
> your diagrams clearly show that the PW is an adaptation 
> function that lies above the MPLS layer network.  So VCCV and 
> Y.1711 are not operating in the same space and thus it is 
> technically incorrect to try and compare them.....that is:
> -	VCCV is defining some OAM function that is specific to 
> a PW adaptation function (rather odd architecturally 
> however...also see Note);
> Note - In the draft draft-ietf-pwe3-satop-00.txt one will 
> also find some specific client/PW case OAM functions....here 
> for a certain type of TDM client, ie the 'L' and 'R' bits.
> 
> The key point however, is that MPLS OAM should be generic 
> irrespective of the client, and it should not be a function 
> of the client adaptation function but only of the MPLS trail 
> termination function as Maarten correctly identifies below.
> 
> So, if one is to compare Y.1711 to anything it should be to 
> LSP-Ping say.  However, I see these as complimentary 
> functions;  and its clear from what Maarten writes below he 
> shares this view.
> 
> regards, Neil
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 11 Dec 2003 11:27:14 -0500

Martin,

	It seems that you are claiming that the
G.805/809 model should be our reference model for
PWE3 as you are pointing out deficiencies in the 
coverage of current OAM tools created by the PWE3 WG.  
I think the larger question we should be asking
is whether or not the IETF PWE3 WG accepts the model from 
G.805/809 to be the model we will use for the PWE3 architecture.  
Since we already have an architecture document that last
time I checked, was pretty complete, I think it is worth hearing 
from the chairs/ADs on this issue to give us some direction 
on how to consider the G.805 model in the context of PWE3.

	--Tom

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of [email-masked]
>Sent: Thursday, December 11, 2003 6:45 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [PWE3] PW functional model and its OAM [was: FCS 
>retention in PWE3]
>
>
>Stewart,
>

---

From: [email-masked]
Date: Thu, 11 Dec 2003 16:54:17 -0000

Busschbach, Peter B (Peter) wrote 11 December 2003 15:55
Peter, please see below:
> 
> Neil,
> 
> You seem to suggest that VCCV is has client-specific 
> elements. I don't see that. Could you explain what in the 
> VCCV draft is client-specific?
> 
> Thanks,
> 
> Peter

NH=> Sorry if I did not explain this well enough.  Let me have another go.  We have some client X and some server Y.  X and Y should have their own OAM that is independent....hopefully that is an obvious requirement.  Note - this observation is pertinent to all layers networks, not just the case here. 

PWs add an adapation function between X and Y.  Some elements of the PW adaptation are client specific.

Now:
-	from the 1st observation above, the OAM of X and Y should be present irrespective of any PW adapation function.....one wants these generic for *all* cases;
-	VCCV puts some additional PW generic OAM in the PW adaptation function....but this is a strange thing to do architecturally if X and Y are properly specified in the 1st place;
-	and some client specific adaptations (I quoted the TDM client case) are adding further client specific OAM, ie the L and R flags I mentioned.

Hopefully that makes what I was saying clear.

There is, of course, more to the complete picture that.  One needs a very clear view of the overall layered relationships to get the defect handling right.....the func arch stuff Maarten was depicting is excellent for understanding this and avoiding mistakes.

Y.1711 was carefully written to be as simple and complete as possible, ie attention was paid from the outset to make sure all defects had automatic defect detection/handling.  I don't see any of this level of detail elsewhere.

Further, it also considers the mapping of defects arising below the MPLS layer into MPLS FDI to *suppress* MPLS layer alarms being raised....and this must recurse up through any nested LSPs up to the client's FDI where this is appropriate (else we get alarm storms all the way up....not a nice thing operationally).  I don't see any of this having been thought about either.

However, I do understand *why* this can't easily be sorted....it basically boils down to:
-	IP and MPLS are not the same network mode....and the fact that they are not is what gives each unique value....so the adapation (and other things like OAM) does not have to be the same.  However, I know this is anti-religious talk so I'll park that one here.
-	MPLS pkts use label swapping and thus have a forwarding behaviour (and defect behaviour) that belongs to the co-ps mode....it does not use full DA/SA identifiers in the pkts as a true cnls mode requires.  This means the topology constructs that should be used with this mode are p2p and p2mp....step outside that and you get problems elsewhere.....fault management being one of them. 

In closing Y.1711 was written by an operator with a strong background in functional arch.....but hey, what do we know about this stuff ;-)

regards, Neil
> > retention in

---

From: [email-masked]
Date: Thu, 11 Dec 2003 17:35:06 -0000

Tom,

It does not matter what folk's opinions are on whether they recognise G.805 and G.809 or not here.....as they are simply a formal language that unambiguously describe networks.  Whether one chooses to use them or not is their business....that does not diminish their intrinsic 'truth'.

We have been using them for years however, and if they did not work or did not have value would not have done so. You obviously don't believe they are useful.  However I, as an operator, do value them because when architectural mistakes and violations occur these ultimately usually mean some cost to us.....using functional modelling means we can identify these issues up-front and not make these mistakes.  They are also invaluable for creating management information models.....also very important for operational/network-management reasons. That may or may-not strike a chord with you.

regards, Neil
BT/GS CTO

> Thomas D. Nadeau
> Sent: 11 December 2003 16:27

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 11 Dec 2003 16:24:15 -0500

> Sent: Thursday, December 11, 2003 11:54 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> NH=> Sorry if I did not explain this well enough.  Let me 
> have another go.  We have some client X and some server Y.  X 
> and Y should have their own OAM that is 
> independent....hopefully that is an obvious requirement.  
> Note - this observation is pertinent to all layers networks, 
> not just the case here. 
> 
> PWs add an adapation function between X and Y.  Some elements 
> of the PW adaptation are client specific.
> 
> Now:
> -	from the 1st observation above, the OAM of X and Y 
> should be present irrespective of any PW adapation 
> function.....one wants these generic for *all* cases;
> -	VCCV puts some additional PW generic OAM in the PW 
> adaptation function....but this is a strange thing to do 
> architecturally if X and Y are properly specified in the 1st place;
> -	and some client specific adaptations (I quoted the TDM 
> client case) are adding further client specific OAM, ie the L 
> and R flags I mentioned.

Neil,

I think your clarification implies that you agree that VCCV is client-layer independent. I agree with you that the SATOP draft seems to violate that separation, but I think that should be raised as an issue against that draft, not against VCCV.

Could you explain why you believe that "VCCV puts some additional PW generic OAM in the PW adaptation function"? The VCCV draft defines how to encapsulate OAM traffic so that it runs over the PW that it is related to. Apart from that, I don't see how VCCV impacts the PW adaptation function.

Peter

> There is, of course, more to the complete picture that.  One 
> needs a very clear view of the overall layered relationships 
> to get the defect handling right.....the func arch stuff 
> Maarten was depicting is excellent for understanding this and 
> avoiding mistakes.
> 
> Y.1711 was carefully written to be as simple and complete as 
> possible, ie attention was paid from the outset to make sure 
> all defects had automatic defect detection/handling.  I don't 
> see any of this level of detail elsewhere.
> 
> Further, it also considers the mapping of defects arising 
> below the MPLS layer into MPLS FDI to *suppress* MPLS layer 
> alarms being raised....and this must recurse up through any 
> nested LSPs up to the client's FDI where this is appropriate 
> (else we get alarm storms all the way up....not a nice thing 
> operationally).  I don't see any of this having been thought 
> about either.
> 
> -	IP and MPLS are not the same network mode....and the 
> fact that they are not is what gives each unique value....so 
> the adapation (and other things like OAM) does not have to be 
> the same.  However, I know this is anti-religious talk so 
> I'll park that one here.
> -	MPLS pkts use label swapping and thus have a forwarding 
> behaviour (and defect behaviour) that belongs to the co-ps 
> mode....it does not use full DA/SA identifiers in the pkts as 
> a true cnls mode requires.  This means the topology 
> constructs that should be used with this mode are p2p and 
> p2mp....step outside that and you get problems 
> elsewhere.....fault management being one of them. 
> 
> In closing Y.1711 was written by an operator with a strong 
> background in functional arch.....but hey, what do we know 
> about this stuff ;-)
> 
> regards, Neil
> >

---

From: [email-masked]
Date: Fri, 12 Dec 2003 00:18:23 -0000

> From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
> Sent: 11 December 2003 21:24
> To: Harrison,N,Neil,IKR2 R; [email-masked];
> [email-masked]
> Cc: [email-masked]
> I think your clarification implies that you agree that VCCV 
> is client-layer independent.
NH=> Well yes, but its also redundant *if* MPLS had properly specified OAM in the 1st place......which is what I started to go into in the later text, inc the correct handling of FDI forwarding/alarm issue.

> I agree with you that the SATOP 
> draft seems to violate that separation,
NH=> I believe I understand why the authors felt they wanted to place L and R indicators in here.....and although not relevent to the specific SATOP draft, if any framing structure is taken into account at the IWF we have a sort-of trail termination proxy of the TDM client here, and so I can make some guesses on how these L/R bits might then be used to detect abberations of such framing structures and take action.  I am not saying I agree with all this, and again this does not excuse having proper MPLS layer OAM.

> but I think that 
> should be raised as an issue against that draft, not against VCCV.
NH=>I can forgive to some extent the aims of the TDMoverMPLS folks given the specific nature of the client in question; but it still does not excuse proper MPLS being required as I noted above.  I am less inclined to forgive the other arch violations as these cause us grief in the network management of them and don't provide any sensible foundation for the future (assuming one believes, as many do, that MPLS could provide a core convergence technology for operators).  Some of my colleagues are doing functional modelling (of the type Maarten showed) of all the facets of the 3 networking modes (of cnls, co-ps and co-cs) and their 9 possible client/server relationships.  MPLS is coming in for some detailed scutiny......merging and PHP don't look good under analysis, but I expect most engineers know this intuitively anyway.
> 
> Could you explain why you believe that "VCCV puts some 
> additional PW generic OAM in the PW adaptation function"? The 
> VCCV draft defines how to encapsulate OAM traffic so that it 
> runs over the PW that it is related to. Apart from that, I 
> don't see how VCCV impacts the PW adaptation function.
NH=> I agree it does not run directly in some of the PW fields, but that this indicates a further level of stuff before we get to whatever the OAM protocol of choice is as an IP-based application, ie.  we have LSP->LSP(to demerge)-> PW CW (carrying mostly redundant stuff, no SN aberration defect defined, ECMP hack avoidance)-> PID -> Client or IP based OAM....some of which is optional, so there are further spins on this.  And then we have LSP-Ping....very complex IMO.  Can you honestly come to me/BT and tell us this lot is representative of good network design?....and where are all the defects defined in terms of automatic detection/handling and the *right* consequenct actions?  Things should be a lot simpler/cleaner than that IMO.

regards, Neil
BT/GS CTO

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 11 Dec 2003 21:15:19 -0500

Neil,

You have stated many times that MPLS would have been a better protocol if it didn't have PHP, MTP and ECMP. Suppose that such a form of MPLS existed. Then it would have been straightforward to define encapsulation of client protocols into this form of MPLS. Without PHP, only one label would be required. Without ECMP, it would be easy to guarantee that OAM traffic would fate-share with the client signal. With such a solution, a PW would be equivalent to an LSP; Maarten's functional model would apply; and everything would be fine and dandy.

However, with such a solution, one ends up with a vary large number of LSPs between to PEs. I suspect that fairly soon Service Providers would decide that it would make sense to set up one LSP between two PEs and tunnel all PW-LSPs through that Tunnel LSP. That would require two layers of OAM. There would be a need for OAM of the Tunnel LSP as well as OAM for every PW-LSP running through it.

In your emails, you have made clear that you believe that PW is broken because it should only be an adaptation function and instead (because of PHP, MTP and ECMP) it almost seems a layer in and of itself.

In seems to me that the situation is actually not that much worse than what I described above for the "ideal" two-layer case. Personally, I don't have a problem with seeing the PW as layer on top of an MPLS or IP infrastructure and I don't see a problem with defining VCCV as the OAM mechanism within that layer. Philosophically, it might not be pure, but pragmatically, it seems equivalent to purer solutions.

I believe that with VCCV, and especially with the adition of BFD, we are on the right way to meet Service Provider needs. The current drafts are not perfect and need additional work. In earlier emails you mentioned the need to define how Sequence Number errors are translated to failure conditions. That is a valid criticism and I agree that it should be addressed. On the other hand, blanket statements like "VCCV is not client-layer independent" are not very helpful, especially since they are wrong.

I hope that we can work our way through the real problems and come up with a good solution.

Peter

> Sent: Thursday, December 11, 2003 7:18 PM
> NH=> Well yes, but its also redundant *if* MPLS had properly 
> specified OAM in the 1st place......which is what I started 
> to go into in the later text, inc the correct handling of FDI 
> forwarding/alarm issue.
> 
> NH=> I believe I understand why the authors felt they wanted 
> to place L and R indicators in here.....and although not 
> relevent to the specific SATOP draft, if any framing 
> structure is taken into account at the IWF we have a sort-of 
> trail termination proxy of the TDM client here, and so I can 
> make some guesses on how these L/R bits might then be used to 
> detect abberations of such framing structures and take 
> action.  I am not saying I agree with all this, and again 
> this does not excuse having proper MPLS layer OAM.
> 
> > but I think that 
> NH=>I can forgive to some extent the aims of the TDMoverMPLS 
> folks given the specific nature of the client in question; 
> but it still does not excuse proper MPLS being required as I 
> noted above.  I am less inclined to forgive the other arch 
> violations as these cause us grief in the network management 
> of them and don't provide any sensible foundation for the 
> future (assuming one believes, as many do, that MPLS could 
> provide a core convergence technology for operators).  Some 
> of my colleagues are doing functional modelling (of the type 
> Maarten showed) of all the facets of the 3 networking modes 
> (of cnls, co-ps and co-cs) and their 9 possible client/server 
> relationships.  MPLS is coming in for some detailed 
> scutiny......merging and PHP don't look good under analysis, 
> but I expect most engineers know this intuitively anyway.
> > 
> NH=> I agree it does not run directly in some of the PW 
> fields, but that this indicates a further level of stuff 
> before we get to whatever the OAM protocol of choice is as an 
> IP-based application, ie.  we have LSP->LSP(to demerge)-> PW 
> CW (carrying mostly redundant stuff, no SN aberration defect 
> defined, ECMP hack avoidance)-> PID -> Client or IP based 
> OAM....some of which is optional, so there are further spins 
> on this.  And then we have LSP-Ping....very complex IMO.  Can 
> you honestly come to me/BT and tell us this lot is 
> representative of good network design?....and where are all 
> the defects defined in terms of automatic detection/handling 
> and the *right* consequenct actions?  Things should be a lot 
> simpler/cleaner than that IMO.
> 
> regards, Neil
> BT/GS CTO
> > 
> > Peter
> > 
> > 
> > > 
> > > > > > > please write a draft explaining how this works in 
> the PWE3 
> > > > > > context and
> > > > > > connection will [likely] contain: an MPLS/ETH_A 
> (adaptation) 
> > > > > > function that 
> > > > > > endpoint of the MPLS Maintenance Entity (i.e. 
> trail) and has 
> > > > > > associated 
> > > > > > with it MPLS OAM to perform pro-active fault 
> management (e.g. 
> > > > > > using Y.1711

---

From: [email-masked]
Date: Sat, 13 Dec 2003 16:34:11 -0000

Peter,  I apologise up-front that this is a longish response....however there are some key points in here.

<snipped>
> 
> You have stated many times that MPLS would have been a better 
> protocol if it didn't have PHP, MTP and ECMP.
NH=> Let's be clear here please.  I don't care which specific technology is being discussed, as the only thing that is relevant is the architecture allowed for the network mode that the technology concerned belongs to.  There are but three networking modes and they are all L3 'peers' in an OSI sense.....the L1, L2 and L3 classifications some use mean absolutely nothing, only the modal classification is useful.  In a functional architecture sense the co-cs and co-ps modes are increasing constraints on the cnls mode....and the reason we impose these constraints is because they provide (i) major simplification benefits wrt network operation/management, and (ii) a 'connection' is essential for some network services (this also has QoS semantic implications of 'urgency' vs 'importance', especially in private network services.....but that is a story in itself which I do not wish to get into here).

Now, to obtain these benefits you have to stay within the allowed architecture of the mode, and for the co-cs/ps modes this means the only allowed constructs are p2p and mp2p.   If one uses labels on link-connections and breaks the architecture by doing mp2p merging say, you have no choice but to run p2p constructions above these if the client is not cnls.  That is simply a fact. And you can see this in all the PW stuff, ie in a simple client/server relationship one only needs 1 server trail level to form the link-connections of the client.....in the PW stuff there are always 2 server layer LSPs doing this job.  And the role of the inner LSP is to recover any merging on the outer LSP, ie to provide the identity of the source which otherwise would be lost.  The PW adaptation sits above all this.

Now we pay a complexity/opex price for the merging (eg only a madman would tell me LSP-Ping is not complex) and we *still* have to run p2p above it. 

PHP is also an architectural violation which terminates the trail in the wrong place...we have done functional arch modelling of this behaviour that shows the operational consequences and we don't like them.

ECMP is something else that is concerned with traffic routing.  Now, it is interesting to observe that the whole point of using a server layer is to control the routing of the client layer traffic.....some folks call this TE.  If one then ignores the server layer constructions on routing the traffic by deciding the actual routing to use based on the client then you might be able to switch-off the server layer TE function as its doing effectively nothing.  However, ECMP together with the arch violations of mp2p and PHP do increase the fault-management complexity of the server layer.  But why bother with all this anyway?  If all one wants is true any-any connectivity and one is prepared to make trade-offs here wrt 'soft-SLAs' and the simplicity obtained from using the co modes then just use IP.  BTW: ECMP *within* a single layer network is fine.....its when its applied over more than 1 layer network that the problems arise....and this observation would apply to any technology.

Now, we are prepared to live with all this stuff....we have to anyway it's out there.   What we find more galling however, is when folks try and tell us this stuff is 'correct' when we can show it plainly is not.

We also don't like it when folks continually ignore good work like Y.1711 and effectively go about re-inventing it.  Some people say they want operator input here but they only listen to it when it suits them and ignore it when it doesn't.  Given there must always be p2p LSPs above any mp2p LSPs to recover from merging we'd like to see Y.1711 run on these top LSPs and use the more complex tools like LSP-Ping to fault-find on-demand in the mp2p layer when (i) the p2p LSPs show a problem and (ii) any lower layer trails (eg in SDH) show clear.

So please explain to me what is wrong with that approach before going and re-inventing OAM is some layer above MPLS that only applies at end points and not to the actual network.....and I'll explain later why this is not the right solution anyway for the general case.

> Suppose that 
> such a form of MPLS existed. Then it would have been 
> straightforward to define encapsulation of client protocols 
> into this form of MPLS.
NH=> I agree.  And we can easily do it....it only takes the will to want to.

> Without PHP, only one label would be 
> required.
NH=> Not strictly true.  If you constructed what is going on in functional arch terms you would see that 2 labels are required to recover from any mp2p merging in a co-ps mode for a non cnls client.  PHP terminates the server layer trail one hop too short.  And this has its own architectural/operational consequences.  But I do agree it also causes a merge behaviour on the last hop.  Again our functional modelling of this clearly shows this and its consequences.

> Without ECMP, it would be easy to guarantee that 
> OAM traffic would fate-share with the client signal. With 
> such a solution, a PW would be equivalent to an LSP; 
> Maarten's functional model would apply; and everything would 
> be fine and dandy.
> 
> However, with such a solution, one ends up with a vary large 
> number of LSPs between to PEs. I suspect that fairly soon 
> Service Providers would decide that it would make sense to 
> set up one LSP between two PEs and tunnel all PW-LSPs through 
> that Tunnel LSP. That would require two layers of OAM. There 
> would be a need for OAM of the Tunnel LSP as well as OAM for 
> every PW-LSP running through it.
NH=> You are now talking about the benefits of using hierarchy...we have been using these techniques for years.  One does not have to violate the architecture of the co modes to gain benefits from hierarchy.  And yes you are right you can now run OAM on each hierarchical level since these are layer networks in their own right......you don't have to, but the ability to do so is important.  Also consider the situation when the client and server LSPs are owned by different administrations.  This is nothing new either.  This can exist in ATM between the VP and VC layers, and in SDH between the STM-N/VC4 and VC12 layers for example.  One has to cater for this situation in the general case....and this is fundamentally what is wrong with the PW/VCCV approach that I will come on to shortly.
> 
> In your emails, you have made clear that you believe that PW 
> is broken because it should only be an adaptation function 
> and instead (because of PHP, MTP and ECMP) it almost seems a 
> layer in and of itself.
NH=> Well PWs are for sure *not* a layer network...we do not 'network' PWs....we could, but then this would place a load of extra requirements on them, ie they would need a full functional component set that defines a layer network.  Compare to GFP or AALs in ATM, ie these are also not layer networks.
> 
> In seems to me that the situation is actually not that much 
> worse than what I described above for the "ideal" two-layer 
> case. Personally, I don't have a problem with seeing the PW 
> as layer on top of an MPLS or IP infrastructure and I don't 
> see a problem with defining VCCV as the OAM mechanism within 
> that layer. Philosophically, it might not be pure, but 
> pragmatically, it seems equivalent to purer solutions.
> 
> I believe that with VCCV, and especially with the adition of 
> BFD, we are on the right way to meet Service Provider needs.
NH=> Do you?   And are you truly considering the general case here?  There are some serious problems with this idea IMO.  If we don't have *networked* OAM within each layer network that is independent and can automatically detect defects (as close to origin as possible, within the scope of the trail termination CI flows) and take appropriate consequent actions, esp FDI generation, we are going to get alarms raised at the wrong locations.  This is not a good idea and I don't think you'll find many operators asking for this behaviour.  You may not have consciously thought about this, but all the stuff I have seen coming from IETF in this area takes for granted the fact that the transport networks, such as SDH/Sonet, are properly specified wrt these OAM functions.  I see various drafts with remarks like 'when a fault is detected.....', but never actually saying *how* this works.....and what they all take for granted is that the transport networks have proper OAM and are going to provide an FDI indication (usually called AIS in co-cs networks).  The main purpose of this function is suppress alarms in higher layer networks.....and it needs to be recursively mapped upwards though nested layers.  Now lets look at some interworking cases wrt to what you are advocating:

Problem 1 - Vertical layer network ownership:

Suppose we have a set of nested trails where each trail is owned by different operators.  It should be very clear that *each* trail requires its own OAM/fault-management.  And that's exactly what you will find in SDH/Sonet for example.  Now consider the case that the nested trails are MPLS LSPs.  It should now also be clear that the OAM *must* be a function of the LSP and not some higher level PW adaptation process right at the top of the stack.  So clearly if we are going to have MPLS used as the target convergence technology (as many operators/vendors show) it must take this kind of international/multi-party networking scenario into account.  This is only possible if the OAM is associated with the entity that is *networked* (ie the LSP) and not some entity that sits above the top-level adaptation function.

Problem 2 - Horizontal layer partitioning:

Suppose we have a trail that is owned by some party X that is carried on leased lower layer transport trails within the domains of operators A, B and C.  Now the operators A, B and C can monitor their server layers *iff* these have their own OAM, eg if SDH VC4s say.  But suppose that X wants an MPLS layer LSP carried and suppose the operators wants to also provide the lower layer transport service using MPLS.  One of the beauties of MPLS is that is has no fixed hierarchy, ie it is a true 'digital wrapper' technology.  This means each operator can construct a lower layer LSP across their domain and monitor this.  This technique is not possible in fixed hierarchy networks, eg ATM....and one has to construct (so-called) 'tandem connection monitoring' segments for such a case....and these have architectural limitations in stacking due to the fixed hierarchy.  So once again, we clearly see that the OAM required *must* be a function of the network LSP entity and not some entity that sits above the top-level adaptation function.

I trust you can agree with these observations.......which are, IMO, quite general requirements of any technology and something that operators would want to see addressed.  Y.1711 takes the above cases into account, ie it works at the LSP level. 

> The current drafts are not perfect and need additional work. 
> In earlier emails you mentioned the need to define how 
> Sequence Number errors are translated to failure conditions. 
> That is a valid criticism and I agree that it should be 
> addressed.
NH=> The issue here is this:  OAM should be generic and agnostic of the application above some given server layer, and from the above the OAM *must* be an intrinsic function of the networked entity.....so we must have the same solutions in all cases.  Sequence numbers on the other hand are client-application specific and not a general requirement of the network.  So in the TDM client-application case I can see a role for Seq Numbers.....but as I stated these should be a function of the adaptation of *that* client-application not the general case.  As you also noted, in an earlier mail, that the algorithm is currently flawed anyway;  but in any case the required 're-ordering' behaviour is client-application specific.....this should *not* be a concern of a server layer network as it should not know or care about specific client applications.  These should be designed (via a suitable adaptation say) to cater for specific client needs.  Now, if Seq No.s are left in there for the general case (which I still maintain is wrong) you cannot simply leave them open-ended wrt defect behaviour.  At some point of Seq No corruption a defect will need to be declared and consequent actions taken.  So if these stay when are we going to see this addressed?

>  On the other hand, blanket statements like "VCCV 
> is not client-layer independent" are not very helpful, 
> especially since they are wrong.
NH=> Well, I hope you understood my earlier arguments than the OAM *must* be a function of the networked entity and why this important.
> come up with a good solution.
NH=> We certainly can but *iff* we:
-	start to acknowledge the stuff that is architecturally not right.....yes we have to live with it and we are fine with that;
-	start to acknowledge we need all 3 networking modes and allow them to work together in a complimentary manner......you can't crunch them all together like the GMPLS peer-model stuff, its simply a commercial non-starter;
-	stop ignoring good work like Y.1711 simply because its been done in ITU and by an operator.

I still remain hopeful for MPLS....but we will see what happens.

regards, Neil

---

From: mark seery <[email-masked]>
Date: Sat, 13 Dec 2003 10:36:36 -0800

Hi Neil, a few comments inline.

Regards,
mark

[email-masked] wrote:

>NH=> Let's be clear here please.  I don't care which specific technology is being discussed, as the only thing that is relevant is the architecture allowed for the network mode that the technology concerned belongs to.  There are but three networking modes and they are all L3 'peers' in an OSI sense.....the L1, L2 and L3 classifications some use mean absolutely nothing, only the modal classification is useful.
>
ms=> I do believe the point you make is not grokked as much as it could 
be, but I also think that in making your point you have emphasized one 
aspect of a more complex issue.

L3 does mean something, specifically within the context of this 
organization. There is a well-honed, well understood concept of an 
Internetwork layer (IP, ICMP, IGMP, etc.) within the IETF. A concept 
which suggests there is one layer that exists rather ignorantly 
(intentionally) of the "network" layers below it. There is great utility 
from this concept which has served this community well. So while I agree 
with your essential intent to illuminate the fact that the OSI model 
does not describe the myriad of server layers that might (depending on 
network design/architecture) exist in a network, there are aspects of 
the OSI model / Internet architecture model that have utility as well.

The model I keep in my own confused head is an amalgomation of the 
Internet layered model and the point you make. It is important to keep 
both in mind because of the historical concern with the Internet 
architecture of end-to-end issues.

><snip>
>
>ECMP is something else that is concerned with traffic routing.  Now, it is interesting to observe that the whole point of using a server layer is to control the routing of the client layer traffic.....some folks call this TE.  If one then ignores the server layer constructions on routing the traffic by deciding the actual routing to use based on the client then you might be able to switch-off the server layer TE function as its doing effectively nothing.
>
ms=> So I think there is an interesting issue here. All IP routing 
essentially ignores the server layer construction. Specifically, in a 
native IP network, ECMP views the server layer as little more than a 
construct for creating successive bandwidth conduits (maybe there are 
other advantages as well) between routers. In this context, the server 
layer really serves the resource allocation/management requirements of 
the bandwidth provider and have little other importance WRT the client 
layer (that the server layer might provide reliability checks, 
protection etc is nice, but not of prominent importance or necessity to 
the client layer).

This is fairly clear I think in an environment where an IP layer is 
running over a circuit layer. It is up to the server layer to define 
itself in a way that is independent of the client layer and meets the 
server layers needs - an issue which the PW WG has no control over.

>  However, ECMP together with the arch violations of mp2p and PHP do increase the fault-management complexity of the server layer.  But why bother with all this anyway?  If all one wants is true any-any connectivity and one is prepared to make trade-offs here wrt 'soft-SLAs' and the simplicity obtained from using the co modes then just use IP.  BTW: ECMP *within* a single layer network is fine.....its when its applied over more than 1 layer network that the problems arise....and this observation would apply to any technology.
>
ms=> I suspect you are making an important point here, but not sure how 
to respond as my own analysis does not conclude definitively whether 
MPLS is a layer in and of itself WRT how it is used and implemented in 
current form, for example it is possible IMO to consider either IP+MPLS 
or MPLS+PW as the full set of semantics necessary to create a layer.

>NH=> Well PWs are for sure *not* a layer network...we do not 'network' PWs....we could, but then this would place a load of extra requirements on them, ie they would need a full functional component…
ms=> So I don't believe this is the complete story. Take for example 
1490 over FR IWF 1483 over ATM. Interworking/translation is required at 
both the server layer and adaptation functions. That we might one day 
take PW+MPLS and interwork it to 1483+ATM is conceivable and doable. 
What makes the PW model a little more interesting is that the adaptation 
function by model occurs on a service provider's service facing 
interface, where commonly in FR/ATM networks it occurs on the customers 
network facing interface, thus moving the point in a system where OAM 
coverage might need to be extended to (which I understand we have argued 
about before).

---

From: [email-masked]
Date: Sun, 14 Dec 2003 10:53:48 +0100

Tom,

Thank you for rasing this question. Find below some further considerations 
and a question:

We may be having a different starting point when we speak about MPLS. For 
me MPLS can be used as a CO-PS technology that is deployed on 
CL-PS/CO-PS/CO-CS multi service switching/provisioning platforms; i.e. 
transport network elements (SDH,OTH) with strong packet support (CL-PS: 
provider bridged Ethernet, CO-PS: e.g. MPLS). This is the direction the 
market is pushing these transport network elements.

I am aware that MPLS has not been developed as a CO-PS technology (a last 
call comment for G.809 stated that MPLS was a CL-PS technology). RFC3031 
states that it focusses on the use of IP as the network layer protocol 
(i.e. client signal), which if I understand it well gives MPLS the CL-PS 
flavour. In the multi service transport network elements it will initially 
be ETH and FR that will be the client signals for the CO-PS layer (e.g. 
MPLS); i.e. not (directly) IP. In the further future I can also see that 
the multi service transport network must support native CO-PS (e.g. MPLS) 
connections (between CO-PS UNIs (e.g. MPLS UNIs)).

Looking at the current set of MPLS specifications most elements for a 
CO-PS usage are present, making it an ideal candidate for use within the 
multi service transport network elements. MPLS would then be transported 
over e.g. (virtual concatenated) SDH VC-n/OTH ODUk signals.

In this transport network environment, G.805/809 models are a basic 
starting point. It would be very helpful if PWE3 would be able to accept 
the G.805 model as an additional (CO-PS) architecture model (in addition 
to the existing CL-PS IP/MPLS based architecture model). 

In this transport network environment with strong connection monitoring 
requirements, PHP would not be required (due to requirement of OAM 
processing at ingress/egress interface ports), MTP would not be required 
(due to connection monitoring and alarm suppression requirements) and ECMP 
would not be required either (feature is provided by VCAT/LCAS). 

As neither of these three (PHP, MTP, ECMP) constructs seem to be mandatory 
(as far as I have understood) in the MPLS architecture in RFC3031, a CO-PS 
MPLS profile seems to be within the boundaries of RFC3031. Is this a 
correct understanding in your opinion?

Regards,
Maarten

"Thomas D. Nadeau" <[email-masked]>
11-12-2003 17:27
Please respond to tnadeau

        To:     Maarten VISSERS/DE/ALCATEL@ALCATEL, <[email-masked]>
        cc:     <[email-masked]>
        Subject:        RE: [PWE3] PW functional model and its OAM [was: FCS retention in PWE3]

                 Martin,

                 --Tom

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 18 Dec 2003 00:16:01 -0500

Neil,

Your email gives me hope that we come to a common understanding. Please see comments in-line.

Peter

> Sent: Saturday, December 13, 2003 11:34 AM
> Peter,  I apologise up-front that this is a longish 
> response....however there are some key points in here.
> 
> <snipped>
> > 
> NH=> Let's be clear here please.  I don't care which specific 
> technology is being discussed, as the only thing that is 
> relevant is the architecture allowed for the network mode 
> that the technology concerned belongs to.  There are but 
> three networking modes and they are all L3 'peers' in an OSI 
> sense.....the L1, L2 and L3 classifications some use mean 
> absolutely nothing, only the modal classification is useful.  
> In a functional architecture sense the co-cs and co-ps modes 
> are increasing constraints on the cnls mode....and the reason 
> we impose these constraints is because they provide (i) major 
> simplification benefits wrt network operation/management, and 
> (ii) a 'connection' is essential for some network services 
> (this also has QoS semantic implications of 'urgency' vs 
> 'importance', especially in private network services.....but 
> that is a story in itself which I do not wish to get into here).
> 
> Now, to obtain these benefits you have to stay within the 
> allowed architecture of the mode, and for the co-cs/ps modes 
> this means the only allowed constructs are p2p and mp2p.   If 
> one uses labels on link-connections and breaks the 
> architecture by doing mp2p merging say, you have no choice 
> but to run p2p constructions above these if the client is not 
> cnls.  That is simply a fact. And you can see this in all the 
> PW stuff, ie in a simple client/server relationship one only 
> needs 1 server trail level to form the link-connections of 
> the client.....in the PW stuff there are always 2 server 
> layer LSPs doing this job.  And the role of the inner LSP is 
> to recover any merging on the outer LSP, ie to provide the 
> identity of the source which otherwise would be lost.  The PW 
> adaptation sits above all this.
> 
> Now we pay a complexity/opex price for the merging (eg only a 
> madman would tell me LSP-Ping is not complex) and we *still* 
> have to run p2p above it. 
> 
> PHP is also an architectural violation which terminates the 
> trail in the wrong place...we have done functional arch 
> modelling of this behaviour that shows the operational 
> consequences and we don't like them.
> 
> ECMP is something else that is concerned with traffic 
> routing.  Now, it is interesting to observe that the whole 
> point of using a server layer is to control the routing of 
> the client layer traffic.....some folks call this TE.  If one 
> then ignores the server layer constructions on routing the 
> traffic by deciding the actual routing to use based on the 
> client then you might be able to switch-off the server layer 
> TE function as its doing effectively nothing.  However, ECMP 
> together with the arch violations of mp2p and PHP do increase 
> the fault-management complexity of the server layer.  But why 
> bother with all this anyway?  If all one wants is true 
> any-any connectivity and one is prepared to make trade-offs 
> here wrt 'soft-SLAs' and the simplicity obtained from using 
> the co modes then just use IP.  BTW: ECMP *within* a single 
> layer network is fine.....its when its applied over more than 
> 1 layer network that the problems arise....and this 
> observation would apply to any technology.
> 
> Now, we are prepared to live with all this stuff....we have 
> to anyway it's out there.   What we find more galling 
> however, is when folks try and tell us this stuff is 
> 'correct' when we can show it plainly is not.

Good! Yes,  the stuff is out there and we need to live with it. If everyone can agree on that, we have a basis for moving forward.

But how about the 'incorrect' design decisions?

I don't think MPLS was designed as a connection-oriented technology. It was designed as a network layer optimized for efficient packet forwarding, emulating characteristics of IP and ATM networks. Given that goal, I think the current MPLS standards meet the objective and in that sense are 'correct'.

But, as you observed before, the fact that MPLS uses labels instead of network-wide unique addresses means by definition that it is a connection-oriented technology. That assertion is debatable. Because of PHP, MPLS is not end-to-end connection-oriented. It wasn't designed to be. So the better question is:

Should MPLS have been designed as a full-blown connection-oriented protocol?

Your observations are right. OAM in a full-blown connection-oriented network is much more straightforward than in MPLS.  However, every engineering effort is a matter of tradeoffs. In this case there is a tradeoff between data plane efficiency and OAM. You clearly value OAM higher than data plane efficiency and given BT's business priorities you may be right. But other people in the past either never considered the tradeoff or they came to different conclusions.

I agree with you that different design decisions would have had their advantages, but I don't think it is fruitful to dwell on that. MPLS may not have been optimized for OAM, but the existing infrastructure provides a platform on top of which other structures (like PWs) can be build that do exhibit the characteristics you need for connection-oriented services and related OAM.

> 
> We also don't like it when folks continually ignore good work 
> like Y.1711 and effectively go about re-inventing it.  Some 
> people say they want operator input here but they only listen 
> to it when it suits them and ignore it when it doesn't.  
> Given there must always be p2p LSPs above any mp2p LSPs to 
> recover from merging we'd like to see Y.1711 run on these top 
> LSPs and use the more complex tools like LSP-Ping to 
> fault-find on-demand in the mp2p layer when (i) the p2p LSPs 
> show a problem and (ii) any lower layer trails (eg in SDH) show clear.

Another step forward! We seem agree that MPLS is not defined as a full-blown connection-oriented protocol; that PWs provide one way to emulate connections; and that we therefore need to run OAM over PWs.

I may have a selective memory, but I don't remember having seen a proposal for running Y.1711 on top of Pseudo Wires. In the past, every email or document that proposed Y.1711 came with a series of objections against the use of PHP, MTP and ECMP. I never got the impression that the proponents of Y.1711 felt that it was usuable in the MPLS networks that exist today.

I think there are two problems with Y.1711 as is:

1) It is defined to be encapsulated with the OAM label. If you do that on top of PWs, it is not guaranteed that the OAM stream follows the same path as the data stream due to ECMP. There have been proposals to introduce a PID, but to me it seems much more straightforward to use the Control Word as proposed in the VCCV draft.

2) Y.1711 defines that messages are sent every second. Given the large number of PWs on a PE, that might be a problem. Therefore I think that the interval should be provisionable by the operator, as is suggested in the BFD draft. Also, I like the "jitter" concept that BFD introduces to avoid synchronization of OAM messages.

I think it would be possible to modify Y.1711 to solve these problems, but I haven't seen much desire to work on this. In my view, Y.1711 has always been presented as a take-it-or-leave-it proposition. In fact, reading the rest of your email I am still not certain whether you consider Y.1711 on top of Pseudo Wires as a sufficient solution.

> 
> So please explain to me what is wrong with that approach 
> before going and re-inventing OAM is some layer above MPLS 
> that only applies at end points and not to the actual 
> network.....and I'll explain later why this is not the right 
> solution anyway for the general case.
> > Suppose that 
> NH=> Not strictly true.  If you constructed what is going on 
> in functional arch terms you would see that 2 labels are 
> required to recover from any mp2p merging in a co-ps mode for 
> a non cnls client.  PHP terminates the server layer trail one 
> hop too short.  And this has its own 
> architectural/operational consequences.  But I do agree it 
> also causes a merge behaviour on the last hop.  Again our 
> functional modelling of this clearly shows this and its consequences.
> 
> NH=> You are now talking about the benefits of using 
> hierarchy...we have been using these techniques for years.  
> One does not have to violate the architecture of the co modes 
> to gain benefits from hierarchy.  And yes you are right you 
> can now run OAM on each hierarchical level since these are 
> layer networks in their own right......you don't have to, but 
> the ability to do so is important.  Also consider the 
> situation when the client and server LSPs are owned by 
> different administrations.  This is nothing new either.  This 
> can exist in ATM between the VP and VC layers, and in SDH 
> between the STM-N/VC4 and VC12 layers for example.  One has 
> to cater for this situation in the general case....and this 
> is fundamentally what is wrong with the PW/VCCV approach that 
> I will come on to shortly.
> > 
> NH=> Well PWs are for sure *not* a layer network...we do not 
> 'network' PWs....we could, but then this would place a load 
> of extra requirements on them, ie they would need a full 
> functional component set that defines a layer network.  
> Compare to GFP or AALs in ATM, ie these are also not layer networks.
> > 
> NH=> Do you?   And are you truly considering the general case 
> here? 

It depends what you mean by "the general case". 

PWs and, as a consequence, VCCV have been defined to run over IP and MPLS networks and, within an MPLS network, do not make any assumptions about the way LSPs between PEs are established. I know you don't agree with that requirement, but within the WG it was accepted as such and within that framework, VCCV provides a general solution.

However, VCCV does not provide a general solution for all connection-oriented services over MPLS networks. The examples of nested and layered LSPs that you give below are obvious cases where PW does not apply. However, in those cases, in all likelyhood, the lower-layer LSPs are setup through RSVP-TE. That has a number of consequences. E.g. the hello and refresh mechanisms that are part of RSVP-TE guarantee detection of the most common network failures. Since this discussion is on the PWE3 mailing list, I don't want to go into more detail, but I am convinced that we have all the tools we need to create sufficiently robust OAM on LSPs that are setup through RSVP-TE. 

I agree with you that we don't have a universal OAM solution that covers all possible cases. After all, MPLS was not designed to enable the simplest possible OAM solution. But we do have solutions for the cases where we need it. 

> There are some serious problems with this idea IMO.  
> If we don't have *networked* OAM within each layer network 
> that is independent and can automatically detect defects (as 
> close to origin as possible, within the scope of the trail 
> termination CI flows) and take appropriate consequent 
> actions, esp FDI generation, we are going to get alarms 
> raised at the wrong locations.  This is not a good idea and I 
> don't think you'll find many operators asking for this 
> behaviour.  You may not have consciously thought about this, 
> but all the stuff I have seen coming from IETF in this area 
> takes for granted the fact that the transport networks, such 
> as SDH/Sonet, are properly specified wrt these OAM functions. 
>  I see various drafts with remarks like 'when a fault is 
> detected.....', but never actually saying *how* this 
> works.....and what they all take for granted is that the 
> transport networks have proper OAM and are going to provide 
> an FDI indication (usually called AIS in co-cs networks).  
> The main purpose of this function is suppress alarms in 
> higher layer networks.....and it needs to be recursively 
> mapped upwards though nested layers.  Now lets look at some 
> interworking cases wrt to what you are advocating:
> 
> Suppose we have a set of nested trails where each trail is 
> owned by different operators.  It should be very clear that 
> *each* trail requires its own OAM/fault-management.  And 
> that's exactly what you will find in SDH/Sonet for example.  
> Now consider the case that the nested trails are MPLS LSPs.  
> It should now also be clear that the OAM *must* be a function 
> of the LSP and not some higher level PW adaptation process 
> right at the top of the stack.

Earlier in your email you wrote that you can live with MPLS as is (as long as people acknowledge that it is not perfect). Well, the consequence is that additional constructs are necessary to enable connection-oriented behavior. Pseudo Wire Emulation is one possible construct. Use of RSVP-TE to set up LSPs is another. 

If you use RSVP-TE, the protocol itself provides mechanisms for failure detection that enable the nested fault detection that you describe. And, yes, you need some additional OAM tools, but this mailing list is not the place to discuss that.

My problem with your reasoning is that you use an example where PWE does not apply to demonstrate that the OAM mechanisms defined for PWs are incorrect.

Yes, if MPLS had been defined as a full-blown connection-oriented protocol, then OAM could have been a function of an LSP and it could have been defined in such a way that it applied universally. But that is not the way it is. 

So my question is: are you willing to accept MPLS as is and live with the consequences, or are you going to continue to compare every solution that is proposed with an imaginary alternative that could have been developed if MPLS had been defined differently?

> So clearly if we are going to 
> have MPLS used as the target convergence technology (as many 
> operators/vendors show) it must take this kind of 
> international/multi-party networking scenario into account.  
> This is only possible if the OAM is associated with the 
> entity that is *networked* (ie the LSP) and not some entity 
> that sits above the top-level adaptation function.

> Suppose we have a trail that is owned by some party X that is 
> carried on leased lower layer transport trails within the 
> domains of operators A, B and C.  Now the operators A, B and 
> C can monitor their server layers *iff* these have their own 
> OAM, eg if SDH VC4s say.  But suppose that X wants an MPLS 
> layer LSP carried and suppose the operators wants to also 
> provide the lower layer transport service using MPLS.  One of 
> the beauties of MPLS is that is has no fixed hierarchy, ie it 
> is a true 'digital wrapper' technology.  This means each 
> operator can construct a lower layer LSP across their domain 
> and monitor this.  This technique is not possible in fixed 
> hierarchy networks, eg ATM....and one has to construct 
> (so-called) 'tandem connection monitoring' segments for such 
> a case....and these have architectural limitations in 
> stacking due to the fixed hierarchy.  So once again, we 
> clearly see that the OAM required *must* be a function of the 
> network LSP entity and not some entity that sits above the 
> top-level adaptation function.
> 
> I trust you can agree with these observations.......which 
> are, IMO, quite general requirements of any technology and 
> something that operators would want to see addressed.  Y.1711 
> takes the above cases into account, ie it works at the LSP level. 
> 
> NH=> The issue here is this:  OAM should be generic and 
> agnostic of the application above some given server layer, 
> and from the above the OAM *must* be an intrinsic function of 
> the networked entity.....so we must have the same solutions 
> in all cases.  Sequence numbers on the other hand are 
> client-application specific and not a general requirement of 
> the network.  So in the TDM client-application case I can see 
> a role for Seq Numbers.....but as I stated these should be a 
> function of the adaptation of *that* client-application not 
> the general case.  As you also noted, in an earlier mail, 
> that the algorithm is currently flawed anyway;  but in any 
> case the required 're-ordering' behaviour is 
> client-application specific.....this should *not* be a 
> concern of a server layer network as it should not know or 
> care about specific client applications.  These should be 
> designed (via a suitable adaptation say) to cater for 
> specific client needs.  Now, if Seq No.s are left in there 
> for the general case (which I still maintain is wrong) you 
> cannot simply leave them open-ended wrt defect behaviour.  At 
> some point of Seq No corruption a defect will need to be 
> declared and consequent actions taken.  So if these stay when 
> are we going to see this addressed?
> 
> NH=> Well, I hope you understood my earlier arguments than 
> the OAM *must* be a function of the networked entity and why 
> this important.
> > 
> -	start to acknowledge the stuff that is architecturally 
> not right.....yes we have to live with it and we are fine with that;

I acknowledge that in the design of MPLS tradeoffs have been made and I can see why BT believes that some of the consequences are not beneficial for the way BT wants to architect their multi-service core network

> -	start to acknowledge we need all 3 networking modes and 
> allow them to work together in a complimentary manner

No, I don't agree with that. If you truly want three networking modes, you either get three independent networks or an integrated network that runs multiple protocols in a ships-in-the-night fashion. That may be beneficial for OAM, but it has disavantages in other respect.

MPLS has been designed to enable connectionless *behavior* and connection-oriented *behavior* in a network optimized for efficient packet forwarding. It does not incorporate a full-blown connectionless mode and a full-blown connection-oriented mode. This is an important distinction.

I think you are turning things upside down. You want robust OAM and you have concluded that support of the three complimentary networking modes is a straightforward way to achieve that goal. However, you don't seem to realize that such an approach might also have certain disadvantages and that there are other ways to achieve robust OAM (maybe not as elegant, but still good enough). Instead, you claim that the support of three complimentary networking modes is an requirement with universal, undeniable validity. With all due respect, that is simply not the case. It is all a matter of tradeoffs.

> ......you can't crunch them all together like the GMPLS 
> peer-model stuff, its simply a commercial non-starter;

As I wrote earlier: I always had the impression that Y.1711 proponents wanted the MPLS network to change so that Y.1711 could be used without modifications. I believe other people had the same impression. Obviously, that didn't help to create much enthousiasm.

---

From: "David Allan" <[email-masked]>
Date: Thu, 18 Dec 2003 14:53:28 -0500

Peter:

Excuse me if I join in on this discussion...

> Good! Yes,  the stuff is out there and we need to live with 
> it. If everyone can agree on that, we have a basis for moving forward.
> 
> I don't think MPLS was designed as a connection-oriented 
> technology. It was designed as a network layer optimized for 
> efficient packet forwarding, emulating characteristics of IP 
> and ATM networks. Given that goal, I think the current MPLS 
> standards meet the objective and in that sense are 'correct'.
> 
> But, as you observed before, the fact that MPLS uses labels 
> instead of network-wide unique addresses means by definition 
> that it is a connection-oriented technology. 

>From a fault management perspective, the artifacts of some classes of MPLS
faults are indistinguishable.

> That assertion 
> is debatable. Because of PHP, MPLS is not end-to-end 
> connection-oriented. 

An LSP has state in each LSR along the path, that would seem to cast a
differing vote. 

Please don't misunderstand me as I debate this topic. I have no religious
convictions as to what MPLS is, I am simply interested in characterizing the
dataplane so I can usefully understand/instrument it. IMHO "control plane
manipulation of a connection oriented dataplane to emulate connectionless
behavior" is the most accurate characterization I've been able to get
comfortable with.

> It wasn't designed to be. So the better 
> question is:
> 

I think the correct statement is "does such a profile exist?" (and I thought
Maarten expressed that well), IMHO it does. There is nowhere that I've seen
it explicitly stated that one MUST use PHP but it has been presented as an
absolute requirement and regardless of it's merits is now presented as THE
way forward. I would be curious to know if everyone wants to change the MAY
in 3031 to a MUST because that is what I seem to be hearing. I can
understand why some vendors might want the change, but I'd be hard pressed
to understand why providers would want such a change.

To date I've operated on the notion that it is a MAY and implementations may
choose NOT to do PHP with no ill effects. Labelling the LSP e2e has value
independent of the forwarding mode used. 

> Your observations are right. OAM in a full-blown 
> connection-oriented network is much more straightforward than 
> in MPLS.  However, every engineering effort is a matter of 
> tradeoffs. In this case there is a tradeoff between data 
> plane efficiency and OAM. You clearly value OAM higher than 
> data plane efficiency and given BT's business priorities you 
> may be right. But other people in the past either never 
> considered the tradeoff or they came to different conclusions.

I agree that there is a specific trade off in efficiency, nothing is free.
We're interested in 1711 despite the limited applicability (which we saw as
simply low hanging fruit) as the general direction was to keep the
functionality in the data plane and not load the control plane, for any type
of proactive OAM that was a desirable feature, and would enhance determinism
of the OAM component and operations in general. This also meant handling
probes at line rate esp. when considering LDP DU where a large
unsynchronized group could be offering bursts of probes at line rate.

> 
> I agree with you that different design decisions would have 
> had their advantages, but I don't think it is fruitful to 
> dwell on that. MPLS may not have been optimized for OAM, but 
> the existing infrastructure provides a platform on top of 
> which other structures (like PWs) can be build that do 
> exhibit the characteristics you need for connection-oriented 
> services and related OAM.

This seems to be based on the idea that MPLS in general does not benefit
from any additional fault management, only PWs. This I can't agree with. The
difference between an MPLS network and an IP network is an extra control
plane, and extra data plane components (which can break) and it provides
additional on-box instrumentation such as packet counts/FEC. Those extras
need to be accounted for.

> Another step forward! We seem agree that MPLS is not defined 
> as a full-blown connection-oriented protocol; that PWs 
> provide one way to emulate connections; and that we therefore 
> need to run OAM over PWs.

Not quite parsing, a requirement for OAM is independent of any requirement
for connections....

> 
> I may have a selective memory, but I don't remember having 
> seen a proposal for running Y.1711 on top of Pseudo Wires. 

You are correct in noting you have selective memory...  ;-)
http://www.ietf.org/internet-drafts/draft-allan-y1711-and-lsp-ping-00.txt
http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt
http://www.ietf.org/internet-drafts/draft-allan-y17iw-overview-00.txt
however to be precise it has never been suggested that the WG adopt 1711
explicitly, simply been kept appraised of the work ;-) BTW Y.17iw is now
Y.1712

> In 
> the past, every email or document that proposed Y.1711 came 
> with a series of objections against the use of PHP, MTP and 
> ECMP. I never got the impression that the proponents of 
> Y.1711 felt that it was usuable in the MPLS networks that exist today.
> 
> 1) It is defined to be encapsulated with the OAM label. If 
> you do that on top of PWs, it is not guaranteed that the OAM 
> stream follows the same path as the data stream due to ECMP. 
> There have been proposals to introduce a PID, but to me it 
> seems much more straightforward to use the Control Word as 
> proposed in the VCCV draft.

You need to separate the functionality from the mechanism to distinguish the
flows. If you draw out the stacks you'd see all proposed mechanisms have
lots of overhead and protocol multiplexing points that could be considered
unnecessary. There is a PID in the IP header a PID in the UDP header, a PID
in the CW. IMHO that is pretty much a wash no matter how you analyze it. 

I suggested to SG13 long ago that we look to obtain either an IP protocol
number or UDP protocol number so that whatever emerged would also apply to
tunnels in general. Unfortunately I did not follow that up with any vigor.

> 
> 2) Y.1711 defines that messages are sent every second. Given 
> the large number of PWs on a PE, that might be a problem. 
> Therefore I think that the interval should be provisionable 
> by the operator, as is suggested in the BFD draft. Also, I 
> like the "jitter" concept that BFD introduces to avoid 
> synchronization of OAM messages.

1711 originates with a specific availability definition, and then defines
the instrumentation to drive the model. That the model does not work under
all modes of MPLS forwarding is understood, no single avalability model
could. Which is why the suite is now getting some other tools.

One problem specific to PWs is that there are clients that have rather
stringent and instrumented availability models (e.g. running ATM I.610 CC).
Simply slowing down the rate of insertion in each PW does not solve this.
Personally I would not want to run one per second over 1000 PWs, I'd rather
run one per second over 1 trunk that carried 1000 PWs and let them inherit
availability state from the trunk so that all clients got what they needed
and probe them uniquely and some very low rate simply for completeness in
coverage, however if I overlay this on ECMP all bets are off as the trunk
probe does not fate share with all the client PWs. The only obvious
conclusion is that not all modes of MPLS forwarding are compatible with all
service requirements....go figure ;-)

Where the jitter capability would help you is if you cannot handle the
messages at line rate therefore pathological and sustained
syncrhonization/clumping is somthing to be ruthlessly avoided. IMO the
requirement to do so is in proportion to message complexity. Our thinking
(some of which is in the old framework draft) was that line rate handling
was an explicit requirement esp. when considering large numbers of unsynched
sources (MP2P ingresses) originating probes. That drove 1711, drives fec-cv
and has other design implications....

> I think it would be possible to modify Y.1711 to solve these 
> problems, but I haven't seen much desire to work on this. In 
> my view, Y.1711 has always been presented as a 
> take-it-or-leave-it proposition. 

Personally I've always seen it as a starting point, not a universal panacea,
and it has been resoundingly criticised as not being a universal panacea.
BTW you have at least one colleague working changes as we speak. 

Unfortunately the whole debate got way too politicized way too early in the
game. Before it was Y1711 it was an internet draft, then a BOF etc. 

BTW OAM is really a very very big topic whereas most of the time we are
discussing fault management and someday may get to performance management.
Can I suggest a blanket text subsititution (FM/PM for OAM) in the mailing
list ;-)

cheers
Dave

<snipped to end>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 18 Dec 2003 16:44:04 -0500

> From: David Allan [mailto:[email-masked]]
> Sent: Thursday, December 18, 2003 2:53 PM
> To: 'Busschbach, Peter B (Peter)'; [email-masked]';
> [email-masked]; [email-masked]
> Cc: [email-masked]
[snipped]

> Simply slowing down the rate of insertion in each PW does not 

Hi Dave,

I have picked one paragraph from your email to illustrate the basic notion that I tried to get across in an earlier email: we will not make any progress on OAM if we make blanket statements. We have to look at specific situations and discuss what works and what doesn't. (BTW: I am not suggesting that your email was full with blanket statements. I just want to further explain my believes)

This is one example: we need to run Y.1711 at a fast rate, because client protocols run at a fast rate.

Why is that? If ATM already runs a connectivity check in every VC and VP at a rate of one CC cell per second, why would you even bother with a connectivity check in the underlying PW or LSP? I understand that it could help with fault isolation, but:

- Service Providers will often use Fault Management systems that are unfazed by a large number of alarms and that take care of alarm correlation and fault isolation.

- The ATM network will start rerouting VCs anyway, whether it is because of AIS and RDI indications, or whether it detected loss of connectivity autonomously.

In fact, given that second point, I think it is much more important that the MPLS core network provides extremely fast protection switching in order to avoid VC restoration (i.e. FRR), than that it supports a Fault Management protocol with a periodic connectivity check.

> and probe them uniquely and some very low rate simply for 
> completeness in coverage,

In my view VCCV provides tools. It is not a mandate to use it.

It is my expectation that PW emulation of ATM will practically always happen over LSPs that are set up with RSVP-TE. In that case, I think it is fairly straightforward to do Fault Management in the transport LSP. There is no need to worry about ECMP, since RSVP-TE nails down a unique path (unless you use hierarchical LSPs, as Curtis V. pointed out on the MPLS mailing list). As mentioned above, you would probably not need a fast Connectivity Verification, but you could rely on RSVP-TE's ability to rapidly react to network failures. To protect against additional failures like mismerging or misbranching you could run LSP_Ping. In addition, you would have to protect against errors in PW labeling so you would have to run VCCV-Ping as well. However, both LSP-Ping and VCCV-Ping could be run at a low frequence. 

In summary, given the specific implementation chosen by the Service Provider, one can select the tools that work best. 

> however if I overlay this on ECMP all bets are off 
> as the trunk

But that is exactly the issue. If the Service Provider decides to setup Transport LSPs with RSVP-TE, ECMP is not an issue and a set of tools is available to do Fault Management.

If on the other hand the Service Provider runs PWs over a core where LSPs are setup autonomously through LSP, ECMP might be an issue. This might cause the Service Provider to decide to run Fault Management protocols over PWs rather than over the underlying LSPs. In that case VCCV specifies the tools.

[snipped to end]

---

From: Peter Willis <[email-masked]>
Date: Fri, 19 Dec 2003 15:01:25 +0000

Colleagues,

First a comment on carrier strategy & requirements then comments on VCCV & 
RSVP-TE detail.

In terms of Fault & Performance Management versus efficient packet forwarding 
the message from BT is very clear. Customer experience is the most important 
thing to us. The customer must never see a fault.  Five 9's reliability & sub 50
msec fast reroute is insignificant if it takes us N hours to locate a fault.
We also aim to reduce Operational costs & we can buy a lot of extra-gates in
ASICs for the recurring costs of experts to locate faults. Carriers won't do
PWE3 or core network convergence to only save capex (that's not where the major
costs lie) but they do it to reduce opex as well. The inability to fault manage 
efficiently increase opex costs and negates the reason to do PWE3 or network
convergence. Seems to me the carrier version of PWE3 starts with "how do
we reduce operational expediture?".

Does VCCV detect swapped or merged LSPs e.g. at the egress 2 LSPs have each 
others' labels or 2 LSPs have merged into 1 label by a fault condition? What's 
the risk of an LSP being sent to the wrong egress and the discriminators still 
being valid?

If we are running graceful restart RSVP to protect our forwarding against 
control plane outages then don't we need to run a data plane liveness test 
(like BFD) to check the forwarding plane is still available whilst the 
control-plane is restarting? 

PeterW.

---

From: "David Allan" <[email-masked]>
Date: Fri, 19 Dec 2003 11:03:30 -0500

Hi Peter:

> I have picked one paragraph from your email to illustrate the 
> basic notion that I tried to get across in an earlier email: 
> we will not make any progress on OAM if we make blanket 
> statements. We have to look at specific situations and 
> discuss what works and what doesn't. (BTW: I am not 
> suggesting that your email was full with blanket statements. 
> I just want to further explain my believes)
> 
> This is one example: we need to run Y.1711 at a fast rate, 
> because client protocols run at a fast rate.
> 
> Why is that? If ATM already runs a connectivity check in 
> every VC and VP at a rate of one CC cell per second, why 
> would you even bother with a connectivity check in the 
> underlying PW or LSP? I understand that it could help with 
> fault isolation, but:
 
As I indicated, my preferred solution is to use hierarchy. If one trunk can
take action and do alarm suppression for its clients you're much better off.
Running CC and probing on a 1:1 VCC-PW basis I would agree is wasteful and
not somthing I would do. If I have a trunk, some client VCCs MAY be running
CC, some may simply depend on getting AIS from the infrastructure.

> - Service Providers will often use Fault Management systems 
> that are unfazed by a large number of alarms and that take 
> care of alarm correlation and fault isolation.

Yes, however IMO that is a lot of churn and stress to propagate upwards.
Plus a reasonable assumption is that the management systems are not
integrated between ATM (for example) and MPLS and the networks MAY be
different operators. Disjoint systems do not correlate faults.
 
> - The ATM network will start rerouting VCs anyway, whether it 
> is because of AIS and RDI indications, or whether it detected 
> loss of connectivity autonomously.

The only way you'll get AIS/RDI from a failure in the PW space is if there
is a detection mechanism that picks off unrecoverable errors and notifies
the egress PE to commence AIS insertion. AIS CAN also act as a hold off
mechanism (please do not adjust your set, someone else has detected the
problem).

> 
> In fact, given that second point, I think it is much more 
> important that the MPLS core network provides extremely fast 
> protection switching in order to avoid VC restoration (i.e. 
> FRR), than that it supports a Fault Management protocol with 
> a periodic connectivity check.

You'll still need resiliency at the ATM layer as the PEs are otherwise
single points of failure that FRR (for example) will not recover from. 

Just to play devils advocate, I could also suggest that by the same logic,
SONET resotration below MPLS would be preferable ;-)

> In my view VCCV provides tools. It is not a mandate to use it.

I'm not getting your point.

> It is my expectation that PW emulation of ATM will 
> practically always happen over LSPs that are set up with 
> RSVP-TE. In that case, I think it is fairly straightforward 
> to do Fault Management in the transport LSP. 

Agreed.

> There is no need 
> to worry about ECMP, since RSVP-TE nails down a unique path 
> (unless you use hierarchical LSPs, as Curtis V. pointed out 
> on the MPLS mailing list). As mentioned above, you would 
> probably not need a fast Connectivity Verification, but you 
> could rely on RSVP-TE's ability to rapidly react to network 
> failures. To protect against additional failures like 
> mismerging or misbranching you could run LSP_Ping. In 
> addition, you would have to protect against errors in PW 
> labeling so you would have to run VCCV-Ping as well. However, 
> both LSP-Ping and VCCV-Ping could be run at a low frequence. 

ideally in one way mode as the egress detecting problems is somewhat more
useful ;-)

> 
> In summary, given the specific implementation chosen by the 
> Service Provider, one can select the tools that work best. 

Sounds like we need to write a BCP document instead of discussing
possiblities....:-)

cheers
Dave

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 19 Dec 2003 12:36:23 -0500

> Behalf Of David Allan
> Sent: Friday, December 19, 2003 11:04 AM

	OTOH, you may wish to periodically verify
imposition/disposition,
which simply checking the transport trunks doesn't achieve.

> different operators. Disjoint systems do not correlate faults.

	In some cases they do not, but in others they do. Be careful
about generalizing. I know providers that have systems in both
areas you describe. There are certainly systems that can handle lots 
of notifications/alarms because of the deployment architecture. 
It is of course, preferred to have fewer alarms, but I have been 
told by some that more are better as long as there are no duplicates
(i.e.: ifDown.1 + ifDown.1).

	--Tom

---

From: "David Allan" <[email-masked]>
Date: Fri, 19 Dec 2003 13:54:25 -0500

Hi Tom:

<snipped>
> imposition/disposition, which simply checking the transport 
> trunks doesn't achieve.

Right, but I think we are all discussing the same thing which is how one
instance can proxy for many, and the "many" only needs a much lower level of
verification actitity to achieve near the same degree of robustness. 
 
<more snipping>

> 	In some cases they do not, but in others they do. Be 
> careful about generalizing. I know providers that have 
> systems in both areas you describe. There are certainly 
> systems that can handle lots 

If we were to look at the most demanding case, it would be different
providers in which case if I were the MPLS provider, I'd want to know about
problems before my ATM customers did, and ideally that my ATM customers knew
I knew (e.g. via AIS) if they also were detecting the problem. If I were to
look at the least demanding case, I would not care which system detected it,
as we are assuming some piece of automation sorted it all out no matter how
it manifested itself. 

IMHO the first scenario would seem to embody the fewest "acts of faith" and
is the best design practice as alarm minimization right off the bat spends
the fewest cycles on both the data plane boxes and the support systems... no
matter who owns them.

cheers
Dave

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 19 Dec 2003 14:59:40 -0500

> Behalf Of Peter Willis
> Sent: Friday, December 19, 2003 10:01 AM
> To: Busschbach, Peter B (Peter)
> Cc: [email-masked]'; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [PWE3] PW functional model and its OAM [was: FCS 
> retention in PWE3] 
> 
> 
> Colleagues,
> 
> the risk of an LSP being sent to the wrong egress and the 
> discriminators still being valid?

	No, not in itself. To reiterate Mr. Busschbach's original
point, the IETF is working on a set of tools that can
be used together to solve a variety of problems in order
to not reinvent the wheel for each application. There are
other tools used to detect mismerging that can be used
in concert with VCCV, ICMP IP ping, VRF-aware ping, etc... 
to form a complete solution.

> control plane outages then don't we need to run a data plane 
> liveness test (like BFD) to check the forwarding plane is still 
> available whilst the control-plane is restarting? 

	I agree that some folks may find this a desirable thing 
to do.

	--Tom

---

From: Peter Willis <[email-masked]>
Date: Tue, 23 Dec 2003 10:58:22 +0000

> There are

Concerned about the remoteness and speed of detection of mismerging with 
these tools. That is if we have a mismerge fault in the core that fault won't 
be detected until much later and at a location where nothing can be done to 
fix the fault. Where as if the mismerge was detected in the core we could fast 
reroute (or whatever) around the fault.

I get even more nervous when graceful restart mechanisms are used because then 
one is assuming that whilst the control plane was crashing it didn't wreck the 
forwarding tables e.g. create a mismerge.

Peter.

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 29 Dec 2003 23:00:49 -0500

> From: Peter Willis [mailto:[email-masked]]

Peter,

Sorry for the late response.

Yes, I believe VCCV protects against swapped or mismerged LSPs. There are two cases:

Wrong PW Label:
When LSP Ping is used over the PW, the original PW-id FEC is included in the message. The receiving PE will check whether the FEC in the Ping message matches the original PW-id FEC. It will reply accordingly. 

Wrong PSN Label:
To detect failures in the underlying transport LSPs, one could run LSP Ping over the PSN LSPs. However, as far as the PWs are concerned, VCCV would also protect against swapped or mismerged PSN LSPs.  It is possible that despite a wrong PSN Label, the PW is still terminated on the correct egress PW. In that case there is no problem. However, if due to an incorrect PSN Label the PW is terminated on a different PE, LSP Ping run over the PW will result in detection of the failure.

Note: LSP Ping over PW will detect swapped or mismerged PSN LSPs. However, it does not enable fault localization. For that, one needs to run an OAM protocol in the PSN layer itself.

Peter

> liveness test