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

From: Gregory Mirsky <[email-masked]>
Date: Mon, 9 Jul 2012 19:32:01 -0400

Dear Editors, Authors, et al.
Please find couple of questions from me to the lastest version of micro-BFD draft:
*       Introduction "... (3) and would be able to verify L3 connectivity per member link."
Since BFD is encapsulation independent to monitor path continuity, ability to verify L3 continuity is result of using IP encapsulation. It is possible to use GAL/G-ACh encapsulation, per RFC 5586, Section 4, with GAL being the only MPLS label in the label stack. But introduction of MPLS layer in monitoring LAG's member links might as well introduce defects that are not related to Ethernet layer. That same, IMO, is true for L3.
*       Introduction. "The goal is to verify link connectivity for every member link."
If the goal is to monitor connectivity, then we need to define mis-connectivity defects, entry and exit criterias accordingly.
*       Section 2.3 There seems to be a contradiction in the last para regarding tagging micro BFD control packets. Consider the very first sentence "Micro BFD packets MUST always be sent untagged." And further down "It is RECOMMENDED that micro BFD packets should always be sent untagged." So, is it thou SHOULD tag micro BFD packets?
*       Section 3.1
I think that characterization of BFD in the second para "BFD, as a layer 3 protocol" is not correct. BFD is encapsulation and hence layer independent protocol to monitor path continuity (bi-directional as of now and uni-directional very soon) at layer defined by type of encapsulation used.
*       And one more question. Consider that a micro BFD session went down on one of member links. If LACP is present, then, according to Section 3.1, micro BFD on that link should be put in Passive mode until LACP determines that "a link is suitable for aggregation within its selected LAG and has completed negotiations with the partner device so as to bring that link to Distributing state ...". Is that correct understanding?

        Regards,
                Greg

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 10 Jul 2012 10:12:12 +0530

Hi Greg,

On 7/10/2012 5:02 AM, Gregory Mirsky wrote:
>   * Introduction "… (3) and would be able to verify L3 connectivity per
>     member link."
>
> Since BFD is encapsulation independent to monitor path continuity,
> ability to verify L3 continuity is result of using IP encapsulation. It
> is possible to use GAL/G-ACh encapsulation, per RFC 5586, Section 4,
> with GAL being the only MPLS label in the label stack. But introduction
> of MPLS layer in monitoring LAG's member links might as well introduce
> defects that are not related to Ethernet layer. That same, IMO, is true
> for L3.

I am afraid i dont understand the comment. Are you suggesting that using 
L3 encapsulation can not catch errors in ethernet layer?

> If the goal is to monitor connectivity, then we need to define
> mis-connectivity defects, entry and exit criterias accordingly.

Again, i dont understand this. What do you mean by entry and exit criterias?

>
>   * Section 2.3 There seems to be a contradiction in the last para
>     regarding tagging micro BFD control packets. Consider the very first
>     sentence "Micro BFD packets MUST always be sent untagged." And
>     further down "It is RECOMMENDED that micro BFD packets should always
>     be sent untagged." So, is it thou SHOULD tag micro BFD packets?

Will replace the text to say that Micro BFD packets SHOULD always be 
sent untagged.

>   * Section 3.1
>
> I think that characterization of BFD in the second para "BFD, as a layer
> 3 protocol" is not correct. BFD is encapsulation and hence layer
> independent protocol to monitor path continuity (bi-directional as of
> now and uni-directional very soon) at layer defined by type of
> encapsulation used.

Do you have any replacement text in mind?

>
>   * And one more question. Consider that a micro BFD session went down
>     on one of member links. If LACP is present, then, according to
>     Section 3.1, micro BFD on that link should be put in Passive mode
>     until LACP determines that "a link is suitable for aggregation
>     within its selected LAG and has completed negotiations with the
>     partner device so as to bring that link to Distributing state …". Is
>     that correct understanding?

Yes.

The idea is that the micro BFD sessions will not influence LACP. We will 
let LACP follow its usual state machine. The link will only be used for 
L3 forwarding once the micro BFD sessions are UP. In the presence of 
LACP, the micro sessions only become active once LACP enters the 
Distributing state.

Cheers, Manav

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 10 Jul 2012 16:27:16 -0400

Hi Manav,
Thank you for  expedient response to my questions. Please find my comments in-lined and tagged by GIM>>.

        Regards,
                Greg

-----Original Message-----
From: Manav Bhatia [mailto:[email-masked]]
Sent: Monday, July 09, 2012 9:42 PM
To: Gregory Mirsky
Cc: [email-masked]
Subject: Re: Comments on draft-mmm-bfd-on-lags-05.txt

Hi Greg,

On 7/10/2012 5:02 AM, Gregory Mirsky wrote:
> ability to verify L3 continuity is result of using IP encapsulation.
> It is possible to use GAL/G-ACh encapsulation, per RFC 5586, Section
> 4, with GAL being the only MPLS label in the label stack. But
> introduction of MPLS layer in monitoring LAG's member links might as
> well introduce defects that are not related to Ethernet layer. That
> same, IMO, is true for L3.

GIM>> I don't see point 3, use of IP encapsulation, as benefit but rather as potential source of defects not related to LAG itself.

GIM>> Defect's entry criteria defines what actually constitutes beginning of the state of defect. Defect's exit criteria defines what constitues clearing of particular defect. For example, entry criteria for Loss of Continuity is expiration of a timer associated with far end; exit criteria for Loss of Continuity defect, e.g. as defined in RFC 6428, "occurs upon receipt of a well-formed BFD control packet from the peer MEP".

>     be sent untagged." So, is it thou SHOULD tag micro BFD packets?

Will replace the text to say that Micro BFD packets SHOULD always be sent untagged.

GIM>> Perhaps the following: "BFD, as media independent protocol, ..." or "BFD with IP encapsulation, as layer 3 protocol, ..."

>     partner device so as to bring that link to Distributing state ...". Is

Yes.

The idea is that the micro BFD sessions will not influence LACP. We will let LACP follow its usual state machine. The link will only be used for
L3 forwarding once the micro BFD sessions are UP. In the presence of LACP, the micro sessions only become active once LACP enters the Distributing state.

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 11 Jul 2012 04:27:45 +0530

Hi Greg,

[clipped]

Are you suggesting that we DON'T use IP encapsulation for micro BFD packets? I believe we had discussed the pros and cons of using IP encap vis-a-vis other encaps in the WG and this was the consensus that everyone had eventually arrived at.

[clipped]

	 

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?

[clipped]

Sure, I have no issues with this text. Will update it as long as my co-authors don't raise any objections with this.

Cheers, Manav

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 11 Jul 2012 01:51:23 -0400

Hi Manav,
Just couple more comments in-lined and tagged by GIM>>>> this time.

        Regards,
                Greg

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]]
Sent: Tuesday, July 10, 2012 3:58 PM
To: Gregory Mirsky
Cc: [email-masked]
Subject: RE: Comments on draft-mmm-bfd-on-lags-05.txt

Hi Greg,

[clipped]

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.

[clipped]

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.

[clipped]

Cheers, Manav

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 11 Jul 2012 12:13:18 +0530

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

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 11 Jul 2012 14:08:36 -0400

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,

> 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.

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 12 Jul 2012 15:37:10 +0530

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.

        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,

Cheers, Manav