Subject: Re: [PWE3] BFD path not forwarding code point needed ?

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 5 Oct 2008 14:56:24 +0200

Vishwas,
IMO local session diagnostic does not require a standard code point.
You can use it if it exists already, but you can also live without it...

Regards,
        Sasha

> -----Original Message-----
> From: Vishwas Manral [mailto:[email-masked]]
> Sent: Friday, September 26, 2008 9:56 AM
> To: Alexander Vainshtein
> Cc: Luca Martini; PWE3 WG (E-mail); [email-masked]
> Subject: Re: [PWE3] BFD path not forwarding code point needed ?
>
> Hi Sasha,
>
> The diagnostics code is used for the local session diagnostics too and
> not just for inclusion in the diag field of the BFD packet. Is there
> something I am missing here?
>
> Thanks,
> Vishwas
>
> On Thu, Sep 25, 2008 at 7:25 PM, Alexander Vainshtein
> <[email-masked]> wrote:
> > Luca,
> > If I understand you correctly, we're speaking about BFD in VCCV.
> > And if the PW path is not forwarding, BFD in VCCV will not
> be delivered either.
> > So it looks as if the new code point would never be received.
> > Did I miss something?
> >
> > Regards,
> >        Sasha
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Luca Martini
> >> Sent: Friday, September 19, 2008 12:07 AM
> >> To: PWE3 WG (E-mail)
> >> Cc: [email-masked]
> >> Subject: [PWE3] BFD path not forwarding code point needed ?
> >>
> >> Hello!
> >>
> >> When the authors of the OAM MSG map draft , and I where
> reviewing the
> >> BFD/VCCV status code points that should be used when the PW control
> >> plane is not used, I noticed that we are missing a "Path not
> >> forwarding"
> >> code point in BFD. The current code that can be used, are :
> >>
> >>    0 - No diagnostic:
> >>    1 - Control detection time expired
> >>    7 - Administratively Down
> >>    6 -- Concatenated Path Down
> >>    8 -- Reverse Concatenated Path Down
> >>
> >>
> >> Note that code 7 applies to the BFD session , and not to the path.
> >>
> >> I suggest that we ask for a new code to be allocated ( I
> >> would  suggest
> >> 9 )  with a definition of "path down" or something
> similar. the state
> >> for this code would be  3 -- Up .
> >>
> >> This would match the code point of   0x00000001 - Pseudowire Not
> >> Forwarding   in RFC4447.
> >>
> >> Any comments ?
> >>
> >> Thanks.
> >> Luca
> >>
> >>
> >> _______________________________________________
> >> pwe3 mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/pwe3
> >>
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/pwe3
> >
>
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Luca Martini <[email-masked]>
Date: Wed, 15 Oct 2008 16:03:24 -0600

Alexander Vainshtein wrote:
> And if the PW path is not forwarding, BFD in VCCV will not be delivered either.
yes.
In the context of BFD over VCCV , the path means the attachment circuit 
as well. So the bfd session can be up and running just fine , but the 
port ( attachment circuit) is administratively  down.
In this case we want to convey the status without taking the bfd session 
down. The difference between this code and 6 , would be that 6 indicates 
an error , while the new code is simply an administrative shutdown 
condition.

Does this clarify the point ?

Thanks.
Luca

>> When the authors of the OAM MSG map draft , and I where reviewing the
>> 9 )  with a definition of "path down" or something similar. the state

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Oct 2008 08:07:20 +0200

Luca (and all),
Please see inline below.

BTW, the address of the BFD WG mailing list has been incorrect in the original
email and my comments to it, so I've replaced it with the correct one.

Regards,
        Sasha
> From: Luca Martini [mailto:[email-masked]]
> Sent: Thursday, October 16, 2008 12:03 AM
> To: Alexander Vainshtein
> Cc: [email-masked]; PWE3 WG (E-mail)
> In the context of BFD over VCCV , the path means the attachment circuit as well.
>
[Sasha] Does it? The only reference to the term "path" in
draft-ietf-pwe3-vccv-bfd-02 is in Section 3.1. which reads:
<quote>
   When heart-beat indication is necessary for one or more PWs, the
   Bidirectional Forwarding Detection (BFD) [I-D.ietf-bfd-base] provides
   a means of continuous monitoring of the PW data path and, in some
   operational modes, propagation of forward and reverse defect
   indications.
<end quote>
This does not sound to me as if ACs are included. So I'd say that "path down"
(or "path not forwarding") is a misnomer for a code point that indicates
administrative shutdown of an AC (and, presumably, nothing else).
>
> So the bfd session can be up and running just fine , but the
> In this case we want to convey the status without taking the
> bfd session down. The difference between this code and 6 , would be that
> 6 indicates an error , while the new code is simply an administrative shutdown
> condition.
>
[Sasha] draft-ietf-pwe3-vccv-bfd-02 states (Section 3.3.) that:
<quote>
       BFD CV Types used for fault detection and status signaling (i.e.,
       CV Types 0x08 and 0x20) SHOULD NOT be used when a control
       protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available
       that can signal the AC/PW status to the remote endpoint of the
       PW.
<end quote>
And so, IMHO, before we begin discussing a new BFD code point hat indicates
an administratively disabled AC, let's consider what happens if/when:
(1) The PW has been set up using LDP
(2) Support of the PW Status has been successfully negotiated, so that BFD in VCCV
     is used (if at all) only for the PW fault detection
(3) One of its ACs (or its supporting entity) has been administratively disabled.

I've looked up RFC 4446 and 4447, but did not find a clear-cut answer:
- The PW label should not be withdrawn as this is reserved for  the case when
  "the PW is administratively disabled" (RFC 4447, Section 5.4.1)
- No special bits in the PW status have been allocated to indicate that the AC is administratively
  disabled (RFC 4446, Section 3.5).

Last, but not least:

IMHO the BFD-in VCCV diagnostic codes are used by the receiver to generate appropriate
native service OAM messages. The only use cases that comes to  my mind when
handling of an administratively disabled peer AC would be different from that of its failure
is the case of a FR PW (where "DLCI deleted" could be signaled via LMI) and, possibly,
an Ethernet PW that supports E-LMI across the ports supporting its ACs.
Did I miss something here?