Subject: RE: [PWE3] BFD for MPLS PWs

From: "Sasha Vainshtein" <[email-masked]>
Date: Tue, 1 Aug 2006 09:20:02 +0200

Rahul and all,
Please see a brief comment inline.

Regards,
               Sasha

> -----Original Message-----
> From: Rahul Aggarwal [mailto:[email-masked]]
> Sent: Monday, July 31, 2006 10:15 PM
> To: Yaakov Stein
> Cc: Sasha Vainshtein; [email-masked]
> Subject: RE: [PWE3] BFD for MPLS PWs
> 
> 
> 
> Hi Yaakov,
> 
> On Mon, 31 Jul 2006, Yaakov Stein wrote:
> 
> > Sasha,
> >
> > > It is my understanding that the BFD-MPLS draft treats PWs 
> just as a
> > pair of uni-directional LSPs
> > > and hence the encapsulation described in Section 7 of 
> this draft fully
> > applies.
> >
> > Yes, I believe so as well. But that is not what Rahul said.
> > If I understood him, he stated that there was specific text 
> in the MPLS
> > BFD
> > draft about PWs that should not be contradicted by the VCCV text.
> >
> 
> See my earlier email the describes how BFD-MPLS spells out the
> encapsulation for BFD for PWs. VCCV must not contradict this. 
> Infact the
> version of VCCV which is currently published, does *not* have any
> contradictions.
> 
> > > This means, IMHO, that, in the case of PWs:
> >
> > > - BFD requests MUST sent over the PW Associated Channel in the
> > appropriate direction of the PW
> > > - BFD replies SHOULD be sent over the PW Associated Channel in the
> > reverse direcion of the PW
> > >   If the receiver is indeed the peer PW end point, and MAY be sent
> > directly over IP if the BFD request
> > >   has been received by another entity.
> >
> > But as I have stated before, this is interpretation on our part.
> >
> 
> The interpretation is correct - see my reply to Sasha.
>
[Sasha] IMHO the VCCV draft should spell it out and not leave such things
open to interpretation (even if you have confirmed the correctnes of mine:-).
> 
> rahul
> 
> > > It would be probably nice to clarify this point in the VCCV draft.
> >
> > Agreed.
> >
> > > It should be also noted that the PW Associated Channel 
> does not always
> > use the first nibble of the CW for discrimination.
> > > The most obvious use case is represented by the PWs that 
> do not use
> > CW, e.g., Ethernet PWs.
> > > (AFAIK, all existing implementations support Ethernet PWs 
> without CW
> > in accordance with RFC 4448 and most do not support CW).
> >
> > A historical mistake that should be rectified by using the 
> CW whenever
> > one wants to use VCCV.
> >
> > > If we agree that IP (and only IP) packets are carried over the
> > Associated Channel,
> > > we can then use IP protocol numbers and, where 
> appropriate, well-known
> > UDP ports for additional discrimination.
> >
> > But I, for one, do not agree.
> >
> > I believe we should expand the possibilities of the PWACH 
> code points
> > instead,
> > and avoid the needless and confusing IP header.
> >
> > > One of the possible applications would be the proposal to 
> carry Y.1731
> > (Ethernet OAM) PDUs over VCCV.
> > > It would looks somewhat bizarre, IMHO, if this proposal were not
> > applicable to Ethernet PWs,
> > > and one way to resolve this controversy could be by encapsulating
> > these PDUs into IP packets
> > > with EtherIP  (RFC 3378) protocol number.
> >
> > Inelegant to say the least.
> >
> > Y(J)S
> >
> >
> 

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

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Tue, 1 Aug 2006 09:12:55 +0200

Yaakov and all,
Please see a brief comment inline. I've snipped the fragments where 
we seem to be in agreement.

Regards,
                     Sasha

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Monday, July 31, 2006 8:33 PM
> To: Sasha Vainshtein
> Cc: [email-masked]; [email-masked]
... snipped ...
> 
> > It should be also noted that the PW Associated Channel does not always
> > The most obvious use case is represented by the PWs that do not use
> > CW, e.g., Ethernet PWs.  
> > (AFAIK, all existing implementations support Ethernet PWs without CW
> A historical mistake that should be rectified by using the CW whenever
> one wants to use VCCV.
>
[Sasha] Mistake or not, this is the fact on the ground. I do not see retrofitting multiple
already deployed services carrying live customer traffic and generating substantial
revenue for the operators as a realistic development. Especially since the OA&M
problem can be amended by other means. (Not to mention the problems with 
revoking/modifying a Standards Track RFC that has only been published 4 months ago 
after 6 years' delay.)
> > we can then use IP protocol numbers and, where appropriate, 
> > well-known
> I believe we should expand the possibilities of the PWACH code points
> instead,
[Sasha]  IMHO the WG should select one of the two approaches for discriminating
various types of payload carried in the ACh:

- Always use IP (so that the type is not needed) and then use IP tools (protocol
  numbers, ports etc.) for dicrimination

OR

- Restrict VCCV to PWs that use a CW and always use the type  field in the CW for
  discrimination.

The advantage of the 1st method its inherent ability to verify PW connectivity as it operates in a 
meaningful way even if the PW label has been popped in a wrong place. I do not see
how this can be achieved with the 2nd method. In addition, it is fully compatible with the existing
and deployed PW implementations.

The advantage of the 2nd method is that it that produces shorter OA&M packets and simplifies,
to some extent, demultiplexing of OA&M packets.
  
> carry Y.1731 (Ethernet OAM) PDUs over VCCV.
[Sasha] I agree. But then the original proposal included quite a few elements that look
inelegant to me:
- meaningless MAC addresses
- MEG IDs (in the CC PDUs) that must be somehow forced to ne the same along a given
  (possibly, multi-segment) PW
- MEP IDs (that must uniquely identify each switching/termination point within the given PW) etc.
Adding/removing a fixed well-defined header on top of all of these looks relatively cheap to me.

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Tue, 1 Aug 2006 14:09:32 -0400

All,
I was also opposed to removing the IP/UDP header. After talks with Tom, we
agreed that a new CV type will be added to provide the option to add the
direct encapsulation (without IP/UDP header).

Mustapha.

> From: Thomas D. Nadeau [mailto:[email-masked]] 
> Sent: Monday, July 31, 2006 4:48 PM
> To: Rahul Aggarwal
> Cc: Yaakov Stein; [email-masked]
> Subject: Re: [PWE3] BFD for MPLS PWs
> 
> 
> > Hi Tom,
> >
> > On Mon, 31 Jul 2006, Thomas D. Nadeau wrote:
> >
> >>
> >> On Jul 31, 2006, at 12:02 PM, Yaakov Stein wrote:
> >>
> >>> Rahul,
> >>>
> >>> At the PWE session you stated that the MPLS BFD draft 
> described the 
> >>> use of BFD for PWs, and that the VCCV draft and the BFD 
> MPLS draft 
> >>> need to remain aligned.
> >>>
> >>> The only mention I find in draft 
> draft-ietf-bfd-mpls-03.txt of PWs 
> >>> is the following motivational text:
> >>>
> >>>    2. MPLS Pseudo Wires (PW). Fast detection may be 
> desired for MPLS
> >>>    PWs depending on i) the model used to layer the MPLS 
> network with 
> >>> the
> >>>    layer 2 network. and ii) the service that the PW is emulating.
> >>> For a
> >>>    non-overlay model between the layer 2 network and the MPLS 
> >>> network
> >>>    the provider may rely on PW fault detection to provide service 
> >>> status
> >>>    to the end-systems. Also in that case interworking 
> scenarios such 
> >>> as
> >>>    ATM/Frame Relay interworking may force periodic PW fault 
> >>> detection
> >>>    messages. Depending on the requirements of the service 
> that the 
> >>> MPLS
> >>>    PW is emulating, fast failure detection may be 
> desirable. Use of 
> >>> BFD
> >>>    for PWs is further described in [VCCV] and [OAM-MAP].
> >>>
> >>> I don't see any normative text here, and certainly nothing 
> >>> describing whether or not UDP is used. What I do see is a 
> pointer to 
> >>> VCCV, so that any changes in VCCV should reflect here.
> >>>
> >>> Section 4 on "theory of operation" seems to be silent on 
> PW issues.
> >>>
> >>> Am I missing something?
> >>
> >> 	It was my assumption that the text in VCCV would stipulate the 
> >> encapsulation (this is the new text that was proposed during and 
> >> modified later based on comments from those who objected after the 
> >> meeting).
> >
> > Can you please send a pointer to this new text ?
> >> VCCV also
> >> stipulates how to use this mode and or makes references where 
> >> necessary.
> >>
> >> 	I do agree with Yaakov in that I think that the text in 
> the BFD/MPLS 
> >> draft referencing PWE3 should be stripped altogether.
> >>
> >
> > BFD-MPLS spells out the generic procedures for various FECs  
> > including the
> > PW FEC. Why should these procedures not apply to the PW FEC ?
> 
> 	The reasons that were explained during the meeting:
> 
> 	1) sending the IP/UDP header is redundant
> 		for SH PWs because the labels or outer l2tpv3 header
> 		ID the VCCV payload.
> 
> 	2) If you include the 127/ dest. address, then it is 
> useless other
> 		than it prevents errant routing if the PW header
> 		is inadvertently stripped.  However, skipping the
> 		IP header altogether obviates both problems. It
> 		also makes each VCCV/BFD packet shorter.
> 
> 	2) sending the IP/UDP header is useless for MH PWs because
> 		the MH PW addressing scheme will not fit into
> 		an IPv4 address.  Instead, the outer PW encapsulation
> 		identifies the destination.
> 
> 	3) the secondary routing header lookup/processing is
> 		a waste of processing cycles since it should
> 		always result in the receiving PE. The outer
> 		header identifies the PW packet already.
> 
> 	Conversations with everyone except yourself (I couldn't
> find you after PWE3) that objected to the removal of the UDP/IP
> header at the meeting, all agreed that this was okay assuming that
> we add two new CV types to explicitly identify when the header
> is and is not included for BFD messages so that we can support
> older implementations. I will have the text for this shortly
> and will send it out.
> 
> 	--Tom
> 
> 
> 
> > rahul
> >
> >> 	--Tom
> >>
> >>
> >>
> >>> Y(J)S
> >>>
> >>>

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Wed, 2 Aug 2006 09:50:11 +0200

Tom and all,
Please see inline below.

Regards,
                 Sasha

> Sent: Tuesday, August 01, 2006 7:51 PM
> To: Sasha Vainshtein
> Cc: pwe3 WG ((((E-mail))))
> On Aug 1, 2006, at 1:07 PM, Sasha Vainshtein wrote:
> 
> > Tom,
> > I've snipped the long discussion to make your summary and 
> my response
> > clearly readable:
> >
> > ... snipped ...
> >>  Lets forget about the LSP ping mode for a second.
> >> For BFD there are currently 2 options:
> >
> >> 1) BFD
> >> or
> >> 2) BFD + status codes.
> >
> >> What is being proposed are 4 options now:
> >>
> >> 1) BFD (with IP headers)
> >> 2) BFD (with IP headers) + status
> >> 3) BFD (without IP headers)
> >> 4) BFD (without IP headers) + status.
> >>
> >> The intent was for options 1/2 to function as-specified 
> today. The  
> >> latter
> >> two are the optimized modes that are useful for those using the
> >> latest MPLS CW.
> >>
> >> 	--Tom
> > [Sasha] This short text clarifies the proposal, it's a pity 
> we ahve  
> > not started from
> > this point.
> >
> > Now my question:
> >
> > Would it be correct to say that, where applicable, the actual OA&M  
> > functionality
> > (i.e. ability to detect and trouble-shoot PW connectivity  
> > problems)  provided by
> > options (3) and (4) is exactly the same as one provided by options  
> > (1) and (2)
> > respectively, while applicability scope of options (1) and (2) is  
> > strictly wider than that of (3) and (4)?
> 
> 	I don't see why this matters. All 4 have their place.
> 
> 	--Tom
> 
[Sasha] With that many options it seems, IMHO, necessary to specify which option(s) constitue the minimum 
REQUIRED for interop. And in order to decide on this, it is useful to understand the functional difference 
between the options and not just the implementation differences (additional look-ups etc.) that have been the 
main point of the discussion so far.

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Mon, 7 Aug 2006 11:37:46 +0200

+Yaakov and all,
I'd say that an *implicit* OAM requirement for "static" (or manually provisioned) PWs is to provide
some equivalent of the functionality that can be achieved for PWs provisioned using the PWE3  setup 
and maintenance propocol (RFC 4448) by some alternative means. For obvious reasons this cannot be
a full equivalent.

IMHO the best way to arrive to explicit specifications woyld be via the PWE3 OAM Message Mapping draft 
(http://www.ietf.org/internet-drafts/draft-ietf-pwe3-oam-msg-map-04.txt). It could be easily augmented
by explicitly specifying which defects, propagation functions and methods are applicable to manually
provisioned PWs.

And, of course, TDM PWs use their own techniques.

Regards,
                     Sasha

> Sent: Monday, August 07, 2006 10:56 AM
> To: Rahul Aggarwal; Thomas D. Nadeau
> Cc: pwe3 WG ((((E-mail)))); Mustapha Aissaoui; Sasha Vainshtein
> Can you please point me to:
>  a) Definition of a static PW ?
> 
> [YJS]  Section 7.1 of RFC 3985 states:
> 
>    Setup or teardown of a PW can be triggered by an operator command,
>    from the management plane of a PE, by signaling set-up or 
> teardown of
>    an AC (e.g., an ATM SVC), or by an auto-discovery mechanism.
>    ...
>    Manual configuration of PWs can be considered a special kind of
>    signaling and is allowed.
> 
> b) Requirements for a static PW ?
> 
> [YJS] Same as requirements for any other PW.
> 
> c) Specifically OAM requirements of a static PW ?
> 
> [YJS] Same as requirements for any other PW.
> 
> d) Definition of a "manually" established PSN ?
> 
> [YJS] see above excerpt from RFC 3985
> 
> e) Requirements for a manually established PSN...
> 
> [YJS] I didn't hear anyone talking about manually establishing a PSN.
> 
> 
>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 16 Aug 2006 16:40:12 -0400

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

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

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 18 Aug 2006 10:09:11 -0400

Tom,

With regards to:

> 	It does make the state machine more complex, but not
> to the point where it cannot work. This is why we have the
> AND/OR processing text that we agreed to.  I am fixing this
> now.

In my opinion, the VCCV draft should not make any statements about the processing of fault notifications. This is addressed in detail in OAM-MAP. Trying to summarize it with a few sentences about AND/OR processing does not add anything and in the worse case might cause confusion and lead to incorrect interpretations.

In fact, the current version of OAM-MAP is quite clear about the procedures. Paragraph 6.1 says that a PE enters the PW forward defect state "if one of the following occurs" and that it exits that state when the previous defect indications have been cleared.

In essence this is the AND/OR procedure that you propose. However, it is more precise since it recognizes that a PE may transition from the forward defect state to the reverse defect state. I don't think you want to get into that level of detail in the VCCV draft and therefore it is better to just refer to OAM-MAP.

Peter

> Sent: Wednesday, August 16, 2006 7:58 AM
> Cc: pwe3 WG ((((((((E-mail)))))))); Swallow George; Pignataro Carlos;
> Morrow Monique; Danny McPherson; Agarwal Rahul; Stewart (stbryant)
> Bryant
> On Aug 15, 2006, at 3:35 PM, Busschbach, Peter B (Peter) wrote:
> 
> >
> > Tom,
> >
> > I have a comment on the following part of your proposed text:
> >
> >>     The defined values for CV Types are:
> >>
> >>         0x00  None.
> >>         0x01  ICMP Ping.
> >>         0x02  LSP Ping.
> >>         0x04  BFD for PW Fault Detection only.
> >>         0x08  BFD for PW Fault Detection and AC/PW Fault
> >>               Status Signaling.
> >>     It should be noted that two different CV Types have 
> been defined
> >>     when BFD is used. In the case of type 0x08, the AC and 
> PW status
> >>     SHOULD be conveyed via BFD status codes as specified in [OAM- 
> >> MAP].
> >>     However, this type SHOULD NOT be used when a control 
> protocl such
> >>     as LDP is available that can signal the AC/PW status to the  
> >> remote
> >>     endpoint of the PW due to complications that can arise from
> >>     synchronization issues between the control protocol's status
> >>     signaling messags and the BFD messages containing fault status
> >>     information.
> >>
> >
> > I don't think it is correct to mandate that 0x08 should not 
> be used  
> > if LDP is used to setup PWs. An operator might prefer to use BFD  
> > for both PW and AC fault notification, even if LDP is being used,  
> > because BFD is transported in the data plane whereas LDP is in the  
> > control plane. Since the control  plane is critical for correct  
> > operation of the network, it makes sense to avoid overloading it  
> > with data-plane-related  failure notifications.
> 
> 	That is true, and is why the text above says "SHOULD NOT"
> instead of "MUST NOT".  If the WG wants me to use lighter language
> I will.
> 
> > Furthermore, I don't understand which "complications" you 
> refer to.  
> > Using BFD for both AC and PW fault status information is more  
> > straightforward than using BFD for some faults and LDP for others.  
> > The only complication that I see is that a developer must read  
> > section 5.3.4 of OAM-MAP. If that text is ambiguous, it should be  
> > updated, but otherwise I don't see what is complicated about it.
> 
> 	It does make the state machine more complex, but not
> to the point where it cannot work. This is why we have the
> AND/OR processing text that we agreed to.  I am fixing this
> now.
> 
> 	--Tom
> 
> 
> >
> > Peter
> >

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 22 Aug 2006 17:50:12 -0400

Andy,

Thanks for your attempt to summarize our positions. I don't fully agree, but it clarifies the discussion.

Please see in-line.

Peter

> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: Tuesday, August 22, 2006 5:16 PM
> To: Luca Martini
> Cc: Busschbach, Peter B (Peter); Swallow George; 'Thomas D. Nadeau';
> Pignataro Carlos; Morrow Monique; pwe3 WG 
> ((((((((E-mail)))))))); Danny
> McPherson; Agarwal Rahul; Stewart (stbryant) Bryant
> Without trying to unwind the 20 levels of this email thread, I think 
> a key point is that Peter asserted (assuming I've followed this 
> thread correctly) that there was strong WG consensus for only using 
> BFD Status messages to signal AC and PW faults and that PW status 
> signalling is redundant.

That is not what I was trying to get across.

I wrote that there is strong consensus that the use of PW Status does not imply that PW Status must be used for *every* single AC and PW defect. E.g. in the case of ATM encapsulation, an AC defect will result in AIS insertion. On the other hand, in the case of FR encapsulation, an AC defect will result in a PW Status message. The OAM message mapping draft defines precisely when PW Status should be sent and when not.

I have not made any statements about the WG's view on the use of BFD. There are two options: (1) use BFD for fault detection only and use PW Status for fault notification (within the bounds of the OAM message mapping draft, i.e. recognizing that for specific defects AIS insertion will be used instead of PW Status); (2) use BFD for both fault detection and fault notification.

I am not aware of any WG consensus about a preferred approach. My personal preference is (1), because I believe that for protocols with well-defined OAM (i.e. ATM and Ethernet w/Y.1731), an AC failure will result in AIS insertion at which point BFD fault notification is unnecessary. However, in my opinion it is up to the service provider to decide which approach to use.

My only statement with regards to BFD was: IF (and only if) one decides to use BFD for both fault detection and notification, there is no need for additional PW Status fault notification. This is an obvious consequence of our general approach to OAM and it is stated as such in the OAM message mapping draft.

>  I don't see that consensus - for example, I 
> happen to agree with Luca that there may be cases where only IP will 
> be able to get through, and in those cases, PW status 
> signaling has value.

And what would that value be? If you run BFD and lose MPLS connectivity, both PEs will detect a forward PW defect and will perform the appropriate consequent actions. There is nothing in the PW Status message that adds any useful information over and beyond what the PE already knows.
> 
> I do agree that there has been an evolution of thinking over time in 
> the WG (seeing as we originally started with just withdrawing PW 
> labels in the original Martini draft), and what we probably need at 
> this point is a single clear overview in one place of the OAM and 
> status signaling functionality currently agreed upon in the WG. 

That already exists. See the OAM message mapping draft. This work has been going on for a couple of years. Furthermore, there is a companion document in L2VPN (draft-ietf-l2vpn-vpws-iw-oam-01). And finally, MFA Forum has produced a similar document that has already been approved: MFA Forum 13.0.0. 

> Once 
> we agree we have a clear consensus,  we can then make sure that the 
> specific documents (encapsulations, OAM-MAP, VCCV, etc.) are 
> consistent with that overview and with each other.

Great idea. Read the documents that exist and let us know how they can be approved.

> 
> Cheers,
> Andy
> 
> -----------
> 
> At 8/18/2006 16:14 -0600, Luca Martini 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.
> >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.
> >
> >>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.
> >>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.
> >>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
> >>
> >>
> >>>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
> >>>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
> >>>
> >>>
> >>>>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
> >>>>
> >>>>
> >>>>
> >>>>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
> >>>>>
>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 22 Aug 2006 22:37:13 -0400

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

Luca,

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

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

Agarwal Rahul;

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.

forward IP packets.

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  

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.

correctly there were strong opinions about making the PW 

status messages 

mandatory.

Luca

Peter

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

From: Busschbach, Peter B (Peter) [ mailto:[email-masked] <mailto:[email-masked]> ]

To: 'Luca Martini'

Agarwal Rahul;

Luca,

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

Agarwal Rahul;

          

            

          

Peter, 

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

mandatory.

when LDP is in use.

Luca

            

proposed procedure.

Peter

pwe3 mailing list

[email-masked] <mailto:[email-masked]> 

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

pwe3 mailing list

[email-masked] <mailto:[email-masked]> 

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

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Wed, 23 Aug 2006 10:26:52 +0200

Peter and all,
Please allow me to revert the question you're asking.

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 in this case the ingress PE mush send an appropriate
AC status notification in BFD (in addition to F4/F5 AIS insertion) for every
affected PW that uses VCCV BFD with status notification?

And, if yes, how, in your opinion, should the egress PEs handle these notifications?
E.g., should they force F4/F5 AIS on VP/VC that act as the ACs of the affected PWs?

To make it short, IMHO you've raised a very serious issue that is equally applicable
to ALL PW OAM techniques.

Regards,
                               Sasha
> Sent: Wednesday, August 16, 2006 10:40 PM
> To: 'Luca Martini'
> Cc: Swallow George; 'Thomas D. Nadeau'; Pignataro Carlos; 
> Morrow Monique; pwe3 WG ((((((((E-mail)))))))); Danny

---

From: <[email-masked]>
Date: Wed, 23 Aug 2006 10:17:10 +0100

Peter,

Please see below.

<snipped>

> I wrote that there is strong consensus that the use of PW
> Status does not imply that PW Status must be used for *every* 
> single AC and PW defect. E.g. in the case of ATM 
> encapsulation, an AC defect will result in AIS insertion. On 
> the other hand, in the case of FR encapsulation, an AC defect 
> will result in a PW Status message. The OAM message mapping 
> draft defines precisely when PW Status should be sent and when not.

NH=> It's one thing having to retrospectively cater for the way folks
have done things in the past (ie things we now understand as wrong or at
least non-optimal), but we also ought to also be learning from this and
producing a view of what the correct architecture/behaviour is and thus
attempting to move in that direction over time.  And one thing I am
still not seeing enough recognition of is that there is NOT a single
functional solution (this is more than OAM) that can correctly be
applied to all 3 network modes.  For example, let us take the OAM case
of applying AIS/FDI in the traffic data-plane:

-	AIS/FDI is absolutely the right response to failures in a co-cs
mode layer network.  {I'll spare the details here as to why this is
required, save to observe that it is yet another consequence (from the
unified modelling work) of the way resource partitions are labelled and
how these are forced to be coupled to real resource in this mode.}  The
reason AIS is traditionally coded as a stream of binary all 1s in the
co-cs mode is simply because the TTL logic used in the early PDH layer
networks floated to a +5v logic '1' under failures.

-	AIS/FDI should NEVER be used in a cl-ps mode layer network since
we do not have connections.....and this includes ethernet (I do not
agree with what has been done in Y.1731 in this respect).

-	The value of AIS/FDI is debateable in a co-ps mode layer
network.  One MUST have pukka connections to even consider it (ie single
source, connectivity=1, no internal routing choice once connection
created).

> 
> I have not made any statements about the WG's view on the use
> of BFD. There are two options: (1) use BFD for fault 
> detection only and use PW Status for fault notification 
> (within the bounds of the OAM message mapping draft, i.e. 
> recognizing that for specific defects AIS insertion will be 
> used instead of PW Status); (2) use BFD for both fault 
> detection and fault notification.
> 
> I am not aware of any WG consensus about a preferred
> approach. My personal preference is (1), because I believe 
> that for protocols with well-defined OAM (i.e. ATM and 
> Ethernet w/Y.1731), an AC failure will result in AIS 
> insertion at which point BFD fault notification is 
> unnecessary. However, in my opinion it is up to the service 
> provider to decide which approach to use.
NH=> I wish!  Seems to me its more down to the vendors who either
provide zero OAM (I can clearly remember being told MPLS did not need
OAM many years ago when we ran a BOF on this topic....and look at what
has happened since!) or, almost as bad, bloated and inappropriate
OAM.....Y.1731 is very much of that ilk IMO.  To be fair however, we
operators almost get what we deserve because we don't input sufficiently
(quantity and esp quality) to the stds fora IMO.

OAM needs to be carefully thought about up-front....and here are some
general rules:
-	one OAM solution is NOT appropriate for all 3 network modes
-	client/server relationships should NOT have 'OAM mappings' in
both directions......the only valid/possible mapping is AIS/FDI upwards
on server failure.....but this should NEVER apply to a cl-ps client
-	separate 'always-on' defect detection/handling OAM from
'on-demand' diagnostics and PM OAM
-	former must be as sparse and simple as possible, and must remove
as much human config as possible....why?....because it has to be
super-reliable (this is also one reason why lots of complex/configured
nested TCM levels in Y.1731 is a very bad thing, but there are many more
things wrong with nested TCM levels in a single layer network, esp a
cl-ps one)
-	if a network needs loads of OAM running to keep it working you
are already dead as an operator......further, we can't afford to process
lots of OAM anyway in normal operation (if you come and look at our
well-engineered/designed networks you will find most of the OAM normally
turned off)....ergo why we need to keep 'always-on' OAM very
simple/sparse....but we still need the ability to invoke good diagnostic
tools on a rare 'on-demand' basis
-	having correct/appropriate architectural design for the network
mode considered (ie no arch violations) in the 1st place will mitigate
the need for running unnecessary levels of complex OAM.

regards, Neil

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Wed, 23 Aug 2006 16:49:45 +0200

Peter,
Thank you for a prompt and detailed response.

One brief comment:

If we accept the guiding principle you've mentioned (i.e., that BFD with status notifications
is an alternative of the PW status message from 4447), life would be much easier
if we also decide that, on a given PW, only one (but not both) can be used.

This would define manually provisioned PWs as the native domain of BFD with AC status
notifications, may be with optional expansion to PWs configured using 4447 (and an 
update to 4447 wrt the mandatory status of the PW status notification).

4447-provisioned PWs would be the native domain of the PW status message (expansion is
not possible in this case:-).

And we should also define how these notifications are handled by the egress PE.

Regards,
                        Sasha

> Sent: Wednesday, August 23, 2006 2:24 PM
> To: Sasha Vainshtein
> Cc: Swallow George; Thomas D. Nadeau; Pignataro Carlos; 
> McPherson; Agarwal Rahul; Stewart (stbryant) Bryant; Luca Martini
> Hi Sasha,
> Good question. Even though the VCCV draft allows PEs to 
> choose the option "use BFD for both fault detection and 
> notification", we haven't defined the related procedures yet. 
> The OAM message mapping draft only deals with in-band 
> notifications in the client protocol layer (like ATM AIS) and 
> PW Status.
> 
> In my opinion, if you use BFD for fault notification, the 
> guiding principle should be that you use BFD where the OAM 
> Message Mapping Draft prescribes PW Status. Thus, for a 
> defect on a FR AC, the PE should send a BFD failure 
> notification, but for an ATM AC defect it should insert AIS 
> and not send a BFD failure notification. But again, we 
> haven't specified this yet. Considering the current 
> confusion, we should probably update OAM message mapping to 
> cover this aspect before going to last call.
> 
> Peter
> 
> > From: Sasha Vainshtein [mailto:[email-masked]]
> > Sent: Wednesday, August 23, 2006 4:27 AM
> > Cc: Swallow George; Thomas D. Nadeau; Pignataro Carlos; 
> > Morrow Monique;
> > pwe3 WG ((((((((E-mail)))))))); Danny McPherson; Agarwal 
> > Rahul; Stewart
> > (stbryant) Bryant; Luca Martini

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 23 Aug 2006 10:35:42 -0400

Sasha,

Please see in-line.

Peter

> Sent: Wednesday, August 23, 2006 10:50 AM

That is what the OAM Msg mapping draft already specifies: see section 5.3 sub-bullet iii). However, this is what Luca seems to disagree with.

> not possible in this case:-).

You are saying that BFD for fault noticiation should only be used for manually provisioned PWs and that for 4447-provisioned PWs, PW Status signaling should be used, right?

That brings us back to the start of this discusion. Tom's proposed addition to the VCCV draft stated exactly that. In my 8/15 email, I pointed out that there are valid reasons why an operator might want to establish PWs with LDP, but prefer to use BFD for fault notification. I didn't see, and still don't, why automatic PW establishment should imply that the signaling protocol must be used for fault notification. In my view these are two orthogonal concepts and it should be up to the operator to decide which combination of techniques to use. In that email, I made the comment that RFC 4447 makes a statement that is overly broad and cannot be interpreted literally. Luca disagreed and that has led to a few more emails.

I actually think we should refine the discussion. There are three opinions that have been expressed:

1)  RFC 4447 implies that PW Status, if used, must be used for every single AC and PW failure

2) RFC 4447 implies that PW Status signaling should be used whenever LDP is used for PW establishment. However, whether to use PW Status or in-band client protocol messages like AIS is situation dependent and is defined in the encapsulation drafts and OAM Msg Mapping.

3) RFC 4447 is overly broad and cannot be used to determine when PW Status should be used. Instead, the OAM Msg Mapping draft should be seen is the defining statute.

In my 8/15 email I claimed that 3) is true. Since Luca disagreed, I asked him a question trying to find out if he believes 1) is true. It seems that he does. I am sure that  most people who worked on the OAM drafts (and on similar work in MFA Forum) do not share that view.

The question, however, is whether 2) is true. This is what you seem to say and what Tom assumed in his VCCV text.

Section 5.4. of RFC 4447 specifies that PE can negotiate whether or not to use PW Status signaling. Therefore, one could argue that an operator who wants to use BFD for fault notification has the option to provision PEs so that they use LDP to set up the PW, but don't use PW Status for fault notification. Unfortunately, 5.4.1 implies that the only alternative to PW Status is Label Withdraw. So, ruling out Label Withdraw as a valid OAM mechanism, it seems fair to say that 2) is true.

Again, I think this is too restrictive. In my opinion, there is should be an option to use LDP signaling for PW setup and BFD for fault notification. However, if the WG concensus is that RFC 4447 implies option 2) and that there is no reason to change it, I can live with that. However, I strongly believe that option 1) incorrect. If the WG feels that RCFC 447 implies 1), we should IMO revise the RFC.

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Wed, 23 Aug 2006 19:12:51 +0200

Peter,

I probably did not explain myself clearly enough.
Here is another attempt (you decide whether it helps or not).

What I have been trying to say is that:

1. Using two ways of carrying the same notification on a given PW (and then trying to
   resolve the inevitable inconsistencies) is a bad idea.
   Looks like you and me are in full agreement on that while Tom has a different opinion.

2. Clear-cut separation between the "native OAM indications over PW" (e.g.,
    insertion of F4/F5 AIS into ATM PWs) and PW-specific OAM indications
    (be it PW status message, BFD with status or something else) is required.

    a) The former, where available, should be provided by the appropriate NSP
        directly to the data plane of the PW

    b) The latter is handled by the user plane (?) of the PW both at ingress
        (where indications received probably from the NSP are translated into
        some form of the PW status notification) and at egress (where the NSP
        may be commanded to inject appropriate OAM indication towards the CE)

    c) Ingress handling may run in parallel (i.e. both native OAM and PW indications),
        but only one type of egress handling per PW can be allowed. (E.g., if the egress 
        PE forwards F4/F5 AIS cells received in the ATM PW packets to the adjacent 
        ATM CE, translation of received remote AC failures to F4/F5 AIS must be disabled). 

    d) Nevertheless it is useful to provide an appropriate indication (based on the PW status
        indications) to the operator as a way to localize the fault observed (presumably)
        by the local CE (e.g., remote AC failure vs. network failure)

   Hopefully this can all be clarified in the OAM message mapping draft before the LC.

3. Changes to the already approved and published PWE3 standards should be minimized.
    This is not a technical issue, rather my common sense (for whatever it is worth:-) 

    a) It took us by far too much time to get these standards approved and published
        (I believe that Luca agrees with that)

    b) The situation in the field is complicated because quite a few of the
        early proposals have been implemented and deployed while the
        proposals themselves underwent substantial changes. The situation
        with the flags in the FR PW CW is a good example: we have an approved
        draft in the RFC queue, but most deployed implementations are aligned
        with the original Martini proposal

    c) The next round of changes almost immediately after 4447 has been approved
        can only make this situation worse

   d) As a consequence, I would really prefer to leave the current 4447 wording wrt
       the PW status message "as is". And this means that carrying the AC status
       indications via BFD should be restricted to manually configured PWs - for the standards
       stability reasons. 

Regards,
                 Sasha

> Sent: Wednesday, August 23, 2006 4:36 PM
> To: Sasha Vainshtein
> That is what the OAM Msg mapping draft already specifies: see 
> section 5.3 sub-bullet iii). However, this is what Luca seems 
> to disagree with.
> 
> > 
> You are saying that BFD for fault notification should only be 
> used for manually provisioned PWs and that for 
> 4447-provisioned PWs, PW Status signaling should be used, right?
>
> 
> That brings us back to the start of this discussion. Tom's 
> proposed addition to the VCCV draft stated exactly that. In 
> my 8/15 email, I pointed out that there are valid reasons why 
> an operator might want to establish PWs with LDP, but prefer 
> to use BFD for fault notification. I didn't see, and still 
> don't, why automatic PW establishment should imply that the 
> signaling protocol must be used for fault notification. In my 
> view these are two orthogonal concepts and it should be up to 
> the operator to decide which combination of techniques to 
> use. In that email, I made the comment that RFC 4447 makes a 
> statement that is overly broad and cannot be interpreted 
> literally. Luca disagreed and that has led to a few more emails.
> 
> 2) RFC 4447 implies that PW Status signaling should be used 
> whenever LDP is used for PW establishment. However, whether 
> to use PW Status or in-band client protocol messages like AIS 
> is situation dependent and is defined in the encapsulation 
> drafts and OAM Msg Mapping.
> 
> 3) RFC 4447 is overly broad and cannot be used to determine 
> when PW Status should be used. Instead, the OAM Msg Mapping 
> draft should be seen is the defining statute.
> 
> In my 8/15 email I claimed that 3) is true. Since Luca 
> disagreed, I asked him a question trying to find out if he 
> believes 1) is true. It seems that he does. I am sure that  
> most people who worked on the OAM drafts (and on similar work 
> in MFA Forum) do not share that view.
> 
> The question, however, is whether 2) is true. This is what 
> you seem to say and what Tom assumed in his VCCV text.
> 
> Section 5.4. of RFC 4447 specifies that PE can negotiate 
> whether or not to use PW Status signaling. Therefore, one 
> could argue that an operator who wants to use BFD for fault 
> notification has the option to provision PEs so that they use 
> LDP to set up the PW, but don't use PW Status for fault 
> notification. Unfortunately, 5.4.1 implies that the only 
> alternative to PW Status is Label Withdraw. So, ruling out 
> Label Withdraw as a valid OAM mechanism, it seems fair to say 
> that 2) is true.
> 
> Again, I think this is too restrictive. In my opinion, there 
> is should be an option to use LDP signaling for PW setup and 
> BFD for fault notification. However, if the WG consensus is 
> that RFC 4447 implies option 2) and that there is no reason 
> to change it, I can live with that. However, I strongly 
> believe that option 1) incorrect. If the WG feels that RCFC 
> 447 implies 1), we should IMO revise the RFC.
> 
> 
> 
> 
> 
> 
> >

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 23 Aug 2006 15:17:23 -0400

> d) As a consequence, I would really prefer to leave the 
> current 4447 wording wrt the PW status message "as is". And this means that 
> carrying the AC status indications via BFD should be restricted to manually 
> configured PWs - for the standards stability reasons. 

Sasha,

It is unfortunate that RFC4447 forces us to accept this unnecessary restriction, but I agree with your view.

Peter

> Sent: Wednesday, August 23, 2006 1:13 PM
> Cc: Swallow George; Thomas D. Nadeau; Pignataro Carlos; Luca Martini;

---

From: "Danny Prairie \(dprairie\)" <[email-masked]>
Date: Wed, 30 Aug 2006 09:30:11 -0400

I have to agree with Tom that using RA label is less desirable than the
other means defined in the draft. We need to make every effort possible
to ensure that the VCCV packets travel along the same path as the data
traffic carried in the pseudowire.

Regards,

Danny

<...SNIP...>
> [Sasha] Please not that the Router Alert mode would work for MS-PWs  
> as well as for SS-PWs,
> while setting TTL to 1 would only support SS-PWs (or a single  
> segment of a MS-PW).
> IMHO there is a difference between the logic used by the router to  
> decide that a certain packet must be
> sent to the control plane and the functional preference of  
> different methods to denote a VCCV packet,
> As long as both mechanisms (TTL expiry and Router Alert) are  
> supported, Router Alert seems preferable to me.
	
	I disagree. In all cases, use of the RA mode MAY result
in data plane handling that differs from that of the PW. It is
only intended for use in special circumstances, and its use will
hopefully go away with time. In particular, it is useful in
cases where the CW is not supported by older hardware. But in
these cases, one has to be VERY careful to understand the
load-sharing behavior of a network to ensure that the VCCV
packets take the same path as the PW data.  For this reason,
it is IMHO the LEAST preferred mode.

	--Tom

>>
> ... snipped to the end ...

---

From: "Danny Prairie \(dprairie\)" <[email-masked]>
Date: Thu, 31 Aug 2006 10:03:48 -0400

Hi Luca,

Since the VC label's TTL is set to 1 by the requesting node (in the case
of SSPW), how do the mentioned policies affect this? 

Regards,

Danny

<...SNIP...> 
These methods are problematic, but let's look at these problems:
> o TTL expiry simply cannot work for end-to-end OAM of MS-PWs (unless
you know the number of hops and
>     can guarantee that it is constant). To me this makes it highly
problematic
> o RA may result in VCCV packets not going over the same path as data
packets. This will happen if:
>    - ECMP is employed (this is a real situation) AND
>    - ECMP uses hashing of the label stack (and not of the IP header
below the label stack).
>
> I am not sure if the latter is a real situation in the deployed
networks. If it is, the best solution would be to
> exclude reserved labels from the ECMP hashing (this has been discussed
many times in the MPLS WG).
>
> Hence, IMO, the comparison is between a 100% real and non-solvable
problem (TTL expiry) and a potential
> (possibly non-existing) and fixable problem.
>
> Which would you choose?
>
>
>
>   
The RA mode of course .

I think that the TTL expiry more has very little chance to work, as a 
lot of networks have policies about copying down the TTL value.

I think the RA mode should be preferred over the TTL expiry mode.

Luca