Subject: Re: Comments on draft-mmm-bfd-on-lags-05.txt

From: Marc Binderberger <[email-masked]>
Date: Mon, 27 Aug 2012 19:18:47 +0200

Hello Gregory and Manav,

with "some" delay replying.

Personally I'm fine with replacing "connectivity" with "continuity". Although, we have this part in the draft

   The procedure for the Reception of BFD Control Packets in Section
   6.8.6 of [RFC5880] is amended as follows for per member link micro
   BFD over LAG sessions: "If the Your Discriminator field is non-zero
   and a micro BFD over LAG session is found, the interface on which the
   micro BFD control packet arrived on MUST correspond to the interface
   associated with that session."

Maybe we should be clear here that "otherwise the BFD packet must be dropped"?   Found this obvious but if you think this should be added we can do.

Anyway, it means we do check the "correct" connectivity. Actually we check the connectivity is not suddenly changing while the session is in "Up" state.

> I hear you when you say that using IP encapsulation for monitoring link status could give a few false positives/negatives.

I don't see anything "false" here. You would use BFD with IP encapsulation exactly to test the LAG port - very LAG port - is handling IP traffic well.

If someone wants to stay solely in the Ethernet/layer-2 domain then I would recommend CFM. We do not try to replace CFM with this draft :-)

I understood Gregory that he doesn't want to limit all the draft statements to IP encapsulation as someone may want to use pure G-ACh/GAL encapsulation for a "TP Bundle" or such. And the generic statements of draft-mmm-bfd-on-lags probably can be worded more generically that BFD allows a verification above layer-2 per LAG port.
(What is above 2?  MPLS is often named layer 2.5 :-)

But maybe I misunderstand Gregory?

Regards, Marc

On 2012-07-12, at 12:07 , Bhatia, Manav (Manav) wrote:

> Hi Greg,
>  
> I hear you when you say that using IP encapsulation for monitoring link status could give a few false positives/negatives. However, i am wondering if its a practical concern. Since all micro BFD sessions are single hop, the packets will get dropped if they get rerouted out of some other IP interface, in effect bringing the micro BFD session down. I, on my part, am unable to envisage a scenario when using L3 encap could lead to a false negative/positive. Do you have a scenario or a sequence of events in mind which can demonstrate the fate of a micro session and the real link status diverging?
>  
> Isnt the argument akin to saying that ISIS can introduce false positives since its riding on top of Layer 2?
>  
> Please note that i have no issues in adding the text that you have suggested. I am merely ensuring that we all understand why we're adding the text.
>  
> Cheers, Manav
> From: Gregory Mirsky [mailto:[email-masked]] 
> Sent: Wednesday, July 11, 2012 11:39 PM
> To: Bhatia, Manav (Manav)
> Cc: [email-masked]
> Subject: RE: Comments on draft-mmm-bfd-on-lags-05.txt
> 
> Hi Manav,
> Glad we're converging.
> Certainly the editorial changes you've proposing will address my concern.
> But I frankly don't see need for a separate document just to express my concern regarding use of IP encapsulation. Simple sentense like "Use of IP encapsulation may introduce Layer 3 defects that be positive negatives to monitored LAG." would be sufficient IMHO.
>  
>         Regards,
>                 Greg
>  
> -----Original Message-----
> From: Manav Bhatia [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2012 11:43 PM
> To: Gregory Mirsky
> Cc: [email-masked]
> Subject: Re: Comments on draft-mmm-bfd-on-lags-05.txt
>  
> Hi Gregory,
>  
> > GIM>>>> No, I'm not suggesting not to use IP encapsulation of BFD but
> > I'm suggesting thoroughly document what could be implications of using
> > IP encapsulation of BFD to monitor Layer 2 path.
>  
> Sure this should be done. We can take it up as an additional draft so that we dont stall the progress of this one. This is precisely why we kept the mechanism to dynamically learn the remote IP addresses in a separate draft (draft-mmsn-bfd-on-lags-address-00.txt).
>  
> We can also later explore the possibility of merging these drafts into the main draft, if thats the WG consensus then.
>  
> > I would wager that the entry and exit criteron for micro BFD would be
> > the same as the regular rfc 5881 BFD. Why would this be any different?
> >
> > GIM>>>> As I've noted earlier, many BFD related document use term
> > "connectivity" when in fact discussing "continuity". But these are not
> > the same, not identical. If the draft we're discussing uses
> > "connectivity" in place of"continuity", then a note with explanation
> > should, IMHO, suffice. But if intention is to go beyond RFC 5880 and
> > monitor connectivity, then mis-connection defects have to be defined.
>  
> Would s/connectivity/continuity help? :-)
>  
> Cheers, Manav
>  

--
Marc Binderberger           <[email-masked]>

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 27 Aug 2012 20:06:10 -0400

Hi Marc,
greatly appreciate your consideration of my earlier comments.
Two more to clarify:
*       part of connectivity monitoring or checking are defects that characterize type of mis-connection. Thus, in your example, not only BFD packet will be dropped but a mis-connectivity defect state entered, reported and, possibly, acted upon. An exit from this defect state might be defined as lack of mis-connected micro-BFD packets for 3.5*max(bfd.RequiredMinRxInterval, remote bfd.DesiredMinTxInterval) msec. But discussion of BFD as connectivity monitoring protocol is outside of scope for micro-BFD. Authors might consider to mention the difference between continuity and connectivity monitoring with the latter being outside of scope, left for further study.
*       yes, since BFD is link layer independent protocol, we don't want to limit ouselves to IP/UDP encapsulation over LAG and possibly Composite Links.

        Regards,
                Greg

-----Original Message-----
From: Marc Binderberger [mailto:[email-masked]]
Sent: Monday, August 27, 2012 10:19 AM
To: Gregory Mirsky; Bhatia, Manav (Manav)
Cc: [email-masked]
Subject: Re: Comments on draft-mmm-bfd-on-lags-05.txt

Hello Gregory and Manav,

Regards, Marc

On 2012-07-12, at 12:07 , Bhatia, Manav (Manav) wrote:

> > GIM>>>> No, I'm not suggesting not to use IP encapsulation of BFD
> > GIM>>>> but
> > I'm suggesting thoroughly document what could be implications of
> > using IP encapsulation of BFD to monitor Layer 2 path.
>
> > I would wager that the entry and exit criteron for micro BFD would
> > be the same as the regular rfc 5881 BFD. Why would this be any different?
> >
> > "connectivity" when in fact discussing "continuity". But these are
> > not the same, not identical. If the draft we're discussing uses