Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

[Glen Kent <[e-mail]>]

Gregory,

You are using a special GAL label for BFD packets. This label exists only
for the BFD packets.

How can you then claim connectivity for other traffic which will not use
this label?

Glen

On Wed, Apr 13, 2016 at 4:18 AM, Gregory Mirsky <[e-mail]
> wrote:

> Hi Jeff,
>
> thank you for adding more details to the discussions before RFC 7130. We
> have submitted another draft that proposes to use MPLS encapsulation of BFD
> control packets over MC-LAG interfaces. Would greatly appreciate reviews,
> questions and comments on draft-tanmir-rtgwg-bfd-mc-lag-mpls
> <https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-mpls-00>.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Monday, April 11, 2016 10:24 AM
> To: Greg Mirsky
> Cc: Reshad Rahman (rrahman);
> [e-mail]; [e-mail];
> [e-mail]; Alia Atlas ([e-mail]); [e-mail];
> [e-mail]
> Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces
>
>
>
> Greg,
>
>
>
> This is more of a general comment on discussions from the development from
> RFC 7130 than any specific comment on your draft.
>
>
>
> On Fri, Apr 08, 2016 at 11:43:18AM -0700, Greg Mirsky wrote:
>
> > yes, link local multicast may be used in MC-LAG scenario. The draft
>
> > states that it MAY be used while the broadcast has SHOULD normative.
>
> > But we are all open to the discussion.
>
>
>
> During our discussions across multiple vendors, including some hardware
> vendors, it was determined that attempts to exercise the layer 3 mechanisms
> would vary significantly across implementations depending on how packets
> were encapsulated.  Multicast in particular provided some problematic
> issues for us beyond the initial bootstrapping phase of LAG for BFD wherein
> we might not have ARP completed.
>
>
>
> My recommendation is to proceed with your drafts with similar caution.
> Try to stay as true to pure IP as possible to best insure the L3 data paths
> are exercised across implementations from various vendors.
>
>
>
> -- Jeff (speaking as an individual contributor)
>