Subject: IP Address Schemes for BFD on LAG interfaces

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 9 Feb 2012 09:35:38 +0530

Hi,

There were some concerns about operational complexity that using unicast addresses for micro BFD sessions would entail. We have written a short draft that alleviates such concerns by suggesting few mechanisms that nodes can use to auto discover remote neighbor IP addresses before establishing micro BFD sessions.

Would be great if the WG can review and provide feedback on this draft.

The URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.txt 

Cheers, Manav

--

From: [email-masked] 
To: [email-masked] 
Reply-to: [email-masked] 
Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt 
X-C5I-RSN: 1/0/935/41368/44754 
 
A New Internet-Draft is available from the on-line Internet-Drafts directories. 
 
Title : IP Address Schemes for Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces 
Author(s) : Manav Bhatia 
Marc Binderberger 
Sami Boutros 
Nobo Akiya 
Filename : draft-mmsn-bfd-on-lags-address-00.txt 
Pages : 5 
Date : 2012-02-08 
 
This document describes techniques which can be used by a router to 
obtain or discover remote neighbor IP address in order to establish 
micro Bidirectional Forwarding Detection (BFD) sessions 
[BFD-ON-LAGS]. 

A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.txt 
 
Internet-Drafts are also available by anonymous FTP at: 
ftp://ftp.ietf.org/internet-drafts/ 
 
This Internet-Draft can be retrieved at: 
ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.txt 
 
_______________________________________________ 
I-D-Announce mailing list 
[email-masked] 
https://www.ietf.org/mailman/listinfo/i-d-announce 
Internet-Draft directories: http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 9 Feb 2012 04:43:22 -0800

Hi Manav,

  The draft specifies multiple mechanisms and section 4.2 lists that all MUST be supported. This doesn't make sense from
a vendor perspective IMO. If "all vendors" have to implement "all options", then why not just have 1 option !

Having multiple options also leads to inter-op issue among vendors. We have seen that story with multiple other protocols.

Thanks
Nitin

On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" <[email-masked]> wrote:

Hi,

Cheers, Manav

--

---

From: Tom Sanders <[email-masked]>
Date: Thu, 9 Feb 2012 21:36:02 +0530

Hi Nitin,

I'll let the authors clarify but i think the clue lies is in the
second statement of Sec 4 which says that ".. all described options
can interoperate with each other, as long as following rules,
described in this section, are honored."

I believe the idea is to describe three possible ways to provide the
unicast IP address that micro BFD sessions can potentially use -
explicit configuration, multicast and unicast from 127/8 range.

Vendors can pick one mechanism out of the three mentioned in the
document. Ordinarily they will only interoperate if the other end also
supports the same mechanism. However, If implementations follow the
rules laid out in Sec 4, then they will always interoperate
irrespective of the mechanism each end supports. I think this is in
line with the IETF maxim - "Be conservative in what you give and
liberal in what you recieve". So, while an implementation would always
send out initial discovery packets using multicast, it will also
accept 127/8 for micro BFD sessions.

I could be completely off the mark in which case the authors can
correct me. But this seemed to me to be the high order bit of the
document.

Question to the authors:

(1) 127/8 seems to be vague. Shouldnt you be specifying an exact /32
address that should be used?

(2) Do you think its wise to float two proposals that vendors can
chose. Cant we have just one - either multicast or the 127/8 unicast?
Why do we need two proposals? That would imo also address Nitin's
concern (which i believe is quite valid).

Toms

On 09/02/2012, Nitin Bahadur <[email-masked]> wrote:
> Hi Manav,
>
>   The draft specifies multiple mechanisms and section 4.2 lists that all
> MUST be supported. This doesn't make sense from
> Having multiple options also leads to inter-op issue among vendors. We have
> seen that story with multiple other protocols.
>
> Thanks
> Nitin
>
>
> There were some concerns about operational complexity that using unicast
> addresses for micro BFD sessions would entail. We have written a short draft
> that alleviates such concerns by suggesting few mechanisms that nodes can
> use to auto discover remote neighbor IP addresses before establishing micro
> BFD sessions.
>

-- 
Toms.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 10 Feb 2012 06:38:39 +0530

Hi Nitin,

Sec 4 states that ideally two routers will use the same discovery mechanism to interoperate, however, *if* they happen to implement different mechanisms then they can still interoperate if the rules laid down in sections 4.1 and 4.2 are followed.

We can dilute the requirements laid down in sections 4.1 and 4.2 and we can actually use a lower case "should" instead of RFC 2119 "MUST" since this section is only giving a hint to the developers. We had internally debated on whether we should use RFC 2119 language or not and had decided that it probably made more sense to do that. If we really want different vendors to interoperate despite using different mechanisms then they MUST follow the rules specified in sec 4.1 and 4.2

We have described two discovery mechanisms - one using multicast and the other using 127/8, since we wanted to let the WG reach a consensus on which mechanism it felt was more appropriate. This was again briefly discussed amongst the authors and we decided to specify the two mechanisms in the first version and remove the one that is not favored in the subsequent versions.

Cheers, Manav

> -----Original Message-----
> From: Nitin Bahadur [mailto:[email-masked]] 
> Sent: Thursday, February 09, 2012 6:13 PM
> To: Bhatia, Manav (Manav); [email-masked]
> Subject: Re: IP Address Schemes for BFD on LAG interfaces
> 
> Hi Manav,
> 
>   The draft specifies multiple mechanisms and section 4.2 
> lists that all MUST be supported. This doesn't make sense 
> from a vendor perspective IMO. If "all vendors" have to 
> implement "all options", then why not just have 1 option !
> 
> Having multiple options also leads to inter-op issue among 
> vendors. We have seen that story with multiple other protocols.
> 
> Thanks
> Nitin
> 
> 
> There were some concerns about operational complexity that 
> using unicast addresses for micro BFD sessions would entail. 
> We have written a short draft that alleviates such concerns 
> by suggesting few mechanisms that nodes can use to auto 
> discover remote neighbor IP addresses before establishing 
> micro BFD sessions.
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 10 Feb 2012 06:53:46 +0530

Hi Toms,

> 
> I could be completely off the mark in which case the authors 
> can correct me. But this seemed to me to be the high order 
> bit of the document.

Perfect! What you've said above is absolutely correct. 

> 
> Question to the authors:
> 
> (1) 127/8 seems to be vague. Shouldnt you be specifying an 
> exact /32 address that should be used?

The idea is to let implementations choose a destination IP address randomly from the 127/8 range. This is consistent with what has been described in RFC 5884 (BFD for MPLS LSPs). 	
> 
> (2) Do you think its wise to float two proposals that vendors 
> can chose. Cant we have just one - either multicast or the 
> 127/8 unicast?
> Why do we need two proposals? That would imo also address 
> Nitin's concern (which i believe is quite valid).

Both proposals have their pros and cons and the authors of the draft are not biased towards any particular solution (multicast or 127/8). We would like the members of the WG to reach a consensus on which proposal they would like to see going forward (if one has to be chosen from the two).

Hope this helps.

Cheers, Manav

> lists that 
> > all MUST be supported. This doesn't make sense from a vendor 
> > perspective IMO. If "all vendors" have to implement "all options", 
> > then why not just have 1 option !
> >
> vendors. We 
> > have seen that story with multiple other protocols.
> >
> > Thanks
> > Nitin
> >
> >
> > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" 
> > <[email-masked]>
> > wrote:
> >
> > Hi,
> >
> > There were some concerns about operational complexity that using 
> > unicast addresses for micro BFD sessions would entail. We 
> have written 
> > a short draft that alleviates such concerns by suggesting few 
> > mechanisms that nodes can use to auto discover remote neighbor IP 
> > addresses before establishing micro BFD sessions.
> >
> > Title : IP Address Schemes for Bidirectional Forwarding Detection 
> > (BFD) on Link Aggregation Group (LAG) Interfaces
> > Author(s) : Manav Bhatia
> > Marc Binderberger
> > Sami Boutros
> > Nobo Akiya
> > Internet-Draft directories: http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> >
> 
> 
> --
> Toms.
>

---

From: Mach Chen <[email-masked]>
Date: Fri, 10 Feb 2012 02:24:17 +0000

Hi Manav, Toms and all,

Firstly, I share the concern of Nitin, and agree with Toms's point: one dynamic remote address learning solution is enough. From your reply, the authors also intend to keep only one solution, great!

> Both proposals have their pros and cons and the authors of the draft are not
> biased towards any particular solution (multicast or 127/8). We would like the
> members of the WG to reach a consensus on which proposal they would like to
> see going forward (if one has to be chosen from the two).

Are there any analysis about the pros and cons?

I personally prefer Multicast, because:

1. For the micro-BFD, we need a well-known Multicast MAC, if use Multicast for remote address learning, the Multicast MAC can be used for both remote address and MAC address learning;

2. The micro-BFD draft proposes to use unicast IP for L3 connectivity test, but the member link will be also used for L3 mulitcast forwarding, so use Multicast for remote address learning could test the L3 multicast connectivity at least one time;

3. On the other hand, if use 127/8, the receiver needs to combine extra information(e.g., UDP port) to identify the learning message.

Best regards,
Mach

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Bhatia, Manav (Manav)
> Sent: Friday, February 10, 2012 9:24 AM
> To: Tom Sanders; Nitin Bahadur
> Cc: [email-masked]
> Subject: RE: IP Address Schemes for BFD on LAG interfaces
> 
> Hi Toms,
> 
> 
> >
> The idea is to let implementations choose a destination IP address randomly
> from the 127/8 range. This is consistent with what has been described in RFC
> 5884 (BFD for MPLS LSPs).
> >
> Both proposals have their pros and cons and the authors of the draft are not
> biased towards any particular solution (multicast or 127/8). We would like the
> members of the WG to reach a consensus on which proposal they would like to
> see going forward (if one has to be chosen from the two).
> 
> Hope this helps.
> 
> Cheers, Manav
> 
> >
> > Toms
> >

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 10 Feb 2012 09:50:15 +0530

Hi Mach,

Yes, the idea is to just retain one mechanism. 

I know you like multicast! ;-)

This is btw exactly the opinion that will be useful in zeroing on a final discovery mechanism. It would be good if others too can chime in with their thoughts on this.

Cheers, Manav

> From: Mach Chen [mailto:[email-masked]] 
> Sent: Friday, February 10, 2012 7:54 AM
> To: Bhatia, Manav (Manav); Tom Sanders; Nitin Bahadur
> Cc: [email-masked]
> Firstly, I share the concern of Nitin, and agree with Toms's 
> point: one dynamic remote address learning solution is 
> enough. From your reply, the authors also intend to keep only 
> one solution, great!
> 
> > Both proposals have their pros and cons and the authors of 
> the draft 
> > are not biased towards any particular solution (multicast 
> or 127/8). 
> > We would like the members of the WG to reach a consensus on which 
> > proposal they would like to see going forward (if one has 
> to be chosen from the two).
> 
> 1. For the micro-BFD, we need a well-known Multicast MAC, if 
> use Multicast for remote address learning, the Multicast MAC 
> can be used for both remote address and MAC address learning;
> 
> 2. The micro-BFD draft proposes to use unicast IP for L3 
> connectivity test, but the member link will be also used for 
> L3 mulitcast forwarding, so use Multicast for remote address 
> learning could test the L3 multicast connectivity at least one time;
> 
> 3. On the other hand, if use 127/8, the receiver needs to 
> combine extra information(e.g., UDP port) to identify the 
> learning message.
> 
> 
> Best regards,
> Mach
> 
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Bhatia, Manav (Manav)
> > The idea is to let implementations choose a destination IP address 
> > randomly from the 127/8 range. This is consistent with what 
> has been 
> > described in RFC
> > Both proposals have their pros and cons and the authors of 
> the draft 
> > are not biased towards any particular solution (multicast 
> or 127/8). 
> > We would like the members of the WG to reach a consensus on which 
> > proposal they would like to see going forward (if one has 
> to be chosen from the two).
> > 
> > Hope this helps.
> > 
> > Cheers, Manav
> > 
> > >
> > > Toms
> > >
> > > > A New Internet-Draft is available from the on-line 
> Internet-Drafts 
> > > > directories.
> > > >
> > > > This document describes techniques which can be used by 
> a router 
> > > > to obtain or discover remote neighbor IP address in order to 
> > > > establish micro Bidirectional Forwarding Detection 
> (BFD) sessions
> > > [BFD-ON-LAGS].
> > > >
> > > >
> > > >
> ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00
> > > .t
> > > > xt
> > > >

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 10 Feb 2012 12:13:26 -0500

Hi Manav,
Then you know where my heart is. It randomly picks from 127/8 range. ;)
One possible disadvantage of using single well-known mcast IP address as DA in micro-BFD mode, IMO, is that to receipient initial BFD packets (Your Discriminator is still zeroed) hard to differentiate, they all are the same but My Discriminator. Should not be a problem but might cause some issues nevertheless.

	Regards,
		Greg 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Thursday, February 09, 2012 8:20 PM
To: Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

Hi Mach,

Cheers, Manav

> point: one dynamic remote address learning solution is enough. From 
> your reply, the authors also intend to keep only one solution, great!
> 
> 1. For the micro-BFD, we need a well-known Multicast MAC, if use 
> Multicast for remote address learning, the Multicast MAC can be used 
> for both remote address and MAC address learning;
> 
> 2. The micro-BFD draft proposes to use unicast IP for L3 connectivity 
> test, but the member link will be also used for
> L3 mulitcast forwarding, so use Multicast for remote address learning 
> could test the L3 multicast connectivity at least one time;
> 
> 3. On the other hand, if use 127/8, the receiver needs to combine 
> extra information(e.g., UDP port) to identify the learning message.
> 
> 
> Best regards,
> Mach
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 10 Feb 2012 20:08:57 +0200

Dear Greg, Manav and all,

I have strong doubts regarding using destination IP address in the 127/8 range in the initial micro-BFD packets for the peer address discovery.

In particular, I think that the reference to LSP Ping (RFC 4379) is incorrect, because LSP Ping Echo packets MUST set the Router Alert option in the IP header (see Section 4.3. "Sending an MPLS Echo Request") in conjunction with using Destination IP address from the 127/8 range.

Many IP stacks silently discarded received packets with Destination IP address in the 127/8 range unless it is accompanied by the Router Alert option. RFC 1122 and RFC 1812 definitely allow (and even request) that.
RFC 4379 has taken care to provide for backward compatibility with these requirements.

Adding the Router Alert option to the initial packets of the micro-BFD session could in principle resolve this contradiction but would actually result in one more step away from reuse (claimed) of  existing implementations of RFC 5881.

My 2c,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Gregory Mirsky [[email-masked]]
Sent: Friday, February 10, 2012 7:13 PM
To: Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

Hi Manav,

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Thursday, February 09, 2012 8:20 PM
To: Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

Hi Mach,

Cheers, Manav

> ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 10 Feb 2012 13:51:29 -0500

Dear Sasha,
Thank you for pointing to RA use in LSP Ping. I agree that reference to RFC 4379 is not the most appropriate. I think that RFC 5884 is more suitable as reference since both address single hop BFD and thus Router Alert is not required.

	Regards,
		Greg

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Friday, February 10, 2012 10:09 AM
To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

My 2c,
     Sasha

Hi Manav,
Then you know where my heart is. It randomly picks from 127/8 range. ;) One possible disadvantage of using single well-known mcast IP address as DA in micro-BFD mode, IMO, is that to receipient initial BFD packets (Your Discriminator is still zeroed) hard to differentiate, they all are the same but My Discriminator. Should not be a problem but might cause some issues nevertheless.

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Thursday, February 09, 2012 8:20 PM
To: Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

Hi Mach,

Cheers, Manav

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 10 Feb 2012 22:10:25 +0200

Dear Greg,
RFC 5884 indeed does not explicitly requires any form of Router Alert.
However, it uses LSP Ping (RFC 4379) for bootstrapping the BFD sessions - and this, in its turn, uses Router Alert.

So I am not sure that reference to RFC 5884 is appropriate either.

Did I miss something?

Regards,
     Sasha

________________________________________
From: Gregory Mirsky [[email-masked]]
Sent: Friday, February 10, 2012 8:51 PM
To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

Dear Sasha,

        Regards,
                Greg

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Friday, February 10, 2012 10:09 AM
To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

My 2c,
     Sasha

Hi Manav,

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Thursday, February 09, 2012 8:20 PM
To: Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

Hi Mach,

Cheers, Manav

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 10 Feb 2012 15:18:14 -0500

Dear Sasha,
AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional. Thus use of Router Alert is not mandated by RFC 5884.

What do you think?

	Regards,
		Greg

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Friday, February 10, 2012 12:10 PM
To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

Dear Greg,

Did I miss something?

Regards,
     Sasha

Dear Sasha,

        Regards,
                Greg

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Friday, February 10, 2012 10:09 AM
To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

My 2c,
     Sasha

Hi Manav,

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Thursday, February 09, 2012 8:20 PM
To: Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

Hi Mach,

Cheers, Manav

---

From: Glen Kent <[email-masked]>
Date: Sat, 11 Feb 2012 02:41:24 +0530

Hi Manav,

I like the idea of discovery since manual configuration is not
possible in all deployments.

I would prefer multicast since other discovery protocols use
multicast. I also find it rather unnatural to see 127/8 range out on
the wire. Ideally, this should never exit the box. RFC 5735 says the
following about 127/8 -
"As described in [RFC1122], Section 3.2.1.3, addresses within the
entire 127.0.0.0/8 block do not legitimately appear on any network
anywhere."

Glen

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 10 Feb 2012 16:35:27 -0500

Hi Kent,
I believe that 127/8 addresses do not require manual configuration and auto-discovery support because they are randomly selected as DA by the sender and not checked by the reciever.
RE: sending 127/8 on the wire. Since we're to use IP over Ethernet EtherType, formally 127/8 is on the wire as IP DA. But I'd note that RFC 1112 defines host behavior whereas RFC 1812 requires not to forward (by default) packets with destination address on 127/8 network. Thus we guaranteed that micro-BFD packets would not be leaked by far-end node.

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Glen Kent
Sent: Friday, February 10, 2012 1:11 PM
To: Bhatia, Manav (Manav); [email-masked]
Subject: Re: IP Address Schemes for BFD on LAG interfaces

Hi Manav,

I like the idea of discovery since manual configuration is not possible in all deployments.

I would prefer multicast since other discovery protocols use multicast. I also find it rather unnatural to see 127/8 range out on the wire. Ideally, this should never exit the box. RFC 5735 says the following about 127/8 - "As described in [RFC1122], Section 3.2.1.3, addresses within the entire 127.0.0.0/8 block do not legitimately appear on any network anywhere."

Glen

---

From: Marc Binderberger <[email-masked]>
Date: Fri, 10 Feb 2012 23:24:13 +0100

Hello Greg, Alexander et al.,

well, Alexander has some point. RFC5884 gets away IMHO because the IP TTL must be "1". And in case of multiple labels for the LSP it states in section 7

                            [...] If the label stack has a depth greater
   than one, the TTL of the inner MPLS label MAY be set to 1.  This may
   be necessary for certain FECs to enable the egress LSR's control
   plane to receive the packet [RFC4379].

So I think RFC5884 uses the TTL method to ensure the packet gets punted up to the control plane.

("I think" as the last paragraph of section 4 has some vagueness which I decided to ignore when implementing but meanwhile I wonder ...).

Back to the Address Scheme, you mentioned in you earlier email:

"One possible disadvantage of using single well-known mcast IP address as DA in micro-BFD mode, IMO, is that to receipient initial BFD packets (Your Discriminator is still zeroed) hard to differentiate, they all are the same but My Discriminator. Should not be a problem but might cause some issues nevertheless."

The micro-session draft requires the use of "interface information of the member link" to demultiplex the initial micro-session BFD packets. I also don't see how a randomly chosen address out of 127/8 can help the receiver side to do a meaningful differentiation (?).
(not against the random choice although Tom mentioned in another email that one could simply chose a fixed address out of 127/8 if that range is to be used)

Anyway, this is a good discussion :-)

Regards, Marc

--
Marc Binderberger           <[email-masked]>

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 10 Feb 2012 17:43:11 -0500

Hi Marc,
I believe that regardless of addressing method IP TTL in micro-BFD must be set to 1 because it is single-hop BFD. And RFC 5884 does that for the same reason - LSP is a single hop segment, a link. Setting MPLS TTL to expire is, in a way, similar to VCCV Control Channel Type 3 that uses TTL expiration. Ethernet doesn't have TTL field and there might be existing equipment that would drop 127/8 addressed IP packets and micro-BFD would not work. But the same would be the case if multicast addressing with new well-known address partially deployed.

	Regards,
		Greg

-----Original Message-----
From: Marc Binderberger [mailto:[email-masked]] 
Sent: Friday, February 10, 2012 2:24 PM
To: Tom Sanders; Alexander Vainshtein; Gregory Mirsky
Cc: Bhatia, Manav (Manav); Mach Chen; Nitin Bahadur; [email-masked]
Subject: Re: IP Address Schemes for BFD on LAG interfaces

Regards, Marc

On 2012-02-10, at 21:18 , Gregory Mirsky wrote:

> From: [email-masked] [[email-masked]] On Behalf Of 
> Gregory Mirsky [[email-masked]]

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 11 Feb 2012 00:46:04 +0100

Hello Gregory,

I beg to differ on the TTL part. Singlehop async BFD uses typically TTL = 255; RFC5884 is the exception. 

And for reasons of having a simple security mechanism I would like to see TTL 255 in use (you can use the more "CPU intensive" option of authentication but I would argue against this as a mandatory method).

Anyway, interesting aspect which I missed when we wrote the draft: if the choice of the IP address has an impact on the TTL. I warm up for "learn IP address by configuration" ;-) - simple idea, simple code.

Regards, Marc

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 11 Feb 2012 11:10:35 +0200

Dear Greg,
I will re-check RFC 5884 and come back to you soon.

Regards,
     Sasha

Sent: Friday, February 10, 2012 10:18 PM

Dear Sasha,

What do you think?

        Regards,
                Greg

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Friday, February 10, 2012 12:10 PM
To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

Dear Greg,

Did I miss something?

Regards,
     Sasha

Dear Sasha,

        Regards,
                Greg

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Friday, February 10, 2012 10:09 AM
To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

My 2c,
     Sasha

Hi Manav,

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Thursday, February 09, 2012 8:20 PM
To: Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

Hi Mach,

Cheers, Manav

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 11 Feb 2012 12:24:41 +0200

Dear Greg,

Regarding your claim that ""use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional" - quoting from RFC 5884:

In Section 4 "Theory of operation"

   To enable fault detection procedures specified in this document, for
   a particular MPLS LSP, this document requires the ingress and egress
   LSRs to be configured.  This includes configuration for supporting
   BFD and LSP Ping as specified in this document.  It also includes
   configuration that enables the ingress LSR to determine the method
   used by the egress LSR to identify Operations, Administration, and
   Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of
   the innermost MPLS label needs to be set to 1 to enable the egress

   LSR to identify the OAM packet.  For fault detection for MPLS PWs,
   this document assumes that the PW control channel type [RFC5085] is
   configured and the support of LSP Ping is also configured.

In Section 6 "Session Establishment":

A BFD session is bootstrapped using LSP Ping.

...

   To establish a BFD session, an LSP Ping
   Echo request message MUST carry the local discriminator assigned by
   the ingress LSR for the BFD session.  This MUST subsequently be used
   as the My Discriminator field in the BFD session packets sent by the
   ingress LSR.

And from Section 6.1. "BFD Discriminator TLV in LSP Ping":

   LSP Ping Echo request and Echo reply messages carry a BFD
   discriminator TLV for the purpose of session establishment as
   described above.  IANA has assigned a type value of 15 to this TLV.
   This TLV has a length of 4.  The value contains the 4-byte local
   discriminator that the LSR, sending the LSP Ping message, associates
   with the BFD session.

   If the BFD session is not in UP state, the periodic LSP Ping Echo
   request messages MUST include the BFD Discriminator TLV.

The highlighted text suggests to me that RFC 5884 mandates usage of LSP Ping for bootstrapping of BFD sessions. Taking into account that it supports BFD session per FEC for a given LSP, I do not see any alternative to this method.

Did I miss something substantial?

Regards,

     Sasha

Dear Sasha,

What do you think?

        Regards,
                Greg

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Friday, February 10, 2012 12:10 PM
To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

Dear Greg,

Did I miss something?

Regards,
     Sasha

Dear Sasha,

        Regards,
                Greg

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Friday, February 10, 2012 10:09 AM
To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

My 2c,
     Sasha

Hi Manav,

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Thursday, February 09, 2012 8:20 PM
To: Mach Chen; Tom Sanders; Nitin Bahadur
Cc: [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

Hi Mach,

Cheers, Manav

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 11 Feb 2012 11:46:33 +0100

Hello Alexander and Greg,

> The highlighted text suggests to me that RFC 5884 mandates usage of LSP Ping for bootstrapping of BFD sessions. Taking into account that it supports BFD session per FEC for a given LSP, I do not se…

I agree. The first sentence in section 6 was already enough for me. It seems obvious to me that RFC5884 is tightly coupling BFD and LSP ping, nothing optional.

Now Greg's email had 2 statements:

"AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional. Thus use of Router Alert is not mandated by RFC 5884."

The first sentence you have answered. For the second sentence I assume this is related to BFD packets (?). And indeed RFC5884 is not mentioning router alert a single time, neither as option nor as label. My understanding is the BFD packet has no router alert option in it's IP header.

I have sent an email to George, one of the authors of RFC5884 and RFC4379, why LSP ping echo requests - with an IP header very similar to BFD in RFC5884 - need to carry RA option but BFD does not.

> Did I miss something substantial?

If so then you are not alone ;-)

Regards, Marc

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 11 Feb 2012 17:24:22 +0200

Marc hi,
Lots of thanks for a prompt response.

Regarding your question to George "why LSP ping echo requests - with an IP header very similar to BFD in RFC5884 - need to carry RA option but BFD does not" - I can only offer my guess (FWIW):

LSP Ping  verifies (among other things) consistency between the CP and DP. Hence it takes care of the use case when the MPLS Echo request packet is processed by an LSR that is not related to the original LSP being pinged (e.g., because DP is broken). RA option in the IP header effectively guarantees that the packet goes to the control plane instead of just being discarded,

BFD in LSP assumes that the CP and DP are congruent and just checks the DP integrity. If the BFD-in-LSP packet ends in a wrong LSR, the BFD session will fail, but BFD will not happen in isolating the DP fault that has caused this. Hence no need for RA option.

 My 2c,
     Sasha

________________________________
From: Marc Binderberger [[email-masked]]
Sent: Saturday, February 11, 2012 12:46 PM
To: Alexander Vainshtein; Gregory Mirsky
Cc: Mach Chen; [email-masked]
Subject: Re: IP Address Schemes for BFD on LAG interfaces

Regards, Marc

Dear Greg,

...

Regards,
     Sasha

Cc: [email-masked]<mailto:[email-masked]>

Dear Sasha,

What do you think?

        Regards,
                Greg

--
Marc Binderberger           <[email-masked]<mailto:[email-masked]>>

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 11 Feb 2012 07:49:57 -0800

Dear Sasha, Marc, et al.
Greatly appreciate our discussion.
The LSP Ping is widely used mechanism to bootstrap BFD sessions over MPLS
LSP because of PHP. If an operator disables PHP then no bootstrapping
needed. Alternatively, mapping might be statically configured on the remote
LER.

My $.02

Kind regards,
Greg

On Sat, Feb 11, 2012 at 2:46 AM, Marc Binderberger <[email-masked]> wrote:

> The highlighted text suggests to me that RFC 5884 mandates usage of LSP
> Ping for bootstrapping of BFD sessions. Taking into account that it
> supports BFD session per FEC for a given LSP, I do not see any alternative
> to this method.
>
>
> I agree. The first sentence in section 6 was already enough for me. It
> seems obvious to me that RFC5884 is tightly coupling BFD and LSP ping,
> nothing optional.
>
> "AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is
> optional. Thus use of Router Alert is not mandated by RFC 5884."
>
>
> The first sentence you have answered. For the second sentence I assume
> this is related to BFD packets (?). And indeed RFC5884 is not mentioning
> router alert a single time, neither as option nor as label. My
> understanding is the BFD packet has no router alert option in it's IP
> header.
>
> I have sent an email to George, one of the authors of RFC5884 and RFC4379,
> why LSP ping echo requests - with an IP header very similar to BFD in
> RFC5884 - need to carry RA option but BFD does not.
>
>
> Regarding your claim that ""use of LSP Ping to bootstrap a BFD session
> over MPLS LSP is optional" - quoting from RFC 5884:
> The highlighted text suggests to me that RFC 5884 mandates usage of LSP
> Ping for bootstrapping of BFD sessions. Taking into account that it
> supports BFD session per FEC for a given LSP, I do not see any alternative
> to this method.
>
>
>
>
> AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is
> optional. Thus use of Router Alert is not mandated by RFC 5884.
>
> What do you think?
>
>         Regards,
>                 Greg
>
>
> --

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 12 Feb 2012 07:41:28 +0200

Dear Greg,

Regarding your statement " If an operator disables PHP then no bootstrapping needed":

IMHO any form of LSP merge (and not just PHP) requires bootstrapping for BFD.
Please consider the case of MP2P LSPs created by LDP when LSPs for a given IPv4 or IPv6 prefix originate at different head-end LSRs merge at some point along the way so that the tail-end LSR cannot use the ingress label to disambiguate the source even if this label is not popped.

This is why RFC 6428 (that is limited to MPLS-TP with its prohibition on LSP merge) does not require LPP ping for the bootstrapping of BFD sessions while RFC 5884 requires it.

My 2c,
     Sasha

________________________________
From: Greg Mirsky [[email-masked]]
Sent: Saturday, February 11, 2012 5:49 PM
To: Marc Binderberger
Cc: Alexander Vainshtein; Gregory Mirsky; [email-masked]
Subject: Re: IP Address Schemes for BFD on LAG interfaces

Dear Sasha, Marc, et al.
Greatly appreciate our discussion.
The LSP Ping is widely used mechanism to bootstrap BFD sessions over MPLS LSP because of PHP. If an operator disables PHP then no bootstrapping needed. Alternatively, mapping might be statically configured on the remote LER.

My $.02

Kind regards,
Greg

On Sat, Feb 11, 2012 at 2:46 AM, Marc Binderberger <[email-masked]<mailto:[email-masked]>> wrote:
Hello Alexander and Greg,

Regards, Marc

Dear Greg,

...

Regards,
     Sasha

From: Gregory Mirsky [[email-masked]<mailto:[email-masked]>]

Dear Sasha,

What do you think?

        Regards,
                Greg

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 11 Feb 2012 21:54:28 -0800

Dear Sasha,
yes, MPLS-TP indeed excludes LSP merge but it doesn't exclude PHP (I still
wonder why it is). AFAIK, PHP is disabled by default but, I imagine, can be
enabled in MPLS-TP network, hence MPLS LSP bootstrapping would come handy.
But I've brought up PHP to illustrate that use of MPLS LSP Ping as
bootstrapping mechanism for MPLS BFD is not mandatory but optional.

Kind regards,
Greg

On Sat, Feb 11, 2012 at 9:41 PM, Alexander Vainshtein <
[email-masked]> wrote:

> Please consider the case of MP2P LSPs created by LDP when LSPs for a
> given IPv4 or IPv6 prefix originate at different head-end LSRs merge at
> some point along the way so that the tail-end LSR cannot use the ingress
> label to disambiguate the source even if this label is not popped.
>
> This is why RFC 6428 (that is limited to MPLS-TP with its prohibition on
> LSP merge) does not require LPP ping for the bootstrapping of BFD sessions
> while RFC 5884 requires it.
>
> My 2c,
>      Sasha
>
>
>
>  ------------------------------
> *From:* Greg Mirsky [[email-masked]]
> *Sent:* Saturday, February 11, 2012 5:49 PM
> *To:* Marc Binderberger
> *Cc:* Alexander Vainshtein; Gregory Mirsky; [email-masked]
> *Subject:* Re: IP Address Schemes for BFD on LAG interfaces
>
>  Dear Sasha, Marc, et al.
>>   The highlighted text suggests to me that RFC 5884 mandates usage of
>> LSP Ping for bootstrapping of BFD sessions. Taking into account that it
>>  I have sent an email to George, one of the authors of RFC5884 and
>> RFC4379, why LSP ping echo requests - with an IP header very similar to BFD
>> in RFC5884 - need to carry RA option but BFD does not.
>>
>>
>   This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please inform us
> by e-mail, phone or fax, and then delete the original and all copies
> thereof.
>

---

From: <[email-masked]>
Date: Thu, 16 Feb 2012 09:45:36 +0000

Hi Greg,

Like Glen I prefer the multicast approach, it aligns with existing discovery approaches and IP addressing for other 'control' plane protocols on links. From an operational perspective I think it'll make more sense to someone fault tracing a link, more likely to spot it's a link local address and remember it's the 'start-up' address used for BFD micro sessions. Also dependent on deployments the multicast approach packets might more easily map into existing security policies and any classification/scheduling QoS schemas.

I would add however that I have no issue with having to configure a static mapping for the micro BFD session endpoint address - if it means a quicker delivery of implementable solutions. 

regards

Paul Hitchen
BT Innovate & Design 

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Gregory Mirsky [[email-masked]]
Sent: 10 February 2012 21:35
To: Glen Kent; Bhatia, Manav (Manav); [email-masked]
Subject: RE: IP Address Schemes for BFD on LAG interfaces

Hi Kent,

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Glen Kent
Sent: Friday, February 10, 2012 1:11 PM
To: Bhatia, Manav (Manav); [email-masked]
Subject: Re: IP Address Schemes for BFD on LAG interfaces

Hi Manav,

Glen

---

From: Tom Sanders <[email-masked]>
Date: Thu, 16 Feb 2012 18:10:56 +0530

I too would prefer to use a multicast address as all other mechanisms
that use 127/8 range seem to rely on other mechanisms (router alert,
ttl, etc) to punt the packet to CPU. I also agree with what somebody
had earlier said on the list, that 127/8 should never leave the box.
While i dont expect to see a switch between two micro BFD end points,
but there is nothing that precludes the possibility of inserting one.
In that case, i dont want us to be sending L3 traffic destined to
127/8 as behavior of snooping switches when dealing with this address
range could be undefined. I am certain that there will not be any
snooping devices or intermediaries dropping L3 traffic for 128/8, but
one can never be too certain.

This problem btw just does not exist when using a well known multicast
address range for end node discovery.

Toms.

-- 
Toms.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Feb 2012 15:33:15 -0500

> http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.txt 

Two comments with my WG chair hat off:
1. I agree with Nitin and others: Once we've come to some consensus, the
document should be reduced to one bootstrapping mechanism.
2. My personal preference would be multicast. (Yes, Mach... :-)  However,
I'd encourage the authors to consider implications on switched links.  In
such a configuration what sort of issues could you run into?

With the hat on:
Once we come to consensus as to the mechanism, we should consider merging
the discovery document and the LAG document unless we find that the LAG
document is more general.  An example would be an application to MPLS LAG.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Feb 2012 15:46:50 -0500

Clarification to my last post:

> > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.txt 
[...]
> 2. My personal preference would be multicast.

However, this would require clarification of when we send unicast vs.
multicast when we're signaling DOWN/ADMINDOWN.  As an example, when we're
transitioning to down we may wish to send DetectMult packets to the last
known unicast address prior to transitioning back to multicast.

-- Jeff

---

From: Tom Sanders <[email-masked]>
Date: Tue, 21 Feb 2012 06:42:09 +0530

Hi Jeff,

> such a configuration what sort of issues could you run into?

Multicast seems to be a clear winner here.

> the discovery document and the LAG document unless we find that the LAG

I would rather that we keep the discovery mechanism outside the main
document since the earlier document is quite generic.

> document is more general.  An example would be an application to MPLS LAG.

What is a MPLS LAG?

Is it an MPLS tunnel over a LAG or a LAG where the constituent "links"
are MPLS tunnels (something like a composite link).

I trust its the latter that youre alluding to. In that case, we will
require a different discovery mechanism entailing a new draft. Thus
its better to keep discovery separate from the main draft.

Toms.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 21 Feb 2012 10:27:15 +0530

Jeff,
 
> 1. I agree with Nitin and others: Once we've come to some 
> consensus, the document should be reduced to one 
> bootstrapping mechanism.

Yes that's the idea. The WG seems to be converging towards multicast. 

> 2. My personal preference would be multicast. (Yes, Mach... 
> :-)  However, I'd encourage the authors to consider 
> implications on switched links.  In such a configuration what 
> sort of issues could you run into?
> 
> With the hat on:
> Once we come to consensus as to the mechanism, we should 
> consider merging the discovery document and the LAG document 
> unless we find that the LAG document is more general.  An 
> example would be an application to MPLS LAG.

I would prefer to keep the discovery mechanism outside the base draft because including this in the base draft will force implementations to implement the discovery process (which is orthogonal to how we need to run BFD on each member link of LAG). There are use cases where there isnt a need for a discovery mechanism and a few vendors may choose not to implement this unless asked for by their customers. By including the discovery mechanism in the base draft, any implementation not supporting this would be non compliant to the BFDoLAGs standard. OTOH if we include this mechanism as a MAY or a SHOULD then we could have interoperability issues where two compliant implementations may not be able to use this mechanism. 

I would like to keep this as a separate draft and implementations claiming compliance to draft-mmsn-bfd-* will be able to use a discovery mechanism.

We could also have other link types (composite links having MPLS tunnels as constituents) that may need a BFD discovery process other than what has been described in draft-mmsn-bfd-*. Those would anyways be described in a different draft. Given this I see no good reason for us to include this in the base draft.

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 21 Feb 2012 19:04:28 +0530

Hi Jeff,

> multicast when we're signaling DOWN/ADMINDOWN.  As an 
> example, when we're transitioning to down we may wish to send 
> DetectMult packets to the last known unicast address prior to 
> transitioning back to multicast.

We have some text that talks about this in Sec 3.2

   "Each router will
   discover the remote IP address by examining the source IP in micro
   BFD session packets.  When transitioning into INIT or UP states,
   discovered neighbor IP address MUST be used as destination address in
   the IP header.  Micro BFD sessions are to proceed as described in
   [RFC5880] and [BFD-ON-LAGS].  When a micro BFD session needs to start
   over the session bring-up logic, destination address in the IP header
   MUST be reset to a well-known link-local multicast IP address.  "

Is this good enough or would you like some more clarification here?

Cheers, Manav

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 21 Feb 2012 10:20:56 -0500

> Is this good enough or would you like some more clarification here?

I'd like some clarification.  Down is a natural part of our state machine
and it'd be nice, IMO, to make sure that sessions that may have some state
in an implementation (rather than a potential catch-all state machine that
spawns new sessions) get the chance to be torn down a bit more explicitly
using unicast.

In an ideal world, the fact that the down is arriving as multicast shouldn't
matter.  I'm somewhat cynical about that. 

If the WG consensus is that multicast is fine for all Down/AdminDown
traffic, I'll cede my point. :-)

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 21 Feb 2012 10:22:23 -0500

> its better to keep discovery separate from the main draft.

I was indeed talking about composite links.  I think you and Manav (in a
separate message) have made good cause for keeping the bootstrapping in a
separate draft.

-- Jeff

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 21 Feb 2012 18:01:27 +0200

Jeff and all,
IMHO and FWIW the doubts regarding usage of different addresses in different states actually hides a very simple fact:
 Discovery of the peer address to be used in the micro-BFD session) should be separated from the micro-BFD session.

I've said in one of my earlier emails that, for LAG with LACP (where micro-BFD sessions are initiated by the LACP) one could use the peer port MAC address in a non-IP encapsulation of the BFD packets. 

Since the WG consensus goes now towards using IP-based encapsulation, I suggest a separate multicast-based peer discovery protocol that would return both IP address of the peer LAG and the MAC address of the peer port.  Micro-BFD sessions would then be initiated by this protocol and use the same destination addresses (IP and MAC) for the life span of the micro-BFD session.

We could use something like Router Discovery Protocol (RFC 1256) for IPv4 or Neighbor Discovery Protocol for IPv6. The only modification is that the advertisement messages would have to be transmitted separately on each LAG member link.

Do I miss something substantial?

Regards,
     Sasha

> Behalf Of Jeffrey Haas
> Sent: Tuesday, February 21, 2012 5:21 PM
> To: Bhatia, Manav (Manav)
> Cc: [email-masked]

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 21 Feb 2012 17:36:16 +0100

Hello Alexander,

> Do I miss something substantial?

in my opinion: simplicity. 

Using the first BFD packets for auto discovery of MAC and IP address is smart in this sense. Having an extra protocol means we extend the state machine by an "discovery" state (even if it never shows up in a BFD packet), i.e. Discover -> Down -> Init -> Up -> Down (-> Discover?).

The "life span of the micro-BFD session" still needs a discussion - which is what we are into now anyway, wondering if multiplier Down packets should be transmitted with unicast IP/MAC before falling back to multicast IP and dedicated (or multicast) MAC.

At least for the initial problem to solve - which is BFD over an Ethernet (and maybe POS) LAG for IP networks - we should have something simple as the task itself it not so terribly complicated ;-)

And for the generalization of a LAG like the "composite MPLS links" I don't like to make a statement yet; it may turn out they are better served with other mechanism (like RFC5884 bootstrapping for the composite MPLS links example).

Regards, Marc

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 21 Feb 2012 18:47:54 +0200

Dear Marc,
I agree that "using the first BFD packets for auto discovery of MAC and IP address is smart". 
But I do not think it is simple, and I am a great believer in the KISS principle.

As for the additional states - there would be no difference with the normal BFD operation as described in RFC 5881 IMHO.

Regards,
     Sasha

> Sent: Tuesday, February 21, 2012 6:36 PM
> To: Alexander Vainshtein
> Cc: Jeffrey Haas; [email-masked]
> Using the first BFD packets for auto discovery of MAC and IP address is smart
> in this sense. Having an extra protocol means we extend the state machine
> by an "discovery" state (even if it never shows up in a BFD packet), i.e.
> Discover -> Down -> Init -> Up -> Down (-> Discover?).
> 
> The "life span of the micro-BFD session" still needs a discussion - which is
> what we are into now anyway, wondering if multiplier Down packets should
> be transmitted with unicast IP/MAC before falling back to multicast IP and
> dedicated (or multicast) MAC.
> 
> At least for the initial problem to solve - which is BFD over an Ethernet (and
> maybe POS) LAG for IP networks - we should have something simple as the
> task itself it not so terribly complicated ;-)
> 
> And for the generalization of a LAG like the "composite MPLS links" I don't
> like to make a statement yet; it may turn out they are better served with
> other mechanism (like RFC5884 bootstrapping for the composite MPLS links
> example).
> 
> 
> Regards, Marc
> 
> 
> 
> > IMHO and FWIW the doubts regarding usage of different addresses in
> different states actually hides a very simple fact:
> > I've said in one of my earlier emails that, for LAG with LACP (where micro-
> BFD sessions are initiated by the LACP) one could use the peer port MAC
> address in a non-IP encapsulation of the BFD packets.
> >
> > Since the WG consensus goes now towards using IP-based encapsulation, I
> suggest a separate multicast-based peer discovery protocol that would
> return both IP address of the peer LAG and the MAC address of the peer
> port.  Micro-BFD sessions would then be initiated by this protocol and use
> the same destination addresses (IP and MAC) for the life span of the micro-
> BFD session.
> >
> > We could use something like Router Discovery Protocol (RFC 1256) for IPv4
> or Neighbor Discovery Protocol for IPv6. The only modification is that the
> advertisement messages would have to be transmitted separately on each
> LAG member link.
> >
> Telecom. If you have received this transmission in error, please inform us by
> e-mail, phone or fax, and then delete the original and all copies thereof.
> >
> 
> --

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 22 Feb 2012 07:04:26 +0530

Hi Sasha,

I don't think involving an external protocol to influence BFD state machinery complies with the KISS principle. There are several things that can potentially break. Take authentication for example. You could use HMAC-SHA to protect BFD sessions. Do you get similar security with RFC 1256? In the security world your entire security is only as secure as your weakest link. If someone can easily spoof the "discovery" messages then your entire micro BFD session security is compromised. Its best to keep things in tight control and as statisticians say, best to design a system with minimum degrees of freedom.

Cheers, Manav

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> Sent: Tuesday, February 21, 2012 10:18 PM
> To: Marc Binderberger
> Cc: [email-masked]
> As for the additional states - there would be no difference 
> with the normal BFD operation as described in RFC 5881 IMHO.
> 
> Regards,
>      Sasha
> 
> 
> > Using the first BFD packets for auto discovery of MAC and 
> IP address 
> > is smart in this sense. Having an extra protocol means we 
> extend the 
> > state machine by an "discovery" state (even if it never 
> shows up in a BFD packet), i.e.
> > The "life span of the micro-BFD session" still needs a discussion - 
> > which is what we are into now anyway, wondering if multiplier Down 
> > packets should be transmitted with unicast IP/MAC before 
> falling back 
> > to multicast IP and dedicated (or multicast) MAC.
> > 
> > At least for the initial problem to solve - which is BFD over an 
> > Ethernet (and maybe POS) LAG for IP networks - we should have 
> > something simple as the task itself it not so terribly 
> complicated ;-)
> > 
> > And for the generalization of a LAG like the "composite 
> MPLS links" I 
> > don't like to make a statement yet; it may turn out they are better 
> > served with other mechanism (like RFC5884 bootstrapping for the 
> > composite MPLS links example).
> > 
> > 
> > Regards, Marc
> > 
> > 
> > 
> > > Discovery of the peer address to be used in the micro-BFD 
> session) 
> > > should
> > be separated from the micro-BFD session.
> > >
> > > I've said in one of my earlier emails that, for LAG with 
> LACP (where 
> > > micro-
> > BFD sessions are initiated by the LACP) one could use the peer port 
> > MAC address in a non-IP encapsulation of the BFD packets.
> > >
> > port.  Micro-BFD sessions would then be initiated by this 
> protocol and 
> > use the same destination addresses (IP and MAC) for the 
> life span of 
> > the micro- BFD session.
> > >
> > > We could use something like Router Discovery Protocol 
> (RFC 1256) for 
> > > IPv4
> > or Neighbor Discovery Protocol for IPv6. The only 
> modification is that 
> > the advertisement messages would have to be transmitted 
> separately on 
> > each LAG member link.
> > >
> > >>>> multicast when we're signaling DOWN/ADMINDOWN.  As an example, 
> > >>>> when we're transitioning to down we may wish to send 
> DetectMult 
> > >>>> packets to the last known unicast address prior to 
> transitioning 
> > >>>> back to multicast.
> > >>>
> > >>>   [RFC5880] and [BFD-ON-LAGS].  When a micro BFD 
> session needs to
> > start
> > >> I'd like some clarification.  Down is a natural part of 
> our state 
> > >> machine and it'd be nice, IMO, to make sure that 
> sessions that may 
> > >> have some
> > state
> > >> in an implementation (rather than a potential catch-all state 
> > >> machine
> > that
> > >> In an ideal world, the fact that the down is arriving as 
> multicast 
> > >> shouldn't matter.  I'm somewhat cynical about that.
> > >>
> > >> If the WG consensus is that multicast is fine for all 
> > >> Down/AdminDown traffic, I'll cede my point. :-)
> > >>
> > >> -- Jeff
> > >
> > >
> > Telecom. If you have received this transmission in error, please 
> > inform us by e-mail, phone or fax, and then delete the 
> original and all copies thereof.
> > >
> > 
> > --
> This e-mail message is intended for the recipient only and 
> contains information which is CONFIDENTIAL and which may be 
> proprietary to ECI Telecom. If you have received this 
> transmission in error, please inform us by e-mail, phone or 
> fax, and then delete the original and all copies thereof.
> 
>