Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

From: Santosh P K <[email-masked]>
Date: Thu, 20 Nov 2014 11:33:22 +0000

Hello All,

    In IETF-91 I have presented open items. Below are the last few things we need to close on.

1.       Active tail.

As discussed earlier, is this required in base draft? I spoke to all implementers  and no one has active tail implemented yet. To push it for RFC we need implementation so can we go ahead and move it to appendix or may be new document?

2.       Demultiplexing and UDP port number.

It makes more sense to have a separate draft for this. Please let me know if that is ok? If it benefits to have it in base draft itself then we can have more sections for demux and port number to be used.

3.       Echo mode supported?

Echo mode does not fit in P2MP BFD. We can say it is not supported. Does anyone see use of echo BFD in P2MP BFD?

4.       Increase interval?

Draft suggest not to use POLL sequence and suggests to increase multiplier first and then interval. If we have hardware implementation and don't want to check complete packet every time received then change in packet may be indicated with

POLL bit set. Since this is one to many mapping we can't have a complete POLL sequence and hence we need to suppress FINAL. Should we be going with POLL and suppress FINAL by setting desired RX interval set to 0? Please suggest any better idea.

5.       bfd.ReportTailDown

Draft suggests that head direct tails to send down notification. How will head direct tail about failure notification to be sent or not? Is this driven by configuration? At least the  section 4.4.1 says so. It could also be communicated to

received out of band?

This should be out of scope of this document as we can't direct tails with in BFD packet. Any comments?

6.       How packets get absorbed on tails?

Few implementers use UDP port number to absorb BFD packet on tails. It would be good to clarify about this in draft. Do we see any other way of absorbing packet on tail?

7.       Security consideration?

No suggestions yet.

Thanks

Santosh P K

> -----Original Message-----

> From: Nobo Akiya (nobo) [mailto:[email-masked]]

> Sent: Wednesday, October 22, 2014 3:09 AM

> To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas; [email-masked];

> Mingui Zhang

> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

> [With Chair Hat On]

> WG,

> I'd imagine many are busy ... being the last week before the cut-off and all ...

> But it'll be very helpful if you can chime in to help Santosh to take BFD

> multipoint further.

> [With Chair Hat Off]

> Hi Santosh,

> > -----Original Message-----

> > From: Santosh P K [mailto:[email-masked]]

> > Sent: Saturday, October 18, 2014 9:34 AM

> > To: Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey Haas; rtg-

> > [email-masked]<mailto:[email-masked]>; Mingui Zhang

> > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

> > Hello Nobo,

> >    Thanks again for your comments on this. Please see my comments.

> > > (a) unicast DOWN notification from leaves.

> > > (b) multicast Poll of leaves.

> > > (c) unicast Poll of leaves.

> > > If we want to keep the in-band mechanism and remove out-of-band

> > mechanism, then preserve (a) and (b) but remove (c). And that would be

> > my preference.

> > > Mingui, for your "TRILL Resilient Distribution Trees", do you see

> > > the need

> > for all [a-c] or just subsets?

> > Does (a) alone not enough?

> Personally I think there's a value in leaving the option for the head to do in-

> band polling of leaves. In other words, if down notification from a leaf to the

> head, then there is no way for the head to find out that leaf is no longer

> receiving.

> > Want to know if there are any application which wants to track tail

> > proactively? If so we can keep both (a) and (b).

> More comments from the WG will be very helpful. So far ...

> - Mingui brought up "TRILL Resilient Distribution Trees".

> - I brought up P2MP-TE Path Protection, which I think both (a) and (b) will be

> useful.

> > > Demux procedures is one, UDP port is the other one (i.e. it is not

> > > specified

> > in this document).

> > Yes, UDP port is not specified in the document. We can add this info

> > in base document itself? Every on ok with this? Any suggestions?

> Demux procedures and UDP ports should go into the same document.

> So it's either:

> (a) put everything in draft-ietf-bfd-multipoint.

> Or

> (b) spin off draft-ietf-bfd-multipoint-<dataplane> document per data plane.

> Thanks!

> -Nobo

> > Thanks

> > Santosh P K

> > -----Original Message-----

> > From: Nobo Akiya (nobo) [mailto:[email-masked]]

> > Sent: Wednesday, October 15, 2014 4:04 AM

> > To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas;

> > [email-masked]<mailto:[email-masked]>; Mingui Zhang

> > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

> > [With Chair Hat Off]

> > Hi Santosh,

> > Thank you for leading this effort!

> > Hopefully others can provide their comments to help close of last

> > remaining points for the BFD multipoint document.

> > Please see my comments in-line.

> > > -----Original Message-----

> > > From: Santosh P K [mailto:[email-masked]]

> > > Sent: Tuesday, October 14, 2014 7:21 AM

> > > To: Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey Haas; rtg-

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

> > > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

> > > Hello All,

> > >    Sorry for delay. I am trying to elaborate what I meant by "active tail".

> > > Please also comment on other two items that I have listed below

> > > which were raised by Prasad and Nobo in earlier discussions.

> > > Active tail:

> > > ------------

> > > As per discussion with implementers it looks like we don't see any

> > > use case scenario for head tracking tail. Currently there are

> > > multiple options given in draft for head to track tail.

> > >      1.  Unreliable Head Notification as per section 6.2

> > >                      When tail detect timer expires it sends DOWN BFD packet to

> > head on

> > > reverse unicast path.

> > >      2. Semi-reliable Head Notification and Tail Solicitation as per

> > > section

> > > 6.3

> > >                      A multipoint POLL with a combination of reverse unicast

> > path FINAL

> > > will help head to know if tail has lost communication with head.

> > >      3. Reliable Head Notification as per section 6.4

> > >                      A combination of multipoint POLL and unicast POLL will be

> > used by

> > > head to detect tail going down. Tail will make use of reverse

> > > unicast path to send FINAL packet to head.

> > One important characteristics is that:

> > (1) allows the head to be notified of _in-band_ failure by leaves.

> > (2) allows the head to poll leaves through _in-band_ packets.

> > (3) allows the head to poll leaves through _out-of-band_ unicast packets.

> > Going back to what Wim wrote (thanks for the comment Wim!):

> > [snip]

> > > In certain environment the tracking of the tails is happening by

> > > other

> > means.

> > > Example is Multicast VPN using MP-BGP.

> > [snip]

> > True, in the scenario described, (3) adds very minimal value beyond

> > running multi-hop BFD session between BGP peers.

> > On the other hand (1) and (2) are in-band, and can detect failures

> > that other sessions like multi-hop BFD sessions cannot. It does look

> > useful with technologies such as P2MP-TE where:

> > - leaves are constant

> > - has path-protection mechanism

> > > We have below options:

> > >      1. Go with simple "No Head Notification" as per section 6.1 in base

> > > draft and move rest of the sections to Appendix or move to separate

> > draft?

> > > In this case On MultipointHead bfd.ReportTailDown

> > >           will be set to 0 and we might not even need MultipointClient

> > > as we are not going to receive any packets from tail. bfd.SilentTail

> > > will be set to 1 on MultipointTail

> > >      2. Another option is to just keep "Unreliable Head Notification" as

> > > per section 6.2 and move/remove rest of mechanism through which

> > > Multipoint head can detect tail going down.

> > >           Meaning we need to move/remove Multicast POLL and unicast

> > POLL

> > > from MultipointHead.

> > Another way to look at this is that:

> > (a) unicast DOWN notification from leaves.

> > (b) multicast Poll of leaves.

> > (c) unicast Poll of leaves.

> > If we want to keep the in-band mechanism and remove out-of-band

> > mechanism, then preserve (a) and (b) but remove (c). And that would be

> > my preference.

> > Mingui, for your "TRILL Resilient Distribution Trees", do you see the

> > need for all [a-c] or just subsets?

> > >      3. Jeff suggested that we move these sections to new draft with

> > > experimental status.

> > >      4.  Any other options? Please suggest.

> > > Along with this I am also seeking comments on below two points.

> > > Demux:

> > > ---------

> > > This was brought up by Prasad in context of EVPN BFD draft that as

> > > per section 4.7 of this draft say

> > >      " The minimum amount of a priori information required both on the

> > > head

> > >          and tails is the binding to the multipoint path over which BFD

> > > is running."

> > > Above text is brief and draft is AF agnostic. Do we need to make

> > > text of Sec

> > > 4.7 and related sections more explicit? For example in case of EVPN

> > > tail nodes may use the P2MP label as the session demux key. Do we

> > > want to elaborate demux in base draft or it should be outside the

> > > scope of this document?

> > Demux procedures is one, UDP port is the other one (i.e. it is not

> > specified in this document).

> > We need to either:

> > - Add details in this document, or

> > - Consider this document as multipoint base document, and roll out

> > micro- documents describing demux/UDP-port details for various data

> planes.

> > Either will work, but the details are required somewhere to interoperate.

> > > Security consideration:

> > > ----------------------------

> > > As per Nobo's comment on this draft long back.  We need to add some

> > > suggestion in security consideration. Mainly because MultipointTail

> > > session can be created dynamically.

> > > Snippet from Nobo's mail.

> > > "MultipointTail sessions are dynamically created. If I had a way of

> > > getting around GTSM & Authentication (or lack of) and was aware of a

> > > source address that will pass the "check", then I could DoS this

> > > system with range of My Discriminator values to leaves, which will

> > > cause many instances of MultipointTail sessions to get created.

> > > Draft does say [create or discard] choice is outside the scope (in 4.16.2).

> > > But given the dynamic nature of session creation, it would be

> > > beneficial to highlight this point and provide suggestions in the

> > > "Security

> > Consideration"."

> > > Any suggestion on this?

> > > Jeff and Nobo have already raised some concerns here. We might have

> > > to see how PIM is doing it today.

> > Right it would be a good idea how other multipoint/multicast protocols

> > have addressed this.

> > Thanks!

> > -Nobo

> > > Thanks

> > > Santosh P K

> > > -----Original Message-----

> > > From: Nobo Akiya (nobo) [mailto:[email-masked]]

> > > Sent: Friday, October 10, 2014 8:18 PM

> > > To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas;

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

> > > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

> > > Santosh,

> > > It will helpful to clarify exactly what you mean by "active tail".

> > > - Do you intend to keep tail reporting of the failure

> > > (bfd.ReportTailDown=1)?

> > > - Is it just unicast poll from head that is being questioned for removal?

> > > Knowing exactly what aspect is being questioned for removal may

> > > provide a better base for good discussions.

> > > Thanks!

> > > -Nobo

> > > > -----Original Message-----

> > > > From: Santosh P K [mailto:[email-masked]]

> > > > Sent: Thursday, October 09, 2014 10:39 PM

> > > > To: Henderickx, Wim (Wim); Nobo Akiya (nobo); Jeffrey Haas; rtg-

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

> > > > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

> > > > Thanks Hendreickx for your reply.

> > > > -----Original Message-----

> > > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-

> > > > lucent.com]

> > > > Sent: Friday, October 10, 2014 12:29 AM

> > > > To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; [email-masked]<mailto:[email-masked]>

> > > > Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt

> > > > In certain environment the tracking of the tails is happening by

> > > > other

> > > means.

> > > > Example is Multicast VPN using MP-BGP.

> > > > On 09/10/14 17:38, "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>> wrote:

> > > > >[With Chair Hat On]

> > > > >Dear WG,

> > > > >The topic of keeping or removing the active tail from

> > > > >draft-ietf-bfd-multipoint is one of the last couple of topics

> > > > >that we, as a WG, need to resolve for this document.

> > > > >Whether or not we keep or remove the active tail, leaves will be

> > > > >able to detect the failure of the multicast tree, which allows

> > > > >protections such as live-live.

> > > > >What is essentially different:

> > > > >Keeping the active tail - Allows ingress/root to keep track of leaves.

> > > > >Removing the active tail - Ingress/root will not be able to keep

> > > > >track of leaves.

> > > > >If there's any requirements for the ingress/root to trigger some

> > > > >protections, then active tail becomes a requirement. If there is

> > > > >no such requirements, then the active tail is an unnecessary

> > > > >portion of this document.

> > > > >It'll be beneficial to hear your thoughts/comments to help gauge

> > > > >where we are on this matter as a WG.

> > > > >Comments/thoughts?

> > > > >Thanks!

> > > > >-Nobo

> > > > >> -----Original Message-----

> > > > >> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of

> > > > >> Santosh P K

> > > > >> Sent: Monday, October 06, 2014 9:27 AM

> > > > >> To: Santosh P K; Jeffrey Haas; [email-masked]<mailto:[email-masked]>

> > > > >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

> > > > >> Sorry for typo in my precious mail  "active tale" it is "active tail".

> > > > >> Thanks

> > > > >> Santosh P K

> > > > >> -----Original Message-----

> > > > >> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of

> > > > >> Santosh P K

> > > > >> Sent: Monday, October 06, 2014 6:22 PM

> > > > >> To: Jeffrey Haas; [email-masked]<mailto:[email-masked]>

> > > > >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

> > > > >> Hello All,

> > > > >>    I am seeking comments on active tale section of this document.

> > > > >>I spoke to  few implementers and found that no one really finds

> > > > >>use case for active tale.

> > > > >> Does anyone on this forum feel that we might need active tale?

> > > > >>If there are  no uses cases then we can move active tale section

> > > > >>to appendix? We would  like to make all the changes before IETF

> > > > >>91 and push this for RFC. Any  suggestions?

> > > > >> Thanks

> > > > >> Santosh P K

> > > > >> -----Original Message-----

> > > > >> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of

> > > > >>Jeffrey Haas

> > > > >> Sent: Tuesday, August 19, 2014 7:38 PM

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

> > > > >> Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt

> > > > >> Note that this consists mostly of a re-publish with Santosh as

> > > > >>the new editor.

> > > > >> (And moving from .nroff to .xml.)

> > > > >> In the next few weeks, Santosh will be working with known

> > > > >>implementors to  edit the document to match implementation.

> > > > >>Ideally these edits will be  complete prior to the next IETF

> > > > >>session in Honolulu.  This will put us a bit  past our original

> > > > >>milestone for publication, but still much better on track  than

> > > > >>many of our previous documents.

> > > > >> -- Jeff

> > > > >> On Mon, Aug 18, 2014 at 05:55:37PM -0700,

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

> > > > >>wrote:

> > > > >> > A New Internet-Draft is available from the on-line

> > > > >> > Internet-Drafts

> > > > >> directories.

> > > > >> >  This draft is a work item of the Bidirectional Forwarding

> > > > >> > Detection

> > > > >> Working Group of the IETF.

> > > > >> >         Title           : BFD for Multipoint Networks

> > > > >> >         Authors         : Dave Katz

> > > > >> >                           Dave Ward

> > > > >> >                           Santosh Pallagatti

> > > > >> >        Filename        : draft-ietf-bfd-multipoint-04.txt

> > > > >> >        Pages           : 27

> > > > >> >        Date            : 2014-08-12

> > > > >> > Abstract:

> > > > >> >    This document describes extensions to the Bidirectional

> > Forwarding

> > > > >> >    Detection (BFD) protocol for its use in multipoint and multicast

> > > > >> >    networks.  Comments on this draft should be directed to rtg-

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

> > > > >> > The IETF datatracker status page for this draft is:

> > > > >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/

> > > > >> > There's also a htmlized version available at:

> > > > >> > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04

> > > > >> > A diff from the previous version is available at:

> > > > >> > http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-04

> > > > >> > Please note that it may take a couple of minutes from the

> > > > >> > time of submission until the htmlized version and diff are

> > > > >> > available at

> > > > >> tools.ietf.org.

> > > > >> > Internet-Drafts are also available by anonymous FTP at:

> > > > >> > ftp://ftp.ietf.org/internet-drafts/

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 21 Nov 2014 12:12:08 +0000

In-line

From: Santosh P K <[email-masked]<mailto:[email-masked]>>
Date: Thursday 20 November 2014 03:33
To: "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>>, Wim Henderickx <[email-masked]<mailto:[email-masked]>>, Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Mingui Zhang <[email-masked]<mailto:[email-masked]>>
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

Hello All,

1.       Active tail.

WH> I would propose we do the active tail in appendix or a separate draft

WH> it should be in the draft I believe

3.       Echo mode supported?

WH> I don’t see a use case for this so far

4.       Increase interval?

Draft suggest not to use POLL sequence and suggests to increase multiplier first and then interval. If we have hardware implementation and don’t want to check complete packet every time received then change in packet may be indicated with

5.       bfd.ReportTailDown

received out of band?

No suggestions yet.

Thanks

Santosh P K

> To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas; [email-masked]<mailto:[email-masked]>;

---

From: Santosh P K <[email-masked]>
Date: Sat, 22 Nov 2014 09:04:12 +0000

Hello Wim,
   Thanks a lot for your inputs on this. This really helps to take this draft forward. 

>>1.	Demultiplexing and UDP port number.

Looks like TRILL will not have UDP and hence it will need different mechanism for demux. I had chat with Mingui and below is mail from him which explain how they absorb packet on tails. 

[Snip]
Since TRILL does not use UDP, no port number will be used. Instead, TRILL creates a data plane channel for BFD. 
A new RBridge-Channel Ethertype 0x8946 has been assigned for this kind of channel (http://tools.ietf.org/html/rfc7178#section-7.2). And RBridge Channel protocol numbers 0x002 and 0x003 are created for BFD Control and BFD Echo respectively (http://tools.ietf.org/html/rfc7175#section-8).
[Snip]

Now for P2MP LSP's we can still UDP to absorb packet on tails (already there are implementations doing this) and for TRILLs we can use RBridge channel. I somehow feel too much of info will go in to base draft if we add demux in to base draft. I am still open  for others opinion :). 

Thanks
Santosh P K

From: Henderickx, Wim (Wim) [mailto:[email-masked]] 
Sent: Friday, November 21, 2014 5:42 PM
To: Santosh P K; Nobo Akiya (nobo); Jeffrey Haas; [email-masked]; Mingui Zhang
Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt

In-line

From: Santosh P K <[email-masked]>
Date: Thursday 20 November 2014 03:33
To: "Nobo Akiya (nobo)" <[email-masked]>, Wim Henderickx <[email-masked]>, Jeffrey Haas <[email-masked]>, "[email-masked]" <[email-masked]>, Mingui Zhang <[email-masked]>
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

Hello All,
 
1. Active tail.

        
3. Echo mode supported?

WH> I don't see a use case for this so far
        
4. Increase interval?
    
5. bfd.ReportTailDown

 

Thanks
Santosh P K 

> > [email-masked]; Mingui Zhang
> > [email-masked]; Mingui Zhang
> > > [email-masked]
> > > [email-masked]
> > > > [email-masked]
> > > > To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; [email-masked]
> > > > On 09/10/14 17:38, "Nobo Akiya (nobo)" <[email-masked]> wrote:
> > > >
> > > > >[With Chair Hat On]
> > > > >
> > > > >Dear WG,
> > > > >
> > > > >> To: Santosh P K; Jeffrey Haas; [email-masked]
> > > > >> To: Jeffrey Haas; [email-masked]
> > > > >> To: [email-masked]
> > > > >>[email-masked]
> > > > >> >    [email-masked].

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 23 Nov 2014 01:57:45 +0000

Hi Santosh, Wim,

> Sent: Friday, November 21, 2014 7:12 AM
> To: "Nobo Akiya (nobo)" <[email-masked]>, Wim Henderickx
> <[email-masked]>, Jeffrey Haas <[email-masked]>, "rtg-
> [email-masked]" <[email-masked]>, Mingui Zhang
> <[email-masked]>
>        As discussed earlier, is this required in base draft? I spoke to all
> implementers  and no one has active tail implemented yet. To push it for
> RFC we need implementation so can we go ahead and move it to appendix
> or may be new document?
> 

[NOBO] Wim, can you clarify which you mean?

A) You propose reliable head notification to be moved.
B) You propose semi-reliable and reliable head notifications to be moved.
C) You propose unreliable, semi-reliable and reliable head notifications to be moved.

You can find the description of each notifications in page 4 of http://www.ietf.org/proceedings/91/slides/slides-91-bfd-0.pptx.

My preference will be (A).

>        It makes more sense to have a separate draft for this. Please let me
> know if that is ok? If it benefits to have it in base draft itself then we can
> have more sections for demux and port number to be used.
> 

[NOBO] So ...

Option 1 is to describe the demux codepoint & procedures in the bfd-multipoint document.
Option 2 is to describe the demux codepoint & procedures in separate data plane document(s).

It sounds like Santosh is preferring Option 2 while Wim is preferring option 1.

Perhaps there's an Option 3.

The bfd-multipoint document to describe one or two basic data plane demux codepoint & procedures cleanly in a separate section (ex: IP and MPLS). Other data planes documents (ex: TRILL) can update the demux section of the bfd-multipoint document. Just thinking out loud ...

> 
> 3.       Echo mode supported?
>        Echo mode does not fit in P2MP BFD. We can say it is not supported.
> Does anyone see use of echo BFD in P2MP BFD?
> 

[NOBO] Agree, I see no value in the multipoint document considering the echo inside the scope.

> 
> 4.       Increase interval?
> Draft suggest not to use POLL sequence and suggests to increase multiplier
> first and then interval. If we have hardware implementation and don't want
> to check complete packet every time received then change in packet may be
> indicated with
> POLL bit set. Since this is one to many mapping we can't have a complete
> POLL sequence and hence we need to suppress FINAL. Should we be going
> with POLL and suppress FINAL by setting desired RX interval set to 0? Please
> suggest any better idea.

[NOBO] If we keep the semi-reliable head notification, then I would have expected P/F (from head to tails) to just work?

> 
> 5.       bfd.ReportTailDown
>        Draft suggests that head direct tails to send down notification. How will
> head direct tail about failure notification to be sent or not? Is this driven by
> configuration? At least the  section 4.4.1 says so. It could also be
> communicated to
>        received out of band?
> 

[NOBO] This is something which can be configured, thus out of scope [for now] should be fine. One reason that I have been pushing to keep semi-reliable head notification is that it can catch instances of odd cases like tails not having consistent configurations ... i.e, only some tails notify and some don't. Head doing the in-band polling can discover the available tails, becomes more of a fail-safe mechanism.

> Few implementers use UDP port number to absorb BFD packet on tails. It
> would be good to clarify about this in draft. Do we see any other way of
> absorbing packet on tail?

[NOBO]

For IP:
- UDP port.

For MPLS:
- 127/8 and UDP port.
- UHP does not require bootstrapping but PHP will require bootstrapping.

Thanks!

-Nobo, as individual contributor

---

From: Santosh P K <[email-masked]>
Date: Sun, 23 Nov 2014 02:35:25 +0000

Hello Nobo,
    Thanks for your reply. Please see inline.

> > 1.       Active tail.
> >        As discussed earlier, is this required in base draft? I spoke
> > to all implementers  and no one has active tail implemented yet. To
> > push it for RFC we need implementation so can we go ahead and move it
> > to appendix or may be new document?
> >
> > WH> I would propose we do the active tail in appendix or a separate
> > WH> draft
> 
> You can find the description of each notifications in page 4 of
> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-0.pptx.
> 

Moving reliable head notification to appendix or new document you mean :) ? 

> >        It makes more sense to have a separate draft for this. Please
> > let me know if that is ok? If it benefits to have it in base draft
> > itself then we can have more sections for demux and port number to be
> used.
> >
> The bfd-multipoint document to describe one or two basic data plane demux
> codepoint & procedures cleanly in a separate section (ex: IP and MPLS).
> Other data planes documents (ex: TRILL) can update the demux section of
> the bfd-multipoint document. Just thinking out loud ...
> 

Currently in document it tries to explain how to demux for IP only in section 4.8. We can add more text for clarity. 
I am ok with option 1 where all procedure dumped in single document but I am worried that in future some other data plane wants a new way of demultiplexing then we may need to change the base document again? 

> [NOBO] Agree, I see no value in the multipoint document considering the

Thanks.

> >
> > 4.       Increase interval?
> > Draft suggest not to use POLL sequence and suggests to increase
> > multiplier first and then interval. If we have hardware implementation
> > and don't want to check complete packet every time received then
> > change in packet may be indicated with POLL bit set. Since this is one
> > to many mapping we can't have a complete POLL sequence and hence we
> > need to suppress FINAL. Should we be going with POLL and suppress
> > FINAL by setting desired RX interval set to 0? Please suggest any
> > better idea.
> 
> [NOBO] If we keep the semi-reliable head notification, then I would have
> expected P/F (from head to tails) to just work?

With semi-reliable head notification you want to have complete POLL sequence for  interval negotiation? One to many mapping will have issues with complete POLL sequence. Can you elaborate how this will help? 

> > 5.       bfd.ReportTailDown
> >        Draft suggests that head direct tails to send down
> > notification. How will head direct tail about failure notification to
> > be sent or not? Is this driven by configuration? At least the  section
> > 4.4.1 says so. It could also be communicated to
> >        received out of band?
> >
> [NOBO] This is something which can be configured, thus out of scope [for
> now] should be fine. One reason that I have been pushing to keep semi-
> reliable head notification is that it can catch instances of odd cases like tails
> not having consistent configurations ... i.e, only some tails notify and some
> don't. Head doing the in-band polling can discover the available tails,
> becomes more of a fail-safe mechanism.

Agreed. It makes sense to have semi-reliable here. 

> > would be good to clarify about this in draft. Do we see any other way
> > of absorbing packet on tail?
> 
> [NOBO]
> 
> For IP:
> - UDP port.
> 
> For MPLS:
> - 127/8 and UDP port.

For TILLS:
A new data channel. 

Thanks
Santosh P K 

> > > I'd imagine many are busy ... being the last week before the cut-off
> > > and
> > all ...
> > >
> > > But it'll be very helpful if you can chime in to help Santosh to
> > > take BFD multipoint further.
> > >
> > > [With Chair Hat Off]
> > >
> > > Hi Santosh,
> > >
> > > > mechanism, then preserve (a) and (b) but remove (c). And that
> > > > would be my preference.
> > > > > Mingui, for your "TRILL Resilient Distribution Trees", do you
> > > > > see the need
> > > Personally I think there's a value in leaving the option for the
> > > head to do
> > in-
> > > band polling of leaves. In other words, if down notification from a
> > > leaf to
> > the
> > > head, then there is no way for the head to find out that leaf is no
> > > longer receiving.
> > >
> > > > Want to know if there are any application which wants to track
> > > > tail proactively? If so we can keep both (a) and (b).
> > >
> > > - I brought up P2MP-TE Path Protection, which I think both (a) and
> > > (b) will
> > be
> > > useful.
> > >
> > > >
> > > > > Demux procedures is one, UDP port is the other one (i.e. it is
> > > > > not specified
> > > > in this document).
> > > >
> > > > Yes, UDP port is not specified in the document. We can add this
> > > > info in base document itself? Every on ok with this? Any suggestions?
> > >
> > > > > As per discussion with implementers it looks like we don't see
> > > > > any use case scenario for head tracking tail. Currently there
> > > > > are multiple options given in draft for head to track tail.
> > > > >      2. Semi-reliable Head Notification and Tail Solicitation as
> > > > > per section
> > > > > 6.3
> > > > True, in the scenario described, (3) adds very minimal value
> > > > beyond running multi-hop BFD session between BGP peers.
> > > >
> > > > that other sessions like multi-hop BFD sessions cannot. It does
> > > > look useful with technologies such as P2MP-TE where:
> > > >
> > > > - leaves are constant
> > > > >      1. Go with simple "No Head Notification" as per section 6.1
> > > > > in base draft and move rest of the sections to Appendix or move
> > > > > to separate
> > > > draft?
> > > > >           will be set to 0 and we might not even need
> > > > > MultipointClient as we are not going to receive any packets from
> > > > > tail. bfd.SilentTail will be set to 1 on MultipointTail
> > > > >      2. Another option is to just keep "Unreliable Head
> > > > > Notification" as per section 6.2 and move/remove rest of
> > > > > mechanism through which Multipoint head can detect tail going
> down.
> > > > mechanism, then preserve (a) and (b) but remove (c). And that
> > > > would be my preference.
> > > >
> > > > the need for all [a-c] or just subsets?
> > > >
> > > > >      3. Jeff suggested that we move these sections to new draft
> > > > > with experimental status.
> > > > > This was brought up by Prasad in context of EVPN BFD draft that
> > > > > as per section 4.7 of this draft say
> > > > >
> > > > >      " The minimum amount of a priori information required both
> > > > > on the head
> > > > >          and tails is the binding to the multipoint path over
> > > > > which BFD is running."
> > > > >
> > > > > 4.7 and related sections more explicit? For example in case of
> > > > > EVPN tail nodes may use the P2MP label as the session demux key.
> > > > > Do we want to elaborate demux in base draft or it should be
> > > > > outside the scope of this document?
> > > >
> > > > > As per Nobo's comment on this draft long back.  We need to add
> > > > > some suggestion in security consideration. Mainly because
> > > > > MultipointTail session can be created dynamically.
> > > > >
> > > > > "MultipointTail sessions are dynamically created. If I had a way
> > > > > of getting around GTSM & Authentication (or lack of) and was
> > > > > aware of a source address that will pass the "check", then I
> > > > > could DoS this system with range of My Discriminator values to
> > > > > leaves, which will cause many instances of MultipointTail sessions to
> get created.
> > > > > beneficial to highlight this point and provide suggestions in
> > > > > the "Security
> > > > Consideration"."
> > > > >
> > > > > Any suggestion on this?
> > > > >
> > > > > Jeff and Nobo have already raised some concerns here. We might
> > > > > have to see how PIM is doing it today.
> > > >
> > > > Right it would be a good idea how other multipoint/multicast
> > > > protocols have addressed this.
> > > >
> > > > Thanks!
> > > >
> > > > -Nobo
> > > >
> > > > >
> > > > >
> > > > > Thanks
> > > > > Santosh P K
> > > > >
> > > > >
> > > > >
> > > > > > To: Henderickx, Wim (Wim); Nobo Akiya (nobo); Jeffrey Haas;
> > > > > > rtg- [email-masked]
> > > > > > In certain environment the tracking of the tails is happening
> > > > > > by other
> > > > > means.
> > > > > > >Whether or not we keep or remove the active tail, leaves will
> > > > > > >be able to detect the failure of the multicast tree, which
> > > > > > >allows protections such as live-live.
> > > > > > >
> > > > > > >Removing the active tail - Ingress/root will not be able to
> > > > > > >keep track of leaves.
> > > > > > >
> > > > > > >If there's any requirements for the ingress/root to trigger
> > > > > > >some protections, then active tail becomes a requirement. If
> > > > > > >there is no such requirements, then the active tail is an
> > > > > > >unnecessary portion of this document.
> > > > > > >
> > > > > > >It'll be beneficial to hear your thoughts/comments to help
> > > > > > >gauge where we are on this matter as a WG.
> > > > > > >
> > > > > > >Comments/thoughts?
> > > > > > >
> > > > > > >Thanks!
> > > > > > >
> > > > > > >-Nobo
> > > > > > >
> > > > > > >> From: Rtg-bfd [mailto:[email-masked]] On Behalf
> > > > > > >> Of Santosh P K
> > > > > > >> From: Rtg-bfd [mailto:[email-masked]] On Behalf
> > > > > > >> Of Santosh P K
> > > > > > >>I spoke to  few implementers and found that no one really
> > > > > > >>finds use case for active tale.
> > > > > > >>If there are  no uses cases then we can move active tale
> > > > > > >>section to appendix? We would  like to make all the changes
> > > > > > >>before IETF
> > > > > > >> From: Rtg-bfd [mailto:[email-masked]] On Behalf
> > > > > > >>Of Jeffrey Haas
> > > > > > >> Note that this consists mostly of a re-publish with Santosh
> > > > > > >>as the new editor.
> > > > > > >>session in Honolulu.  This will put us a bit  past our
> > > > > > >>original milestone for publication, but still much better on
> > > > > > >>track  than many of our previous documents.
> > > > > > >>
> > > > > > >> -- Jeff
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> >  This draft is a work item of the Bidirectional
> > > > > > >> >Forwarding  Detection
> > > > > > >> > time of submission until the htmlized version and diff
> > > > > > >> > are available at
> > > > > > >> tools.ietf.org.
> > > > > > >> >

---

From: Gregory Mirsky <[email-masked]>
Date: Sun, 23 Nov 2014 04:49:11 +0000

Hi Santosh, et. al,
I'm adding more in-line to the level of making the discussion untraceable. Look for GIM>> tags.

	Regards,
		Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P K
Sent: Saturday, November 22, 2014 6:35 PM
To: Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey Haas; [email-masked]; Mingui Zhang
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

Hello Nobo,

> > push it for RFC we need implementation so can we go ahead and move 
> > it to appendix or may be new document?
> >
Moving reliable head notification to appendix or new document you mean :) ? 
GIM>> My preference - C into the separate draft. And all related updates of state machine and new variables - go with it.

> The bfd-multipoint document to describe one or two basic data plane 
> demux codepoint & procedures cleanly in a separate section (ex: IP and MPLS).
> Other data planes documents (ex: TRILL) can update the demux section 
> of the bfd-multipoint document. Just thinking out loud ...
> 

Currently in document it tries to explain how to demux for IP only in section 4.8. We can add more text for clarity. 
I am ok with option 1 where all procedure dumped in single document but I am worried that in future some other data plane wants a new way of demultiplexing then we may need to change the base document again? 
GIM>> Option 1 does make sense to me. Other encapsulations, e.g. MPLS ACH, would have to write documents of their own.

> the echo inside the scope.

Thanks.
GIM>> Agree, no echo mode.

> > multiplier first and then interval. If we have hardware 
> > implementation and don't want to check complete packet every time 
> > received then change in packet may be indicated with POLL bit set. 
> > Since this is one to many mapping we can't have a complete POLL 
> > sequence and hence we need to suppress FINAL. Should we be going 
> > with POLL and suppress FINAL by setting desired RX interval set to 
> > 0? Please suggest any better idea.
> 
> [NOBO] If we keep the semi-reliable head notification, then I would 
> have expected P/F (from head to tails) to just work?

> > notification. How will head direct tail about failure notification 
> > to be sent or not? Is this driven by configuration? At least the  
> > section
> >        This should be out of scope of this document as we can't 
> > direct tails with in BFD packet. Any comments?
> 
> [NOBO] This is something which can be configured, thus out of scope 
> [for now] should be fine. One reason that I have been pushing to keep 
> semi- reliable head notification is that it can catch instances of odd 
> cases like tails not having consistent configurations ... i.e, only 
> some tails notify and some don't. Head doing the in-band polling can 
> discover the available tails, becomes more of a fail-safe mechanism.

GIM>> I think that I disagree on this. Configuration can be verified by other means. I consider the base of multi-point BFD as mechanism suitable for 1+1 protection switchover. Any type of tail monitoring, IMO, is optional and can be document of its own.

> > Few implementers use UDP port number to absorb BFD packet on tails. 
> > It would be good to clarify about this in draft. Do we see any other 
> > way of absorbing packet on tail?
> 
> [NOBO]
> 
> For IP:
> - UDP port.
> 
> For MPLS:
> - 127/8 and UDP port.

GIM>> Why would bootstrapping be required for multi-point BFD session in MPLS data plane with PHP if tail monitoring is not required? 
 
For TILLS:
A new data channel. 

Thanks
Santosh P K 

> > > I'd imagine many are busy ... being the last week before the 
> > > cut-off and
> > all ...
> > >
> > > band polling of leaves. In other words, if down notification from 
> > > a leaf to
> > the
> > > head, then there is no way for the head to find out that leaf is 
> > > no longer receiving.
> > >
> > > (b) spin off draft-ietf-bfd-multipoint-<dataplane> document per 
> > > data
> > plane.
> > >
> > > Thanks!
> > >
> > > -Nobo
> > >
> > > >
> > > >
> > > > Thanks
> > > > Santosh P K
> > > >
> > > >
> > > > Hopefully others can provide their comments to help close of 
> > > > last remaining points for the BFD multipoint document.
> > > >
> > > > > To: Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey Haas; 
> > > > > rtg- [email-masked]
> > > > > Please also comment on other two items that I have listed 
> > > > >below which were raised by Prasad and Nobo in earlier discussions.
> > > > >
> > > > > Active tail:
> > > > > ------------
> > > > >      2. Semi-reliable Head Notification and Tail Solicitation 
> > > > > as per section
> > > > > 6.3
> > > > On the other hand (1) and (2) are in-band, and can detect 
> > > > failures that other sessions like multi-hop BFD sessions cannot. 
> > > > It does look useful with technologies such as P2MP-TE where:
> > > >
> > > > - leaves are constant
> > > > >      1. Go with simple "No Head Notification" as per section 
> > > > > 6.1 in base draft and move rest of the sections to Appendix or 
> > > > > move to separate
> > > > draft?
> > > > > MultipointClient as we are not going to receive any packets 
> > > > > from tail. bfd.SilentTail will be set to 1 on MultipointTail
> > > > see the need for all [a-c] or just subsets?
> > > >
> > > > >      3. Jeff suggested that we move these sections to new 
> > > > > draft with experimental status.
> > > > > This was brought up by Prasad in context of EVPN BFD draft 
> > > > > that as per section 4.7 of this draft say
> > > > >
> > > > >      " The minimum amount of a priori information required 
> > > > > both on the head
> > > > > Above text is brief and draft is AF agnostic. Do we need to 
> > > > > make text of Sec
> > > > not specified in this document).
> > > >
> > > > We need to either:
> > > > > "MultipointTail sessions are dynamically created. If I had a 
> > > > > way of getting around GTSM & Authentication (or lack of) and 
> > > > > was aware of a source address that will pass the "check", then 
> > > > > I could DoS this system with range of My Discriminator values 
> > > > > to leaves, which will cause many instances of MultipointTail 
> > > > > sessions to
> get created.
> > > > > Draft does say [create or discard] choice is outside the scope 
> > > > > (in
> 4.16.2).
> > > > > Knowing exactly what aspect is being questioned for removal 
> > > > > may provide a better base for good discussions.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > -Nobo
> > > > >
> > > > > > In certain environment the tracking of the tails is 
> > > > > > happening by other
> > > > > means.
> > > > > > >draft-ietf-bfd-multipoint is one of the last couple of 
> > > > > > >topics that we, as a WG, need to resolve for this document.
> > > > > > >
> > > > > > >Whether or not we keep or remove the active tail, leaves 
> > > > > > >will be able to detect the failure of the multicast tree, 
> > > > > > >which allows protections such as live-live.
> > > > > > >
> > > > > > >Keeping the active tail - Allows ingress/root to keep track 
> > > > > > >of
> leaves.
> > > > > > >
> > > > > > >some protections, then active tail becomes a requirement. 
> > > > > > >If there is no such requirements, then the active tail is 
> > > > > > >an unnecessary portion of this document.
> > > > > > >
> > > > > > >>section to appendix? We would  like to make all the 
> > > > > > >>changes before IETF
> > > > > > >> Note that this consists mostly of a re-publish with 
> > > > > > >>Santosh as the new editor.
> > > > > > >>Ideally these edits will be  complete prior to the next 
> > > > > > >>IETF session in Honolulu.  This will put us a bit  past 
> > > > > > >>our original milestone for publication, but still much 
> > > > > > >>better on track  than many of our previous documents.
> > > > > > >>
> > > > > > >> -- Jeff
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipo
> > > > > > >> > in
> > > > > > >> > t/
> > > > > > >> >
> > > > > > >> > http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipo
> > > > > > >> > in
> > > > > > >> > t-04
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > Please note that it may take a couple of minutes from 
> > > > > > >> > the time of submission until the htmlized version and 
> > > > > > >> > diff are available at
> > > > > > >> tools.ietf.org.
> > > > > > >> >

---

From: Santosh P K <[email-masked]>
Date: Sun, 23 Nov 2014 05:29:30 +0000

Hello Greg,
      Thanks a lot of your comments. Please see inline. 

> GIM>> My preference - C into the separate draft. And all related updates of
> state machine and new variables - go with it.

Ok so we have

1. Moving reliable notification option (A) moving to separate document/appendix.  (Nobo's preference)
2. Moving unreliable, semi-reliable and reliable (C) to separate document/appendix. (Greg's preference) 

Wim you have any preference on this? 

> I am ok with option 1 where all procedure dumped in single document but I
> am worried that in future some other data plane wants a new way of
> demultiplexing then we may need to change the base document again?
> GIM>> Option 1 does make sense to me. Other encapsulations, e.g. MPLS
> ACH, would have to write documents of their own.

Ok so I think we are making progress on this. I understand that we need to do below. 

Keep base document with IP demux and MPLS demux. For any other (TRILLS, MPLS ACH) demux required come up with a new draft. 

> GIM>> Agree, no echo mode.

Thanks. We are converging on this point. 

> With semi-reliable head notification you want to have complete POLL
> sequence for  interval negotiation? One to many mapping will have issues
> with complete POLL sequence. Can you elaborate how this will help?
> 
> 
> > > 5.       bfd.ReportTailDown
> GIM>> I think that I disagree on this. Configuration can be verified by other
> means. I consider the base of multi-point BFD as mechanism suitable for 1+1
> protection switchover. Any type of tail monitoring, IMO, is optional and can
> be document of its own.

Hmmm so this means we need converge on below options for tail monitoring.

1. Moving reliable notification option (A) moving to separate document/appendix.  (Nobo's preference)
2. Moving unreliable, semi-reliable and reliable (C) to separate document/appendix. (Greg's preference)

> GIM>> Why would bootstrapping be required for multi-point BFD session in
> MPLS data plane with PHP if tail monitoring is not required?

In case of PHP tail will not know which how to associate BFD received packet to an LSP as all BFD packets will come with 127/8 address. This is why we need boot strapping with MPLS LSP ping. There was a draft for the same long time ago.

http://tools.ietf.org/html/draft-hc-mpls-mpoint-bfd-for-mpls-00

Thanks
Santosh P K

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Sun, 23 Nov 2014 10:15:26 +0000

In-line with WH>

On 23/11/14 06:29, "Santosh P K" <[email-masked]> wrote:

>> Moving reliable head notification to appendix or new document you mean
>>:)
>> ?
WH> I would prefer C a per Greg¹s suggestion
>> > It sounds like Santosh is preferring Option 2 while Wim is preferring
>>option
>> 1.
>> >
>> Currently in document it tries to explain how to demux for IP only in
>>section
>> 4.8. We can add more text for clarity.
>Keep base document with IP demux and MPLS demux. For any other (TRILLS,
>MPLS ACH) demux required come up with a new draft.
WH> I agree to make a separate doc on other demux schemes other than IP
and MPLS
>In case of PHP tail will not know which how to associate BFD received
>packet to an LSP as all BFD packets will come with 127/8 address. This is
>why we need boot strapping with MPLS LSP ping. There was a draft for the
>same long time ago.
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 24 Nov 2014 01:30:56 +0000

Hi Santosh,

> >> > > 1.       Active tail.
> >> > >        As discussed earlier, is this required in base draft? I
> >> > > spoke to all implementers  and no one has active tail implemented
> >> > > yet. To push it for RFC we need implementation so can we go ahead
> >> > > and move it to appendix or may be new document?
> >> > >
> >> > > WH> I would propose we do the active tail in appendix or a
> >> > > WH> separate draft
> >> >
> >1. Moving reliable notification option (A) moving to separate
> >document/appendix.  (Nobo's preference) 2. Moving unreliable,
> >semi-reliable and reliable (C) to separate document/appendix. (Greg's
> >preference)
> >

If the majority of the WG thinks we should go with (C), then I wouldn't oppose.

There is a benefit in progressing the portion that we all agree on, and revisit those questionable parts when there are stronger requirements.

Thanks!

-Nobo

---

From: Mingui Zhang <[email-masked]>
Date: Mon, 24 Nov 2014 03:36:57 +0000

Hi Santosh,

<snip>
>MPLS ACH) demux required come up with a new draft.
<snip>

I think this is reasonable.

Thanks,
Mingui

>Sent: Sunday, November 23, 2014 1:30 PM
>To: Gregory Mirsky; Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey Haas;
>In case of PHP tail will not know which how to associate BFD received packet to
>an LSP as all BFD packets will come with 127/8 address. This is why we need
>boot strapping with MPLS LSP ping. There was a draft for the same long time
>ago.
>

---

From: Santosh P K <[email-masked]>
Date: Mon, 24 Nov 2014 06:03:45 +0000

Thanks Nobo.

> Sent: Monday, November 24, 2014 7:01 AM
> To: Henderickx, Wim (Wim); Santosh P K; Gregory Mirsky; Jeffrey Haas; rtg-
> > >> > > spoke to all implementers  and no one has active tail
> > >> > > implemented yet. To push it for RFC we need implementation so
> > >> > > can we go ahead and move it to appendix or may be new
> document?
> > >> > >
> > >> > B) You propose semi-reliable and reliable head notifications to
> > >> > be
> > >>moved.
> There is a benefit in progressing the portion that we all agree on, and revisit
> those questionable parts when there are stronger requirements.
> 
> Thanks!
> 
> -Nobo

---

From: Santosh P K <[email-masked]>
Date: Mon, 24 Nov 2014 06:04:08 +0000

Thanks Wim for clarifying. 

Thanks
Santosh P K 

> Sent: Sunday, November 23, 2014 3:45 PM
> To: Santosh P K; Gregory Mirsky; Nobo Akiya (nobo); Jeffrey Haas; rtg-
> >> > >        It makes more sense to have a separate draft for this.
> >> > > Please let me know if that is ok? If it benefits to have it in
> >> > > base draft itself then we can have more sections for demux and
> >> > > port number to be
> >> > used.
> >> > >
> >> > Option 1 is to describe the demux codepoint & procedures in the
> >> > bfd- multipoint document.
> >> > demux codepoint & procedures cleanly in a separate section (ex: IP
> >> > and
> >> MPLS).
> >> > Other data planes documents (ex: TRILL) can update the demux
> >> > section of the bfd-multipoint document. Just thinking out loud ...
> >> >
> >>
> >>section  4.8. We can add more text for clarity.
> >> I am ok with option 1 where all procedure dumped in single document
> >>but I  am worried that in future some other data plane wants a new way
> >>of  demultiplexing then we may need to change the base document
> again?
> >> > > with POLL and suppress FINAL by setting desired RX interval set
> >> > > to 0? Please suggest any better idea.
> >> >
> >> sequence for  interval negotiation? One to many mapping will have
> >> issues with complete POLL sequence. Can you elaborate how this will
> help?
> >>
> >>
> >> > > 5.       bfd.ReportTailDown
> >> > > notification. How will head direct tail about failure
> >> > > notification to be sent or not? Is this driven by configuration?
> >> > > At least the section
> >> > semi- reliable head notification is that it can catch instances of
> >> > odd cases like tails not having consistent configurations ... i.e,
> >> > only some tails notify and some don't. Head doing the in-band
> >> > polling can discover the available tails, becomes more of a fail-safe
> mechanism.
> >>
> >> GIM>> I think that I disagree on this. Configuration can be verified
> >> GIM>> by
> >>other
> >> means. I consider the base of multi-point BFD as mechanism suitable
> >>for
> >>1+1
> >> protection switchover. Any type of tail monitoring, IMO, is optional
> >>and can  be document of its own.
> >
> >> > > It would be good to clarify about this in draft. Do we see any
> >> > > other way of absorbing packet on tail?
> >> >
> >> > [NOBO]
> >> >
> >> > For IP:
> >> > - UDP port.
> >> >
> >> > For MPLS:
> >> > - 127/8 and UDP port.
> >> GIM>> Why would bootstrapping be required for multi-point BFD session
> >> GIM>> in
> >packet to an LSP as all BFD packets will come with 127/8 address. This
> >is why we need boot strapping with MPLS LSP ping. There was a draft for
> >the same long time ago.
> >

---

From: Santosh P K <[email-masked]>
Date: Mon, 24 Nov 2014 06:31:00 +0000

Mingui,
   Thanks for your comments.

Thanks
Santosh  P K 

> From: Mingui Zhang [mailto:[email-masked]]
> Sent: Monday, November 24, 2014 9:07 AM
> To: Santosh P K; Gregory Mirsky; Nobo Akiya (nobo); Henderickx, Wim
> (Wim); Jeffrey Haas; [email-masked]
> >To: Gregory Mirsky; Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey
> >Haas; [email-masked]; Mingui Zhang
> >> GIM>> My preference - C into the separate draft. And all related
> >> GIM>> updates of
> document/appendix.
> >(Nobo's preference)
> >> > It sounds like Santosh is preferring Option 2 while Wim is
> >> > preferring option
> >> 1.
> >> >
> >> GIM>> by other
> >> for 1+1 protection switchover. Any type of tail monitoring, IMO, is
> >> optional and can be document of its own.
> >
> document/appendix.
> >(Nobo's preference)

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Mon, 24 Nov 2014 10:18:52 +0000

Hello Santosh,
   I agree that option (C) is a reasonable approach to carry forward the P2MP document.
Thanks
Prasad

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Mingui Zhang
Sent: Monday, November 24, 2014 9:07 AM
To: Santosh P K; Gregory Mirsky; Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey Haas; [email-masked]
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

Hi Santosh,

<snip>
<snip>

Thanks,
Mingui

>> of demultiplexing then we may need to change the base document again?
>> issues with complete POLL sequence. Can you elaborate how this will help?
>>
>>
>> > > 5.       bfd.ReportTailDown
>> > polling can discover the available tails, becomes more of a fail-safe mechanism.
>>

---

From: Santosh P K <[email-masked]>
Date: Mon, 24 Nov 2014 11:37:08 +0000

Thanks Prasad. 

> From: Vengada Prasad Govindan (venggovi) [mailto:[email-masked]]
> Sent: Monday, November 24, 2014 3:49 PM
> To: Mingui Zhang; Santosh P K; Gregory Mirsky; Nobo Akiya (nobo);
> Henderickx, Wim (Wim); Jeffrey Haas; [email-masked]

---

From: Santosh P K <[email-masked]>
Date: Thu, 27 Nov 2014 15:55:48 +0000

I would like to thank all for valuable comments. I think we have made enough progress now. Below are the points on which we have rough consensus .

1.       Active tail.

We have rough consensus that we can move all active tail stuff (reliable, semi-reliable and non-reliable) to new draft.

Suggestion was made to add more text for IP demux and MPLS demux in base draft. For rest of the data plane can have their own draft.

3.       Echo mode supported?

We have rough consensus that echo mode is NOT supported.

4.        bfd.ReportTailDown directed to tail by head

How head directs tail to report down when tails detect timer expires should be outside scope of this document.

5.       How packets get absorbed on tails?

This should go along with data plane. Add more text on how tail absorbs packets for IP and MPLS in base draft.

There few points which are still open.

1.       Increase interval?

2.       Security consideration?

No suggestions.

I think I have summarized what we have discussed till now. Please let me know if I have missed something.

Thanks

Santosh P K

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 28 Nov 2014 02:25:15 +0000

Hi Santosh,

[snip]

> with POLL and suppress FINAL by setting desired RX interval set to 0? Please

With removal of all flavors of active tails, it's definitely no longer possible to have P/F sequences. However, I do think that it's a good idea to have an explicit indication in the packet to communicate to MultipointTail sessions that the transmit timers are about to change, this is very helpful for some implementations. I'm not clear on what you mean by "... by setting desired RX interval set to 0?". Can you elaborate?

> 2.       Security consideration?

Section 4.7:

   Sessions on the tail MAY be established dynamically, based on the
   receipt of a Multipoint BFD Control packet from the head, and are of
   type MultipointTail.  Tail sessions always take the Passive role.

One concerning area of this mechanism is the dynamic creation of MultipointTail sessions, as described by above text. This must not become the point of DoS attack, and for that we should beef up the texts.

In Section 4.8, making the tail demux'ing more stricter may be helpful.

[OLD]
   The head sends Multipoint BFD Control packets over the MultipointHead
   session with My Discr set to a value bound to the multipoint path,
   and with Your Discr set to zero.  The tails MUST demultiplex these
   packets based on a combination of the source address and My Discr,
   which together uniquely identify the head and the multipoint path.

[NEW]
   The head sends Multipoint BFD Control packets over the MultipointHead
   session with My Discr set to a value bound to the multipoint path,
   and with Your Discr set to zero.  The tails MUST demultiplex these
   packets based on a combination of the source address, My
   Discriminator and the identity of the multicast tree which the
   Multipoint BFD Control packet was received from.  Together they
   uniquely identify the head of the multipoint path.

In Security Considerations section, texts like below may be helpful.

[NEW]
   Implementations that creates MultpointTail sessions dynamically upon
   receipt of Multipoint BFD Control packets MUST implement protective
   measures to prevent infinite number of MultipointTail session being
   created.  Below lists some points to be considered in such
   implementations.

   o  If a Multipoint BFD Control packet did not arrive on a multicast
      tree (ex: on expected interface, with expected MPLS label, etc),
      then a MultipointTail session should not be created.

   o  If redundant streams are expected for a given multicast stream,
      then the implementations should not create more MultipointTail
      sessions than the number of streams.  Additionally, when the
      number of MultipointTail sessions exceeds the number of expected
      streams, then the implementation should generate an alarm to users
      to indicate the anomaly.

   o  The implementation should have a reasonable upper bound on the
      number of MultipointTail sessions that can be created, with the
      upper bound potentially being computed based on the number of
      multicast streams that the system is expecting.

Thanks!

-Nobo

---

From: Santosh P K <[email-masked]>
Date: Fri, 28 Nov 2014 13:04:50 +0000

Nobo,
   Thanks for your suggestions on last two open items. Please see inline. 

> With removal of all flavors of active tails, it's definitely no longer possible to
> have P/F sequences. However, I do think that it's a good idea to have an
> explicit indication in the packet to communicate to MultipointTail sessions
> that the transmit timers are about to change, this is very helpful for some
> implementations. I'm not clear on what you mean by "... by setting desired
> RX interval set to 0?". Can you elaborate?
> 

We do not really want to have complete POLL sequence with many to one mapping. So we somehow need to indicate to tails that packet has changed. Only possible way today is with POLL bit set, one way to suppress FINAL being generated from tail is to have desired RX interval to 0. This is something which goes against RFC 5880 where it says POLL should have FINAL in reply. I wanted to know if WG has any other alternative solution or if it ok to suppress FINAL.  

> One concerning area of this mechanism is the dynamic creation of
> MultipointTail sessions, as described by above text. This must not become
> the point of DoS attack, and for that we should beef up the texts.
> 

 These suggestion are good, I will add this text in draft. 

Thanks
Santosh P K

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 28 Nov 2014 13:41:30 +0000

Hi Santosh,

> Sent: Friday, November 28, 2014 8:05 AM
> To: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); Mingui Zhang;
> Gregory Mirsky; Henderickx, Wim (Wim); Jeffrey Haas; [email-masked]
> > With removal of all flavors of active tails, it's definitely no longer
> > possible to have P/F sequences. However, I do think that it's a good
> > idea to have an explicit indication in the packet to communicate to
> > MultipointTail sessions that the transmit timers are about to change,
> > this is very helpful for some implementations. I'm not clear on what
> > you mean by "... by setting desired RX interval set to 0?". Can you
> elaborate?
> >
> 
> We do not really want to have complete POLL sequence with many to one
> mapping. So we somehow need to indicate to tails that packet has changed.
> Only possible way today is with POLL bit set, one way to suppress FINAL
> being generated from tail is to have desired RX interval to 0. This is
> something which goes against RFC 5880 where it says POLL should have
> FINAL in reply. I wanted to know if WG has any other alternative solution or
> if it ok to suppress FINAL.

To me, having sufficient texts to describe MultipointHead sending P bit and MultipointTail suppressing F bit (since it never sends BFD packets to head) is sufficient. In other words, I don't see a need to tweak other bits to make sure that MultipointTail sessions do not send F bit. The only other point to consider is, how long does MultipointHead wait before applying the change.

If we take an extreme example:
- Current interval is 15 ms.
- Current detection multiplier is 3.
- MultipointHead wants to change the interval to 2 sec.
- MultipointHead sends P bit in next 3 BFD packets (3 x 15ms).
- MultipointHead update the interval to 2 sec.
- MultipointTail does not receive the first 2 P bit (for whatever reason) but receives the last P bit.

Now MultipointTail has 45ms to update the detection timer (since next packet is expected 2 sec later).
Under scaled number of sessions, does this raise any concerns to implementations?

In other words:
- Should MultipointHead send P bit set in next "multiplier" number of packets and change the interval at that point?
- Should the document specify a minimal time (say 1 second) before MultipointHead can change the interval?

Something to think about in implementations.

> > MultipointTail sessions, as described by above text. This must not
> > become the point of DoS attack, and for that we should beef up the texts.
> >

Thanks!

-Nobo

---

From: Santosh P K <[email-masked]>
Date: Sat, 29 Nov 2014 05:56:16 +0000

Hi Nobo,
    Please see my inline comments. 

> > > With removal of all flavors of active tails, it's definitely no
> > > longer possible to have P/F sequences. However, I do think that it's
> > > a good idea to have an explicit indication in the packet to
> > > communicate to MultipointTail sessions that the transmit timers are
> > > about to change, this is very helpful for some implementations. I'm
> > > not clear on what you mean by "... by setting desired RX interval
> > > set to 0?". Can you
> > elaborate?
> > >
> >
> > Only possible way today is with POLL bit set, one way to suppress
> > FINAL being generated from tail is to have desired RX interval to 0.
> > This is something which goes against RFC 5880 where it says POLL
> > should have FINAL in reply. I wanted to know if WG has any other
> > alternative solution or if it ok to suppress FINAL.
> 
> To me, having sufficient texts to describe MultipointHead sending P bit and
> MultipointTail suppressing F bit (since it never sends BFD packets to head) is
> sufficient. In other words, I don't see a need to tweak other bits to make
> sure that MultipointTail sessions do not send F bit. The only other point to
> consider is, how long does MultipointHead wait before applying the change.

We are surely removing active tail but only form this draft right. Meaning we will still have active tail in  extended draft. So can we really rule out that tail will not reply to head at all? 

> Under scaled number of sessions, does this raise any concerns to

This is really a good point. I think we should have a suggestion where it balances between number of POLL sent and how long does it wait before changing the timer. We should not end up sending too many POLL packets to tail as some implementation might end up sending all POLL packets to software. Do you agree? 

How about suggesting that we should first send POLL till detect time and post that head sends regular packet without POLL with the same rate (in this example 15ms) for next detect time and only then fall to higher interval? Any other suggestions? 

> Something to think about in implementations.

Yes, we need to add suggestions for implementation.

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Sat, 29 Nov 2014 08:31:45 +0000

Hello Santosh,

>How about suggesting that we should first send POLL till detect time and post that head sends regular packet without POLL with the >same rate (in this example 15ms) for next detect time and only then fall to higher interval? Any other suggestions?

Sorry to make you repeat,  but can you please clarify the above? Do you mean to say (assuming a detect multiplier of 3) that the head sends 3 packet with Poll bit set AND 3 more packets without it set (in effect 6 packets at 15 ms)?
Thanks
Prasad

-----Original Message-----
From: Santosh P K [mailto:[email-masked]] 
Sent: Saturday, November 29, 2014 11:26 AM
To: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); Mingui Zhang; Gregory Mirsky; Henderickx, Wim (Wim); Jeffrey Haas; [email-masked]
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

Hi Nobo,

> > > > implementation and don't want to check complete packet every 
> > > > time received then change in packet may be indicated with POLL bit set.
> > > longer possible to have P/F sequences. However, I do think that 
> > > it's a good idea to have an explicit indication in the packet to 
> > > communicate to MultipointTail sessions that the transmit timers 
> > > are about to change, this is very helpful for some 
> > > implementations. I'm not clear on what you mean by "... by setting 
> > > desired RX interval set to 0?". Can you
> > elaborate?
> > >
> >
> > We do not really want to have complete POLL sequence with many to 
> > one mapping. So we somehow need to indicate to tails that packet has
> changed.
> To me, having sufficient texts to describe MultipointHead sending P 
> bit and MultipointTail suppressing F bit (since it never sends BFD 
> packets to head) is sufficient. In other words, I don't see a need to 
> tweak other bits to make sure that MultipointTail sessions do not send 
> F bit. The only other point to consider is, how long does MultipointHead wait before applying the change.

> In other words:
> - Should MultipointHead send P bit set in next "multiplier" number of 
> packets and change the interval at that point?

---

From: Santosh P K <[email-masked]>
Date: Sat, 29 Nov 2014 13:10:48 +0000

Hi Prasad,

> >How about suggesting that we should first send POLL till detect time and
> post that head sends regular packet without POLL with the >same rate (in
> this example 15ms) for next detect time and only then fall to higher interval?
> Any other suggestions?
> 
> Sorry to make you repeat,  but can you please clarify the above? Do you
> mean to say (assuming a detect multiplier of 3) that the head sends 3 packet
> with Poll bit set AND 3 more packets without it set (in effect 6 packets at 15
> ms)?

Yes, that's correct. I know this not as per RFC 5880 but is this ok for WG? If not any better solution? 

Thanks
Santosh P K 

> We are surely removing active tail but only form this draft right. Meaning we
> will still have active tail in  extended draft. So can we really rule out that tail
> will not reply to head at all?
> 
> This is really a good point. I think we should have a suggestion where it
> balances between number of POLL sent and how long does it wait before
> changing the timer. We should not end up sending too many POLL packets to
> tail as some implementation might end up sending all POLL packets to
> software. Do you agree?
> 
> How about suggesting that we should first send POLL till detect time and post
> that head sends regular packet without POLL with the same rate (in this
> example 15ms) for next detect time and only then fall to higher interval? Any
> other suggestions?
> 
> 
> 
> > In other words:

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 30 Nov 2014 01:30:35 +0000

Hi Santosh, Prasad, et al,

> Sent: Saturday, November 29, 2014 8:11 AM
> To: Vengada Prasad Govindan (venggovi); Nobo Akiya (nobo); Mingui Zhang;
> > post that head sends regular packet without POLL with the >same rate
> > (in this example 15ms) for next detect time and only then fall to higher
> interval?
> > Any other suggestions?
> >
> > Sorry to make you repeat,  but can you please clarify the above? Do
> > you mean to say (assuming a detect multiplier of 3) that the head
> > sends 3 packet with Poll bit set AND 3 more packets without it set (in
> > effect 6 packets at 15 ms)?
> 

I would reword that slightly differently.

Before the MultipointHead changes it's transmit interval:

- The MultipointHead MUST send BFD packets "detect mult" times with P bit set, via transmit interval timer expiry.
- The MultipointHead MAY wait also wait some amount of time before making the changes to the transmit interval (this can be configured, but ultimately out of scope).

When the interval is slowing down, then:

- The MultipointHead SHOULD gradually slow down the transmit interval.

Something like that.

Thanks!

-Nobo

> > To: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); Mingui
> > Zhang; Gregory Mirsky; Henderickx, Wim (Wim); Jeffrey Haas;
> > [email-masked]
> > > > > > Draft suggest not to use POLL sequence and suggests to
> > > > > > increase multiplier first and then interval. If we have
> > > > > > hardware implementation and don't want to check complete
> > > > > > packet every time received then change in packet may be
> > > > > > indicated with POLL bit
> > set.
> > > > > > Since this is one to many mapping we can't have a complete
> > > > > > POLL sequence and hence we need to suppress FINAL. Should we
> > > > > > be going with POLL and suppress FINAL by setting desired RX
> > > > > > interval set to 0? Please suggest any better idea.
> > > > >
> > > > > implementations. I'm not clear on what you mean by "... by
> > > > > setting desired RX interval set to 0?". Can you
> > > > elaborate?
> > > > >
> > > >
> > > packets to head) is sufficient. In other words, I don't see a need
> > > to tweak other bits to make sure that MultipointTail sessions do not
> > > send F bit. The only other point to consider is, how long does
> > > MultipointHead
> > wait before applying the change.
> >
> > We are surely removing active tail but only form this draft right.
> > Meaning we will still have active tail in  extended draft. So can we
> > really rule out that tail will not reply to head at all?
> >
> > This is really a good point. I think we should have a suggestion where
> > it balances between number of POLL sent and how long does it wait
> > before changing the timer. We should not end up sending too many POLL
> > packets to tail as some implementation might end up sending all POLL
> > packets to software. Do you agree?
> >
> > How about suggesting that we should first send POLL till detect time
> > and post that head sends regular packet without POLL with the same
> > rate (in this example 15ms) for next detect time and only then fall to
> > higher interval? Any other suggestions?
> >
> >
> >
> > > In other words:
> > > - Should MultipointHead send P bit set in next "multiplier" number
> > > of packets and change the interval at that point?

---

From: Santosh P K <[email-masked]>
Date: Sun, 30 Nov 2014 03:59:49 +0000

Hi Nobo,

> > > sends 3 packet with Poll bit set AND 3 more packets without it set
> > > (in effect 6 packets at 15 ms)?
> >
> - The MultipointHead MAY wait also wait some amount of time before
> making the changes to the transmit interval (this can be configured, but
> ultimately out of scope).
> 

For slowing down interval we should fall to faster interval faster. For wordings you suggested was exactly what I thought. We don't want to mandate how an head implementation MUST behave during interval but we can give suggestion in the draft. 

Thanks
Santos h  P K

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Mon, 1 Dec 2014 04:21:17 +0000

Hello Santosh/ Nobo,
   Agree with the conclusions below.
Thanks
Prasad

-----Original Message-----
From: Santosh P K [mailto:[email-masked]] 
Sent: Sunday, November 30, 2014 9:30 AM
To: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); Mingui Zhang; Gregory Mirsky; Henderickx, Wim (Wim); Jeffrey Haas; [email-masked]
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

Hi Nobo,

> > > post that head sends regular packet without POLL with the >same 
> > > rate (in this example 15ms) for next detect time and only then 
> > > fall to higher
> > interval?
> > > Any other suggestions?
> > >
> > > Sorry to make you repeat,  but can you please clarify the above? 
> > > Do you mean to say (assuming a detect multiplier of 3) that the 
> > > head sends 3 packet with Poll bit set AND 3 more packets without 
> > > it set (in effect 6 packets at 15 ms)?
> >
> - The MultipointHead MUST send BFD packets "detect mult" times with P 
> bit set, via transmit interval timer expiry.
> making the changes to the transmit interval (this can be configured, 
> but ultimately out of scope).
> 

Thanks
Santos h  P K