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

[Marc Binderberger <[e-mail]>]

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:[e-mail]] 
> Sent: Wednesday, July 11, 2012 11:39 PM
> To: Bhatia, Manav (Manav)
> Cc: [e-mail]
> 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:[e-mail]]
> Sent: Tuesday, July 10, 2012 11:43 PM
> To: Gregory Mirsky
> Cc: [e-mail]
> 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           <[e-mail]>