Subject: RE: [PWE3] BFD for MPLS PWs

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Sun, 20 Aug 2006 23:13:35 -0400

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:[email-masked]]
> 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.

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

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

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.

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

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

> > 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:[email-masked]]
> >> 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:[email-masked]]
> >>> 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
> >>>> [email-masked]
> >>>> https://www1.ietf.org/mailman/listinfo/pwe3
> >>>>   
> >>>>         
> >> _______________________________________________
> >> pwe3 mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/pwe3
> >>
> >>     
> 

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

---

From: Luca Martini <[email-masked]>
Date: Tue, 22 Aug 2006 16:47:27 -0600

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

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

> 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