RE: [PWE3] BFD for MPLS PWs

["Sasha Vainshtein" <[e-mail]>]

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

> -----Original Message-----
> From: Busschbach, Peter B (Peter) [mailto:[e-mail]]
> Sent: Wednesday, August 23, 2006 4:36 PM
> To: Sasha Vainshtein
> Cc: Swallow George; Thomas D. Nadeau; Pignataro Carlos; 
> Morrow Monique; pwe3 WG ((((((((E-mail)))))))); Danny 
> McPherson; Agarwal Rahul; Stewart (stbryant) Bryant; Luca Martini
> Subject: RE: [PWE3] BFD for MPLS PWs
> 
> 
> Sasha,
> 
> Please see in-line.
> 
> Peter
> 
> > -----Original Message-----
> > From: Sasha Vainshtein [mailto:[e-mail]]
> > Sent: Wednesday, August 23, 2006 10:50 AM
> > 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; Luca Martini
> > Subject: RE: [PWE3] BFD for MPLS PWs
> > 
> > 
> > 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.
> 
> 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.
> 
> > 
> > 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:-).
> 
> 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.
> 
> 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 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.
> 
> 
> 
> 
> 
> 
> > 
> > And we should also define how these notifications are handled 
> > by the egress PE.
> > 
> > Regards,
> >                         Sasha
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 

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