RE: [PWE3] BFD for MPLS PWs

["Busschbach, Peter B (Peter)" <[e-mail]>]

Luca,
 
Your entire email suggests that all that OAM stuff isn't really that critical. To some extent I even agree with you. When you run MPLS over SONET or SDH, the probability of a pure MPLS or PW failure is rare and does not warrant a heavy investment in PW OAM. If I were an operator, I don't think that I would run BFD over every PW.
 
However, your comment about ATM not being used as the Internet Protocol is nonsense. The Internet is by design a connectionless network with completely different properties than the services for which ATM was designed. There are many different network architectures and many different services and for some of these OAM implementations are required that do not apply to the Internet.
 
The irony of the situation is that even though you don't see much value in OAM, you are proposing solutions that complicate the implementation of it: you believe that in many cases defects should be reported twice, once via in-band notifications and once via PW Status.
 
My proposal is to define OAM in way that is simple as possible. For each defect there is a well-defined, minimal set of consequent actions. That seems the obvious way to minimize the burden that OAM could potentially imply. One would think that you would resonate with that. Yet, for some reason, and I don't understand why, you are fighting it.
 
I can't prevent you from writing emails to explain what you believe is the best solution, but it is worth considering that several of us have spent a lot of time to define the OAM Message Mapping draft. Therefore, if you believe that there is a fundamentally better solution, I would rather see that you work it out in a document with sufficient detail so that we can compare apples with apples.
 
Peter
 
 

 -----Original Message-----
From: Luca Martini [mailto:[e-mail]]
Sent: Tuesday, August 22, 2006 6:47 PM
To: Busschbach, Peter B (Peter)
Cc: Swallow George; 'Thomas D. Nadeau'; Pignataro Carlos; Morrow Monique; pwe3 WG ((((((((E-mail)))))))); Danny McPherson; Agarwal Rahul; Stewart (stbryant) Bryant
Subject: Re: [PWE3] BFD for MPLS PWs



Busschbach, Peter B (Peter) wrote: 

Luca,



  

I would suggest that you look at the e-mail archive. If I remember 

correctly there were strong opinions about making the PW 

status messages mandatory.

    



I remember that there was a strong consensus to use PW Status instead of Label Withdraw. In that sense PW Status is indeed mandatory. However, I don't remember ever having seen a discussion about the mandatory use of PW Status for *every* single PW and AC defect. It would be helpful if you could identify that email exchange.



Further comments in-line.



Peter



  

-----Original Message-----

From: Luca Martini [ mailto:[e-mail] <mailto:[e-mail]> ]

Sent: Friday, August 18, 2006 6:15 PM

To: Busschbach, Peter B (Peter)

Cc: Swallow George; 'Thomas D. Nadeau'; Pignataro Carlos; Morrow

Monique; pwe3 WG ((((((((E-mail)))))))); Danny McPherson; 

Agarwal Rahul;

Stewart (stbryant) Bryant

Subject: Re: [PWE3] BFD for MPLS PWs





Busschbach, Peter B (Peter) wrote:

    

To move the discussion forward, let me follow up on my own question.



I believe that there is a broad concensus that insertion of 

      

AIS, as mandated by draft-ietf-pwe3-atm-encap-11, implies 

that the PE will NOT send an additional PW Status message to 

report the same defect.

    

  

      

Here I am assuming you mean insertion of an AIS alarm at the 

PE toward 

the local attachment circuit.

    



No. My example was about LOS, which is an AC defect, which according to draft-ietf-pwe3-atm-encap-11 triggers the PE to insert F4 AIS over the PW.



  

We should also send a status message with status "0x00000008 - Local 

PSN-facing PW (ingress) Receive Fault "  fault in this case.

Remember that the MPLS path might have gone down completely because 

somewhere a router was mis-configured , and can now only 

forward IP packets.

This message would be immediate , and much faster then any VCCV path 

fault detection scheme.

    



You seem to be confusing fault detection and fault notification. My example was about AC defects, but let's look at the PW defects that you are addressing.



  

no , I wanted to understand which kind of fault are you refering to: AC or or PSN faults.



If for some reason the MPLS path goes down, you need some mechanism to find out that that is the case. You could do this via BFD or Y.1711, or you could wait until you receive an RSVP error notification. Since, according to your assumption, the control plane stays up, a PE will not 

or more likely receive an OSPF/ISIS route update , or an LDP label withdraw.


detect the failure through an LDP session failure. PW Status only served to inform a PE about a defect detected by its peer. But then the peer 

Detecting LDP session failures is always a last resort. I have experienced this only once in 5 year of running  a real network. THere was always some other event first.


needs a way to detect the defect. Two PEs that don't do anything else than sending each other PW Staus messages will never detect a defect.



  

Defects are communicated by the network. Some people like the circuit based architectures and want every circuit to monitor and communicate defects. 
This was the ATM concept, and clearly it did not work as we are not running ATM as the Internet Protocol.



Is PW Status faster? It depends. Let's assume you use BFD for failure detection. A PE enters the defect state at expiry of the control detection time. In the next control packet it sends to its peer, it indicates that it entered the defect state. Since the two sessions are asynchronous, there may be a time lag between defect detection in PE1 and (BFD) notification to PE2, but that lag is smaller than the timer value. 



Consider two scenarios: in the first case, the operator requires sub-50-ms failure detection and restoration and therefore provisions use of a 10-ms timer. Within 10 ms after failure detection both sides know about the defect. With PW Status, that 

A 10 ms timer is not realistic. Anything below 10 seconds will not scale in a real network. Why would one spend so many resources to protect against possible bugs ? 
Under normal operation you will get a notification from the PSN that something has gone down. 

is hard to achieve, especially since an MPLS failure may bring hundreds of PWs down, each of which would trigger transmission of a PW Status message.

  

Ok, and generating hundreds of ATm AIS alarms is going to be easier ? No. it would take far more resources. If this is your concern , I suggest using the Grouping TLV ( or group ID ), and wind card PW status messages. this mechanism was designed specifically for ATM to improve the down time response.



Alternatively, consider that the operator provisions 10 minute timers. In that case, it might take several minutes before PE1 informs PE2 about the defect and the use of PW Status would result in a much faster failure notification. But in this case, what is the point? If it is acceptable that defect detection might take 30 minutes , it does not seem necessary to inform the peer PE about the defect within a much smaller time interval.



  

I think that it might very well be acceptable that a very rare , bug related , network defect be deteced more slowy. Especially since 99.9999% of the cases this will not happen.


  

RFC 4447 states "The PW status signaling procedures 

      

described in this section MUST be fully implemented." The 

document itself, however, specifies HOW to use PW Status 

signaling but is vague about WHEN to use PW Status signaling. 

The latter is addressed in the encapsulation drafts, such as 

atm-encap, and is fully defined in OAM-MAP 

(draft-ietf-pwe3-oam-msg-map-04).

    

  

      

This is not my interpretation. When we say procedures 

described in this 

section MUST be fully implemented, implies that the protocol 

will send 

and receive status messages when appropriate. The trigger to send the 

status messages is attachment circuit specific, and therefore is  

described in the encapsulation drafts.

    



But the atm-encapsulation draft that I referenced specifies transmission of F4 AIS, not of PW Status. 

  

That is an omission that we can still fix. Matthew had at one point suggested that we remove this entire section.




The notion that RFC 4447 should be interpreted as a mandate 

      

to send a PW Status message for every single defect is an 

incorrect interpretation of the spirit of the standard, does 

not reflect WG concensus and, if implemented, would lead to 

inefficient implementations.

    

  

      

I disagree, and I have seen no indication that the WG interpreted the 

rfc4447 in this fashion.

    



Perhaps you should read OAM-MSG-MAP. It clearly shows that the people who worked on OAM never thought that PW Status would be transmitted for every single PW and AC defect.



  

I realize this , and we need to resolve the problem.

I will summarize what I believe is the best solution in a separate e-mail.

Thanks.
Luca



  

Therefore, I strongly disagree with the point of view that 

      

Tom and Luca have formulated regarding the use of BFD for 

both fault detection and status signaling. When this option 

is used, there is, IMO, no need to send PW Status messages. 

The current text of OAM-MAP is in line with this view.

    

  

      

I would suggest that you look at the e-mail archive. If I remember 

correctly there were strong opinions about making the PW 

status messages 

mandatory.



The current text OAM-MAP needs to be changed.



Luca

 

    

Peter



  

      

-----Original Message-----

From: Busschbach, Peter B (Peter) [ mailto:[e-mail] <mailto:[e-mail]> ]

Sent: Wednesday, August 16, 2006 4:40 PM

To: 'Luca Martini'

Cc: Swallow George; 'Thomas D. Nadeau'; Pignataro Carlos; Morrow

Monique; pwe3 WG ((((((((E-mail)))))))); Danny McPherson; 

Agarwal Rahul;

Stewart (stbryant) Bryant

Subject: RE: [PWE3] BFD for MPLS PWs





Luca,



Section 7.4 of the ATM Encapsulation draft 

(draft-ietf-pwe3-atm-encap-11.txt) mandates that upon LOS the 

ingress PE inserts F4 AIS for every affected VPC. Is it your 

opinion that because of RFC 4447 the ingress PE must send a 

PW Status message in addition to F AIS insertion?



Peter



    

        

-----Original Message-----

From: Luca Martini [ mailto:[e-mail] <mailto:[e-mail]> ]

Sent: Tuesday, August 15, 2006 6:29 PM

To: Busschbach, Peter B (Peter)

Cc: 'Thomas D. Nadeau'; Swallow George; Pignataro Carlos; Morrow

Monique; pwe3 WG ((((((((E-mail)))))))); Danny McPherson; 

Agarwal Rahul;

Stewart (stbryant) Bryant

Subject: Re: [PWE3] BFD for MPLS PWs





Busschbach, Peter B (Peter) wrote:

      

          

In my opinion, the work on VCCV and OAM-MAP provides a 

        

            

further specification of RFC4447 and in fact overrules the 

requirement that LDP Status signaling must be used.

      

          

  

        

            

Peter, 

We agreed a long time ago that the LDP status messaging was 

going to be mandatory , in fact people insisted I make it 

          

mandatory.

    

So I would have to say that the LDP status MUST always be 

used as mandated in RFC 4447, and the BFD status messaging is 

an optional, and , in my opinion, not a very useful option 

when LDP is in use.



Luca





      

          

A minor comment on your email:

I am not sure what you mean by the "de-facto status must 

        

            

always rely on LDP". Either you declare that that the PW is 

down when (1) BFD OR LSP indicate a PW failure, or (2) based 

only on the LDP status. In my mind "de-facto status" implies 

(2), whereas the beginning of your email says that (1) is the 

proposed procedure.

      

          

Peter

 



_______________________________________________

pwe3 mailing list

[e-mail] <mailto:[e-mail]> 

https://www1.ietf.org/mailman/listinfo/pwe3 <https://www1.ietf.org/mailman/listinfo/pwe3> 

  

        

            

_______________________________________________

pwe3 mailing list

[e-mail] <mailto:[e-mail]> 

https://www1.ietf.org/mailman/listinfo/pwe3 <https://www1.ietf.org/mailman/listinfo/pwe3> 



    

        

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