Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017)

From: Greg Mirsky <[email-masked]>
Date: Mon, 3 Jul 2017 12:32:44 -0700

Dear Authors, WG chairs, et. al,
please kindly consider my comments to the latest version of the draft as
part of WGLC:

   - Very general
      - I suggest to add note clarifying that all terms that include
      "connectivity" in the document are being used as alternative to
      "continuity", i.e. existence of a path between the sender and
the receiver,
      and should not be interpreted as "connectivity verification in terms of
      transport network".
   - Introduction
      - I find that characterization of BFD and unidirectional continuity
      verification as "natural fit" bit of stretching. Perhaps "capable of
      supporting this use case" is acceptable;
   - Goals
      - the last statement of non-goal seems little unclear. In fact, if
      there's only one tail, the BFD for multipoint network does verify
      connectivity, though unidirectional, between the head and the
tail. I think
      that the intention is to stress that p2p bi-directional connectivity
      verification is not supported by this document.
   - Section 4.7
      - the last paragraph notes that the discriminator value MUST NOT be
      changed. Since Your Discriminator MUST be set to 0 this refers to My
      Discriminator only. I think that explicit reference will make
the statement
      more clear. Thus suggest s/the discriminator values/the My Discriminator
      value/
   - Section 4.8
      - I believe that requiring use of IP/UDP encapsulation for BFD in
      multipoint networks over MPSL LSP is too restrictive. I suggest changing
      text as following:

OLD:

For multipoint LSP, MultipointTail MUST use destination UDP port
"3784" and IP "127.0.0.0/8" range.

NEW

If IP/UDP encapsulation used by MultipointHead for multipoint LSP,
MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP
port "3784" and IP "127.0.0.0/8" range.

Use of other types of encapsulation for multipoint LSP is outside the
scope of this document.

   - Section 4.10
      - I cannot say what bfd.DetectMult packet is. It has not been
defined in RFC 5880, nor in this document. What is the scenario
described in the second paragraph? Is it when MultipointHead reduces
Desired Min TX  Interval thus making defect detection more aggressive?
   - Section 7
      - I think it should be plural in the first paragraph, i.e.
s/MultipointTail session/MultipointTail sessions/
      - I think that we can add another consideration to improve,
strengthen security of BFD for multipoint network by suggesting that
MultipointTail sessions created only for known combination of
MultipointHead and My Discriminator. Such information MAY be learned
from out-of-band and mechanisms are outside the scope of this
document.

Regards,

Greg

On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas <[email-masked]> wrote:

> Working Group,
>
> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10
> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04
>
>
> The BFD Multipoint documents have been stable for some time.  Prior
> discussion at meetings has suggested we have an implementation for the main
> protocol component.  Also per prior discussions, we split the active-tail
> component of the original multipoint document to permit implementors to not
> have to worry about implementing active-tail procedures if they weren't
> interested in that feature.
>
> We are starting an extended last call on these documents.  The WGLC will
> conclude on July 14.  This provides ample time for list discussion.  If
> necessary, the IETF-99 meeting may provide for opportunities to close any
> contentious technical points.  (BFD is not currently scheduled to meet.)
>
> One item I would like to kick off is the document status of the active-tail
> mechanism.  At this time, no one has implemented it that I am aware of.
> Discussion with our AD suggests that publishing the document with
> Experimental status may be reasonable to preserve the work that went into
> the proposal.
>
> -- Jeff
>
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 5 Jul 2017 12:25:05 -0400

Carlos,

Thanks for your detailed feedback.  Most of this feedback seems to be of the
nature of minor edits.  Is it your opinion this document is ready to advance
after these issues are addressed?

-- Jeff

On Tue, Jun 27, 2017 at 02:56:22PM +0000, Carlos Pignataro (cpignata) wrote:
> Just one comment on these two documents, in regards to the state variables:
> 
> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10#section-4.4.1
> 
> 4.4.1.  New State Variables
> 
>    A number of state variables are added to the base specification in
>    support of Multipoint BFD.
> 
>       bfd.SessionType
> 
>          The type of this session.  Allowable values are:
> 
> CMP: However, this state (bfd.SessionType) variable is already defined in SBFD RFC 7880:
> 
> https://tools.ietf.org/html/rfc7880#section-6.1
> 
> 6.1.  New State Variables
> 
>    A new state variable is added to the base specification in support
>    of S-BFD.
> 
>    o  bfd.SessionType: This is a new state variable that describes
>       the type of a particular session.
> 
> 
> CMP: So, for draft-ietf-bfd-multipoint, I suggest a pointer to RFC 7880 where bfd.SessionType is defined in the addition of new values to the existing variable.
> 
> CMP: Similarly:
> 
> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04#section-3.3.1
> 
>       bfd.SessionType
> 
>          The type of this session as defined in
>          [I-D.ietf-bfd-multipoint].  A new value introduced is:
> 
> CMP: The pointer above should be to RFC 7880 also, and:
> 
>       bfd.SilentTail
> 
> CMP: But this is defined in draft-ietf-bfd-multipoint
> 
> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10#section-4.4.1
> 
>       bfd.SilentTail
> 
> Thanks!
> 
> — Carlos.
> 
> 
> On Jun 19, 2017, at 3:39 PM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
> 
> Working Group,
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 5 Jul 2017 12:26:43 -0400

Greg,

Thanks for your detailed feedback.

A portion of your feedback seems to be mostly minor editorial changes.  A
few of these items are discussion points that probably need to be resolved
with some amount of WG discussion.

What's your opinion about the ability to advance these documents once these
issues have been addressed?

-- Jeff

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 5 Jul 2017 18:02:34 +0000

Jeff,

Thanks for seeking clarification and apologies for not being explicit enough: Yes, I believe this document is ready to advance.

Thanks,

— Carlos.

On Jul 5, 2017, at 12:25 PM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

-- Jeff

     bfd.SessionType

6.1.  New State Variables

CMP: Similarly:

     bfd.SessionType

     bfd.SilentTail

     bfd.SilentTail

Thanks!

— Carlos.

On Jun 19, 2017, at 3:39 PM, Jeffrey Haas <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

Working Group,

-- Jeff

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 5 Jul 2017 11:10:36 -0700

Hi Jeff,
thank you for your kind consideration of my comments. Yes, after we agree
on how to address the comments, the document shall be advanced.

Regards,
Greg

---

From: Santosh P K <[email-masked]>
Date: Thu, 6 Jul 2017 22:19:19 +0530

Hello Carlos,
     Thanks for your review comments. Please see inline [SPK].

Thanks
Santosh P K

> CMP: However, this state (bfd.SessionType) variable is already defined in

[SPK] Ok we can remove it here and give reference to RFC 7880. This draft
can use this state variable and need not say that new state variable.

> CMP: So, for draft-ietf-bfd-multipoint, I suggest a pointer to RFC 7880
> where bfd.SessionType is defined in the addition of new values to the
> existing variable.
>

[SPK] Sure.

> [SPK] I will take care of this.

> Thanks!
>
> — Carlos.
>
>
> On Jun 19, 2017, at 3:39 PM, Jeffrey Haas <[email-masked]> wrote:
>
> Working Group,
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 6 Jul 2017 16:55:35 +0000

Thanks, Santosh!

On Jul 6, 2017, at 12:49 PM, Santosh P K <[email-masked]<mailto:[email-masked]>> wrote:

Hello Carlos,

Thanks
Santosh P K

On Tue, Jun 27, 2017 at 8:26 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Just one comment on these two documents, in regards to the state variables:

      bfd.SessionType

[SPK] Ok we can remove it here and give reference to RFC 7880. This draft can use this state variable and need not say that new state variable.

6.1.  New State Variables

[SPK] Sure.

CMP: Similarly:

      bfd.SessionType

      bfd.SilentTail

      bfd.SilentTail

Thanks!

— Carlos.

Working Group,

-- Jeff

—

---

From: Santosh P K <[email-masked]>
Date: Thu, 6 Jul 2017 22:57:13 +0530

Hello Greg,
   Thanks for your comments. Please see my reply inline tagged[ SPK].

Thanks
Santosh P K

On Tue, Jul 4, 2017 at 1:02 AM, Greg Mirsky <[email-masked]> wrote:

>       "continuity", i.e. existence of a path between the sender and the receiver,
> [SPK] Will take care.

>       connectivity, though unidirectional, between the head and the tail. I think
> [SPK] It only says that this document does not support verification of
unicast path between head and tail. I can clarify a bit on this. Please let
me know if you have a suggestion for this.

>       Discriminator only. I think that explicit reference will make the statement
> [SPK] Will take care of this.

> For multipoint LSP, MultipointTail MUST use destination UDP port "3784" and IP "127.0.0.0/8" range.
>
>
> NEW
>
> If IP/UDP encapsulation used by MultipointHead for multipoint LSP, MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP port "3784" and IP "127.0.0.0/8" range.
>
> Use of other types of encapsulation for multipoint LSP is outside the scope of this document.
>
>
[SPK] Thanks. I think this make sense for non MPLS tunnels.

>
>    - Section 4.10
>       - I cannot say what bfd.DetectMult packet is. It has not been defined in RFC 5880, nor in this document. What is the scenario described in the second paragraph? Is it when MultipointHead reduces Desired Min TX  Interval thus making defect detection more aggressive?
>    -
>
> [SPK] This section talks about how to handle Poll sequence. In case of
Multipoint head we cant afford to send POLL and expect all tail to reply
with F bit set. Keeping track and building state at headend will be costly.

>
>    - Section 7
>       - I think it should be plural in the first paragraph, i.e. s/MultipointTail session/MultipointTail sessions/
>       - I think that we can add another consideration to improve, strengthen security of BFD for multipoint network by suggesting that MultipointTail sessions created only for known combination of MultipointHead and My Discriminator. Such information MAY be learned from out-of-band and mechanisms are outside the scope of this document.
>
>
> Regards,
>
> Greg
>
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 6 Jul 2017 11:00:41 -0700

Hi Santosh,
many thanks for your thoughtful consideration of my comments. Please find
my answers and couple more notes in-line and tagged GIM>>.

Regards,
Greg

On Thu, Jul 6, 2017 at 10:27 AM, Santosh P K <[email-masked]>
wrote:

>>       - I find that characterization of BFD and unidirectional
>>       continuity verification as "natural fit" bit of stretching. Perhaps
>>       "capable of supporting this use case" is acceptable;
>>
>> [SPK] Will take care.
>
GIM>> Thanks

> me know if you have a suggestion for this.
GIM>> I'd suggest to use unicast in place of point-to-point. Using my
earlier example, in case when there's only one tail multipoint becomes
point-to-point.

>
>
>>
>>    - Section 4.7
>>       - the last paragraph notes that the discriminator value MUST NOT
>>       be changed. Since Your Discriminator MUST be set to 0 this refers to My
GIM>> Thanks.

> [SPK] Thanks. I think this make sense for non MPLS tunnels.
GIM>> Thanks. As I've looked at the text, I've realized that it misses IPv6
case. Please consider the following as my new proposed change (not sure but
I think that quote marks are not required):
NEW
If IP/UDP encapsulation used by MultipointHead for multipoint LSP,
MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP port
3784, and the 127/8 range for IPv4, and the 0:0:0:0:0:FFFF:7F00/104 range
for IPv6.
Use of other types of encapsulation for multipoint LSP is outside the scope
of this document.

> with F bit set. Keeping track and building state at headend will be costly.
GIM>> Perhaps I wasn't clear in my question.  It was to the opening of this
sentence:

   The MultipointHead MUST send bfd.DetectMult packets with P bit set at
   the old transmit interval before using the higher value in order to
   avoid false detection timeouts at the tails.

I couldn't find reference to "bfd.DetectMult packet" in any document
related to BFD.

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 7 Jul 2017 18:16:53 -0700

Hi Santosh, et. al,
another note, question on IP/UDP encapsulation of BFD for multipoint
networks. The document says nothing about values that may be used for
Source UDP port number. Even though MultipointHead will not receive BFD
packets from MultipointTail on the UDP port listed, should we recommend to
use numbers from dynamic range, i.e. 49152 to 65535? I think that the
multipoint document should state, as in RFC 5881:

The source port MUST be in the range 49152 through 65535.

What do you think?

Regards,
Greg

On Thu, Jul 6, 2017 at 11:00 AM, Greg Mirsky <[email-masked]> wrote:

> On Thu, Jul 6, 2017 at 10:27 AM, Santosh P K <[email-masked]
> > wrote:
>
>> Hello Greg,
>>>       - the last statement of non-goal seems little unclear. In fact,
>>>       if there's only one tail, the BFD for multipoint network does verify
> GIM>> Thanks. As I've looked at the text, I've realized that it misses
> IPv6 case. Please consider the following as my new proposed change (not
> sure but I think that quote marks are not required):
> NEW
> GIM>> Perhaps I wasn't clear in my question.  It was to the opening of
> this sentence:
>
> I couldn't find reference to "bfd.DetectMult packet" in any document related to BFD.
>
>
>
>>>    - Section 7

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 9 Jul 2017 10:17:12 -0700

Hi Santosh, et. al,
would like us to look closer into the statement in Goals section, the one

I think we've missed MPLS network scenario. What would be the difference
between p2p LSP and p2mp LSP? Both use labels though with different
context. So the only difference is that BFD for multipoint does not monitor
bi-directional continuity, i.e. viability of a path, between root and the
leaf. I believe such statement already exists in the document and doesn't
seem there's need to repeat it again. Perhaps we can remove that last
statement altogether?

Regards,
Greg

On Fri, Jul 7, 2017 at 6:16 PM, Greg Mirsky <[email-masked]> wrote:

>> On Thu, Jul 6, 2017 at 10:27 AM, Santosh P K <
>> [email-masked]> wrote:
>>
>>> Hello Greg,
>>>> please kindly consider my comments to the latest version of the draft
>>>> as part of WGLC:
>>>>
>>>>    - Very general
>>>>       - I believe that requiring use of IP/UDP encapsulation for BFD
>>>>       in multipoint networks over MPSL LSP is too restrictive. I suggest changing
>>>>       text as following:
>>>>
>>>> OLD:
>>>>
>> 3784, and the 127/8 range for IPv4, and the 0:0:0:0:0:FFFF:7F00/104
>> range for IPv6.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 9 Jul 2017 21:30:29 +0000

Greg,

How would that help interoperability? Seems like it would not matter, hence not mention is appropriate...

Sent from my iPad

On Jul 7, 2017, at 9:17 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Santosh, et. al,
another note, question on IP/UDP encapsulation of BFD for multipoint networks. The document says nothing about values that may be used for Source UDP port number. Even though MultipointHead will not receive BFD packets from MultipointTail on the UDP port listed, should we recommend to use numbers from dynamic range, i.e. 49152 to 65535? I think that the multipoint document should state, as in RFC 5881:

What do you think?

Regards,
Greg

On Thu, Jul 6, 2017 at 11:00 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Santosh,
many thanks for your thoughtful consideration of my comments. Please find my answers and couple more notes in-line and tagged GIM>>.

Regards,
Greg

On Thu, Jul 6, 2017 at 10:27 AM, Santosh P K <[email-masked]<mailto:[email-masked]>> wrote:
Hello Greg,
   Thanks for your comments. Please see my reply inline tagged[ SPK].

Thanks
Santosh P K

On Tue, Jul 4, 2017 at 1:02 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Dear Authors, WG chairs, et. al,
please kindly consider my comments to the latest version of the draft as part of WGLC:

  *   Very general
     *   I suggest to add note clarifying that all terms that include "connectivity" in the document are being used as alternative to "continuity", i.e. existence of a path between the sender and the receiver, and should not be interpreted as "connectivity verification in terms of transport network".
  *   Introduction
     *   I find that characterization of BFD and unidirectional continuity verification as "natural fit" bit of stretching. Perhaps "capable of supporting this use case" is acceptable;

[SPK] Will take care.
GIM>> Thanks

  *   Goals
     *   the last statement of non-goal seems little unclear. In fact, if there's only one tail, the BFD for multipoint network does verify connectivity, though unidirectional, between the head and the tail. I think that the intention is to stress that p2p bi-directional connectivity verification is not supported by this document.

[SPK] It only says that this document does not support verification of unicast path between head and tail. I can clarify a bit on this. Please let me know if you have a suggestion for this.
GIM>> I'd suggest to use unicast in place of point-to-point. Using my earlier example, in case when there's only one tail multipoint becomes point-to-point.

  *   Section 4.7
     *   the last paragraph notes that the discriminator value MUST NOT be changed. Since Your Discriminator MUST be set to 0 this refers to My Discriminator only. I think that explicit reference will make the statement more clear. Thus suggest s/the discriminator values/the My Discriminator value/

  *   Section 4.8
     *   I believe that requiring use of IP/UDP encapsulation for BFD in multipoint networks over MPSL LSP is too restrictive. I suggest changing text as following:

OLD:

For multipoint LSP, MultipointTail MUST use destination UDP port "3784" and IP "127.0.0.0/8<http://127.0.0.0/8>" range.

NEW

If IP/UDP encapsulation used by MultipointHead for multipoint LSP, MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP port "3784" and IP "127.0.0.0/8<http://127.0.0.0/8>" range.

[SPK] Thanks. I think this make sense for non MPLS tunnels.
GIM>> Thanks. As I've looked at the text, I've realized that it misses IPv6 case. Please consider the following as my new proposed change (not sure but I think that quote marks are not required):
NEW
If IP/UDP encapsulation used by MultipointHead for multipoint LSP, MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP port 3784, and the 127/8 range for IPv4, and the 0:0:0:0:0:FFFF:7F00/104 range for IPv6.
Use of other types of encapsulation for multipoint LSP is outside the scope of this document.

  *   Section 4.10
     *   I cannot say what bfd.DetectMult packet is. It has not been defined in RFC 5880, nor in this document. What is the scenario described in the second paragraph? Is it when MultipointHead reduces Desired Min TX  Interval thus making defect detection more aggressive?
  *

[SPK] This section talks about how to handle Poll sequence. In case of Multipoint head we cant afford to send POLL and expect all tail to reply with F bit set. Keeping track and building state at headend will be costly.
GIM>> Perhaps I wasn't clear in my question.  It was to the opening of this sentence:

  *   Section 7
     *   I think it should be plural in the first paragraph, i.e. s/MultipointTail session/MultipointTail sessions/
     *   I think that we can add another consideration to improve, strengthen security of BFD for multipoint network by suggesting that MultipointTail sessions created only for known combination of MultipointHead and My Discriminator. Such information MAY be learned from out-of-band and mechanisms are outside the scope of this document.

Regards,

Greg

On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
Working Group,

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 31 Jul 2017 13:15:34 -0400

Working Group,

We've received some good feedback for Santosh to include in the next
revision of the documents and likely have enough discussion to move them
forward in the publication process.

At this point, we are waiting for targeted review from ALU/Nokia who
actually has an implementation of the base multipoint spec.  Once we've
received that review, we can continue in our deliberations.

-- Jeff