Subject: TTL of micro BFD packets?

From: Tom Sanders <[email-masked]>
Date: Wed, 22 Feb 2012 21:22:52 +0530

Hi,

Just wondering. What will the TTL be set to for the micro BFD packets?
Will it be 1 or set to 255 by the sender and checked to be 254 by the
receiver?

We should be chary in specifying the TTL as that would mean that the
micro BFD packets can never traverse multiple IP hops. Is that ok? I
think it is as long as we assume that a micro BFD session can only be
established between two back to back routers. However, that precludes
the possibility of supporting micro BFD sessions over a composite
link. Or perhaps that never ever was the intention, eh?

Personally i would like it to remain unspecified for future extensibility.

-- 
Toms.

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 22 Feb 2012 17:03:36 +0100

Hello Tom,

I agree we should have flexibility. Now draft-mmm-03 is specific for IP/UDP packets over LAG and does not really cover "composite XYZ". There is just a discussion if we need to generalize the draft.

To allow for the low-cost security mechanism we have with other single-hop BFD sessions I would like to see TTL=255 for IP/UDP encapsulated BFD packets for LAG member links. Similar to RFC5880 we can relax the TTL requirements when authentication is used.

My $0.02

Regards, Marc

--
Marc Binderberger           <[email-masked]>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 22 Feb 2012 11:41:26 -0500

Hi Tom,
I wonder why support of micro-BFD on IP-enabled composite links (that by itself seems to me as strong limitation) would require IP TTL of more then one hop? If member link is logical, not physical then it appears as layer violation as composite links are always between the same two routers. Or you refer to another model of composite links not the one in draft-ietf-rtgwg-cl-requirement-05?

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Sanders
Sent: Wednesday, February 22, 2012 7:53 AM
To: [email-masked]
Subject: TTL of micro BFD packets?

Hi,

Just wondering. What will the TTL be set to for the micro BFD packets?
Will it be 1 or set to 255 by the sender and checked to be 254 by the receiver?

We should be chary in specifying the TTL as that would mean that the micro BFD packets can never traverse multiple IP hops. Is that ok? I think it is as long as we assume that a micro BFD session can only be established between two back to back routers. However, that precludes the possibility of supporting micro BFD sessions over a composite link. Or perhaps that never ever was the intention, eh?

--
Toms.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 23 Feb 2012 07:02:57 +0530

Hi Tom,

> Will it be 1 or set to 255 by the sender and checked to be 

Should be the latter.

> 
> We should be chary in specifying the TTL as that would mean 
> that the micro BFD packets can never traverse multiple IP 
> hops. Is that ok? I think it is as long as we assume that a 

I think it should be ok. You don't want micro BFD packets to be traversing multiple IP hops.

> micro BFD session can only be established between two back to 
> back routers. However, that precludes the possibility of 
> supporting micro BFD sessions over a composite link. Or 
> perhaps that never ever was the intention, eh?

composite link, as the name suggests is just a "link", and as such should only be one IP hop.

> Personally i would like it to remain unspecified for future 

This to me would be a hack! :-)

The intention of the draft-mmm- is to monitor individual component links in a bundle and to remove a link for L3 forwarding if the micro session over that link goes down. I don't see why we would need multiple hops if its only the "link" liveliness that we're interested in. While we have taken an example of a LAG as a bundle there is really nothing that precludes the possibility of that bundle being a composite link comprising of MPLS tunnels or something else. In that case the "link" could be an MPLS tunnel.

Yes, we have some text that's specific to IEEE 802.1ax and LACP, but the idea can be generalized to work for other bundles that have separate component links. The draft specifically talks about IEEE 802.1ax and LACP since that's what our customers have been specifically asking us to fix.

Cheers, Manav

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 23 Feb 2012 16:07:05 -0800

Dear Manav,
you've brought interesting scneario in your example of composite that has
MPLS LSP as member link:
"In that case the "link" could be an MPLS tunnel."
In this case, would use of multicast IP address for multi-BFD and 127/8 for
BFD with IP/UDP encapsulation over the same MPLS LSP be slightly confusing?

Regards,
Greg

On Wed, Feb 22, 2012 at 5:32 PM, Bhatia, Manav (Manav) <
[email-masked]> wrote:

> The intention of the draft-mmm- is to monitor individual component links
> in a bundle and to remove a link for L3 forwarding if the micro session
> over that link goes down. I don't see why we would need multiple hops if
> its only the "link" liveliness that we're interested in. While we have
> taken an example of a LAG as a bundle there is really nothing that
> precludes the possibility of that bundle being a composite link comprising
> of MPLS tunnels or something else. In that case the "link" could be an MPLS
> tunnel.
>
> Yes, we have some text that's specific to IEEE 802.1ax and LACP, but the
> idea can be generalized to work for other bundles that have separate
> component links. The draft specifically talks about IEEE 802.1ax and LACP
> since that's what our customers have been specifically asking us to fix.
>
> Cheers, Manav
>
> >
> > --
> > Toms.
> >

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 26 Feb 2012 08:13:17 +0200

Dear Greg & Manav,
I concur with Greg.
if the "link? Is a P2P LSP carrying IP, Ethernet encapsulation would not be preserved.

It could be an Ethernet PW, but in this case you would not have to worry about IP TTL.

And, what is IMHO much more important, you would probably use Bfd for the LSP or BFD in VCCV for the PW and not a much more complicated microiBFD session.

i'd like to reiterate my statement that the primary use case for micro-BFD sessions is  the situation where nativr lin failure indicatuons are not available. Making these sessions into a kind of theSwiss army knife is not justified IMHO.

Regards,
Sasha   
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Greg Mirsky [[email-masked]]
Sent: Friday, February 24, 2012 2:07 AM
To: Bhatia, Manav (Manav)
Cc: [email-masked]
Subject: Re: TTL of micro BFD packets?

Dear Manav,
you've brought interesting scneario in your example of composite that has MPLS LSP as member link:
"In that case the "link" could be an MPLS tunnel."
In this case, would use of multicast IP address for multi-BFD and 127/8 for BFD with IP/UDP encapsulation over the same MPLS LSP be slightly confusing?

Regards,
Greg

On Wed, Feb 22, 2012 at 5:32 PM, Bhatia, Manav (Manav) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tom,

Should be the latter.

Cheers, Manav

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.