Re: [mpls] Review of draft-mirsky-mpls-bfd-directed-03

[Nobo Akiya <[e-mail]>]

Hi Greg,

Looks good!

Thanks for considering my nitty-gritty comments.

Regards,
Nobo

On Wed, Sep 2, 2015 at 1:18 AM, Gregory Mirsky <[e-mail]>
wrote:

> Hi Nobo,
>
> many thanks for your thoughtful comments and help to improve the document.
>
> Would the following change address your concern:
>
> OLD:
>
> But the reverse
>
>    direction of the BFD session would still follow the shortest path
>
>    route and that might lead to the following problems detecting
>
>    failures on the unidirectional explicit path:
>
>
>
>    o  detection of a failure on the reverse path cannot reliably be
>
>       interpreted as bi-directional defect and thus trigger, for
>
>       example, protection switchover of the forward direction;
>
>
>
>    o  if a failure of the reverse path had been ignored, the ingress
>
>       node would not receive indication of forward direction failure
>
>       from its egress peer.
>
> NEW:
>
> But the reverse
>
>    direction of the BFD session would still follow the shortest path
>
>    route and that might lead to the following problem in detecting
>
>    failures on the unidirectional explicit path:
>
>
>
>    o  a failure detection by ingress node on the reverse path cannot be
>
>       interpreted as bi-directional failure with all the certainty and
>
>       thus trigger, for example, protection switchover of the forward
>
>       direction without possibility of being false positive or false
>
>       negative.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Nobo Akiya [mailto:[e-mail]]
> *Sent:* Saturday, August 15, 2015 8:27 PM
> *To:* Gregory Mirsky
> *Cc:* Mach Chen; mpls; [e-mail];
> Ross Callon
> *Subject:* Re: Review of draft-mirsky-mpls-bfd-directed-03
>
>
>
> Hi March, Greg,
>
>
>
> My apologies for very delayed response.
>
>
>
> Please see in-line with [NOBO].
>
>
>
> Note I've snipped out sections that I accept your response.
>
>
>
>
>
> > Section 2
>
> >
>
> > o if reverse direction is in Down state, the head-end node would not
>
> >    receive indication of forward direction failure from its egress
>
> >    peer.
>
> >
>
> > [NOBO] I found above to be slightly unclear in 2 aspects.
>
> >
>
> > Since this section is describing the limitations of using BFD on an
>
> > unidirectional explicitly routed path, what does "if reverse direction
> is in Down state" mean?
>
> >
>
> > Additionally, "would not receive indication of forward direction
>
> > failure from its egress peer" is a bit cryptic. If the egress peer
>
> > detected that forward direction failed (e.g., BFD session timed out),
>
> > then the egress peer will send few BFD control packets with DOWN
>
> > state, IP routed. Thus the ingress peer will notice the problem of the
> forward direction.
>
> >
>
> > Readers can likely benefit from having this bullet point better
> clarified.
>
> >
>
>
>
> GIM≫ Would the following wording be more deterministic:
>
>    o  failure detection on the reverse path cannot reliably be
>
>       interpreted as bi-directional failure and thus trigger, for
>
>       example, protection switchover of the forward direction;
>
>
>
>    o  if a failure of the reverse path being ignored, the ingress node
>
>       would not receive indication of forward direction failure from its
>
>       egress peer.
>
>
>
>
>
> [NOBO] The second bullet may create more confusion. Can we keep just the
> first bullet and add a bit of clarifications as below?
>
>
>
> * a failure detection on the reverse path cannot reliably be
>
>   interpreted as bi-directional failure and thus trigger, for
>
>   example, protection switchover of the forward direction.
>
>   When the BFD session on the egress node declares a failure
>
>   (i.e., forward direction failure), the failure may or may not
>
>   reach the ingress node. Therefore, the BFD session on the
>
>   ingress node declaring failure may be a result of just the
>
>   reverse path failure or both forward and reverse paths
>
>   failures.
>
>
>
> Regards,
>
> Nobo
>