Subject: RE: AD Review of draft-ietf-bfd-seamless-base

From: Santosh P K <[email-masked]>
Date: Sun, 6 Dec 2015 09:09:18 +0000

Hello Alvaro,
   
Thanks for your comments. Please see inline comments [SPK]. I have addressed rest of the comments from you and have attached the new version and also diff between 05 and 06 version. 

Thanks
Santosh P K

Major:
1. Section 1. (Introduction) says that "This document extends BFD to provide solutions to use cases listed in [I-D.ietf-bfd-seamless-use-case]."  Maybe it's just me, but I fail to see how all the use cases are satisfied - in part because the requirements in I-D.ietf-bfd-seamless-use-case are not clear (see my review for that document), and in part because this document isn't explicit about how the specification solves the use cases.  For example, how does this document provide a solution for the use case in section 3.6. (BFD for Anycast Address)?
2. Normative References 
o I-D.ietf-bfd-multipoint should clearly be Normative because of the new bfd.SessionType state variable
o I-D.ietf-bfd-generic-crypto-auth should also be Normative because of how the Security Considerations are written: pointing to is as a "MUST".  Given that (as far as I can tell) there aren't implementations of I-D.ietf-bfd-generic-crypto-auth, we could end up with a Normative reference that blocks the publication of this document.  I want to suggest that the comments be reworded as a suggestion or pointer to potential solutions, not as a mandate to use them.  [Disclaimer: we will still need the SecDir to review.]

[SPK] Carlos has replied to these comments and I am waiting for confirmation on these comments. 

o "Diagnostic (Diag)   MAY be set to appropriate value for communicating with peer"  The obvious question is: which values?  Section 7.4. (Diagnostic Values) tries to address that, but it says that "Diagnostic value in both directions MAY be set to a certain value...details of such are outside the scope of this specification."  What about bfd.LocalDiag?  Are those values still valid?  As long as 7.4 is there, you could explain a little bit more why this doesn't matter.  

[SPK] I am not sure if understood the comment here.

o You didn't say anything about the "Authentication Section".

[SPK] It is same as RFC 5880 and hence not mentioned. 

o Unlike rfc5880, this document doesn't explicitly mention that "Some form of authentication SHOULD be included, since Echo packets may be spoofed."   The recommendation of sending both S-BFD control and echo packets points at alleviating some of the spoofing concerns even though they are independent packets (in other words: the Echo packet can still u-turn at a different node).  Please include a discussion of the alleviated security concern in the Security Considerations (since it is different than rfc5880).  Also, it would be nice if it was mentioned explicitly whether authentication for Echo packets is needed/recommended or not.
7. Section 11. (Security Considerations) 

[SPK] I want this to be discussed in WG before I can address these comments. 

o "crypto sequence number"  What are you referring to?  I'm guessing the Sequence Number field in the Authentication Section - is that a good guess?  Please be specific and include a reference.
o The text says that the "SBFDReflector MUST compute the Authentication data", but that it "MUST NOT look at the crypto sequence number".  Is that a contradiction?  As defined in rfc5880, the Authentication Data seems to include everything in the Authentication Section, including the sequence number.

[SPK] SBFDReflector has no state to check for sequence number. That is the reason why it MUST NOT look at the sequence number and only should check the authentication. 

o Why isn't the "loop problem" in Appendix A mentioned?

[SPK] It is mentioned in appendix A. Did you mean why is this mentioned? This is to give more clarity on why we are overloading D bit to break the loop. 

8. Nowhere in this document (or draft-ietf-bfd-seamless-ip) is congestion mentioned.  rfc5880 talks about some of the considerations.  Are there new congestion-related considerations that arise because of eliminating some of the negotiation aspects?  Thinking out loud: if a session doesn't have to be established (and everyone knows a remote discriminator), then there's a possibility of more nodes sending traffic to a specific reflector (just as an example).  Please include some text indicating any congestion issues - or at least explaining why there aren't any new ones.

[SPK] It has no new congestion issues. SBFDRefelector will be able to use "Required Min RX interval" to control rate from senders.

     " Required Min RX Interval

         MUST be set to a value describing how many incoming control
         packets this reflector BFD session can handle.  Further details
         are described in Section 7.8."

Do you still think we need to add a separate section explaining it? 

3. Section 4.1. (S-BFD Discriminator Uniqueness)  I think the text in this section is a little confusing.  The requirement (the "S-BFD discriminator...MUST be unique within an administrative domain") is clearly stated at the start, but then the justification of why goes into how is IP is used (with no reference to where S-BFD for IP is specified) and concludes that (in that case) the "S-BFD discriminator only has to be unique within a local node" - at first read it sounds like there is a contradiction in the text.  The paragraph closes with a reiteration of the uniqueness.  Please clarify - maybe specifically state that the discussion (maybe in a separate paragraph) is to justify the uniqueness..

[SPK] It is not a contradicting it just gives an example to say if IP then you really don't need a discr unique to domain but SBFD is generic and hence it needs to be unique. Do you want to reword this?   

5. Section 7.1. (Demultiplexing of S-BFD Control Packet)   
o What happens if the "your discriminator" field doesn't match an existing SBFDReflector session?  I think the piece where the packet is discarded is missing.  Section 7.3.1. (Responder Demultiplexing) does say that in that case the packet "MUST NOT be considered for this mechanism".  Does that mean that the packets are to be discarded, or something else?
o Is there a reason for having 7.3.1?  IOW, can anything extra there be included in 7.1?

[SPK] one talks about initiator and other talks about reflector hence separate sections. 

o It may be the indenting, but it looks like the logic says: if the packet doesn't correspond to an SBFDInitiator session, then discard it.
o "More details on S-BFD control packet demultiplexing are described in relevant S-BFD data plane documents."  Section 4. (S-BFD Control Packet Demultiplexing) of draft-ietf-bfd-seamless-ip actually has less details: it doesn't include the step about discarding if there's no corresponding SBFDInitiator session, nor the last ELSE.

[SPK] I have addressed this in base document itself.

3. Section 7.2. (Initiator Procedures) 
o The example and the figure seem out of place in this section as the responder procedures haven't been introduced yet.

[SPK] So should this section be placed after reflector procedure has been introduced? 

6. Section 8. (Scaling Aspect)  The text indirectly implies that the scaling is better by saying that the number of sessions is less.. I understand the point, but it just sounds like a superfluous section to me.

[SPK] Remove it? 

7. Section 9. (Co-existence with Classical BFD Sessions) is another superfluous section; there's nothing here that you couldn't have said in 7.1.

[SPK] Remove it?

Thanks
Santosh P K

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 8 Dec 2015 14:36:29 +0000

On 12/6/15, 4:09 AM, "Santosh P K" <[email-masked]> wrote:

Santosh:

Hi!  Thanks for picking up the pen on this one!

>Thanks for your comments. Please see inline comments [SPK]. I have
>addressed rest of the comments from you and have attached the new version
>and also diff between 05 and 06 version.

I looked at the proposed new text and the diffs.  I left below only the
parts that I think still need more work, added back a couple of items and
answered some questions.

Thanks!

Alvaro.

> 
>Major:
>1. Section 1. (Introduction) says that "This document extends BFD to
>provide solutions to use cases listed in
>[I-D.ietf-bfd-seamless-use-case]."  Maybe it's just me, but I fail to see
>how all the use cases are satisfied - in part because the requirements in
>I-D.ietf-bfd-seamless-use-case are not clear (see my review for that
>document), and in part because this document isn't explicit about how the
>specification solves the use cases.  For example, how does this document
>provide a solution for the use case in section 3.6. (BFD for Anycast
>Address)?
>2. Normative References
>o I-D.ietf-bfd-generic-crypto-auth should also be Normative because of
>how the Security Considerations are written: pointing to is as a "MUST".
>Given that (as far as I can tell) there aren't implementations of
>I-D.ietf-bfd-generic-crypto-auth, we could end up with a Normative
>reference that blocks the publication of this document.  I want to
>suggest that the comments be reworded as a suggestion or pointer to
>potential solutions, not as a mandate to use them.  [Disclaimer: we will
>still need the SecDir to review.]
>

Unless I missed something, Carlos [1] didn't reply to #1: how are the use
cases satisfied?  I'm looking forward to an updated version of
I-D.ietf-bfd-seamless-use-case which may help.

FWIW, I agree with his comments related to the references.  And still
think that both should be Normative.  BTW, I don't think that changing the
"MUST" to "SHOULD" when referring to I-D.ietf-bfd-generic-crypto-auth
changed that need.

[1] 
https://mailarchive.ietf.org/arch/msg/rtg-bfd/o81wfG8db34WhnX9qMPCZ-IEtAQ

> 
>o "Diagnostic (Diag)   MAY be set to appropriate value for communicating
>with peer"  The obvious question is: which values?  Section 7.4.
>(Diagnostic Values) tries to address that, but it says that "Diagnostic
>value in both directions MAY be set to a certain value...details of such
>are outside the scope of this specification."  What about bfd.LocalDiag?
>Are those values still valid?  As long as 7.4 is there, you could explain
>a little bit more why this doesn't matter.
>

The (updated) text (7.2.2/7.3.2) says that Diag "MUST be set as per
Section 6.8.7 of [RFC5880]", which simply reads "Set to bfd.LocalDiag."
As far as I can tell, there are 4 values defined for Diag in rfc5880.
But, Section 7.4 of this document reads:

7.4.  Diagnostic Values

   Diagnostic value in both directions MAY be set to a certain value, to
   attempt to communicate further information to both ends.  However,
   details of such are outside the scope of this specification.

So..the (updated) text (7.2.2/7.3.2) does say that Diag = bfd.LocalDiag,
but 7.4 seems to imply that other values (besides the ones in rfc5880) are
valid.  That part is ok (about other values), but it is still no clear
whether the values from rfc5880 are also valid or not.

. . .

There are still some other comments that I don't think were addressed from
7.2.2 and 7.3.2.  In most of the comments below the common thread is
whether the state variables described in rfc5880 are reused (if so, then
maybe the initialization/maintenance are different) or not (if so, are you
creating new variables here and not explicitly defining them?).

For 7.2.2:

* "Your Discriminator Set to value corresponding to remote entity.² Do you
mean bfd.RemoteDiscr? BTW, I think you should explain how this variable is
initialized.

For 7.3.2:

* Several fields are set to the value copied from the received packet
(Detect Mult, My Discriminator, Your Discriminator and Desired Min TX
Interval).  I¹m assuming that all these values are copied into the state
variables defined in rfc5880.  If so, then mentioning these fields seems
redundant given the header of the section.

* "bfd.RequiredMinRxInterval, value describing how many incoming control
packets this reflector BFD session can handle"   But rfc5880 defines
bfd.RequiredMinRxInterval as "The minimum interval, in microseconds,
between received BFD Control packets".  IOW, the definitions don't match.

>o Unlike rfc5880, this document doesn't explicitly mention that "Some
>form of authentication SHOULD be included, since Echo packets may be
>spoofed."   The recommendation of sending both S-BFD control and echo
>packets points at alleviating some of the spoofing concerns even though
>they are independent packets (in other words: the Echo packet can still
>u-turn at a different node).  Please include a discussion of the
>alleviated security concern in the Security Considerations (since it is
>different than rfc5880).  Also, it would be nice if it was mentioned
>explicitly whether authentication for Echo packets is needed/recommended
>or not.

You mean the comment above, right?

Discussing with the WG is perfectly fine with me.

> 
>o "crypto sequence number"  What are you referring to?  I'm guessing the
>Sequence Number field in the Authentication Section - is that a good
>guess?  Please be specific and include a reference.
>o The text says that the "SBFDReflector MUST compute the Authentication
>data", but that it "MUST NOT look at the crypto sequence number".  Is
>that a contradiction?  As defined in rfc5880, the Authentication Data
>seems to include everything in the Authentication Section, including the
>sequence number.
>
>[SPK] SBFDReflector has no state to check for sequence number. That is
>the reason why it MUST NOT look at the sequence number and only should
>check the authentication.

Ahh.. So you mean that it shouldn't bother with the seq because it can't
verify it.  What confused me (and may confuse others) is the meaning of
"look at": if the Reflector is computing the Authentication Data it may
look (as in notice that is there) at the sequence number vs actually
calculating it.  I'm ok with leaving the current language (now that I
understand), but it might be nice to clarify.

>[SPK] It is mentioned in appendix A. Did you mean why is this mentioned?
>This is to give more clarity on why we are overloading D bit to break the
>loop.

I meant why isn't it mentioned in the Security Considerations section?  If
it's a problem worth including in the document, I think it would be good
to point at it in a section that people may read.

> 
>8. Nowhere in this document (or draft-ietf-bfd-seamless-ip) is congestion
>mentioned.  rfc5880 talks about some of the considerations.  Are there
>new congestion-related considerations that arise because of eliminating
>some of the negotiation aspects?  Thinking out loud: if a session doesn't
>have to be established (and everyone knows a remote discriminator), then
>there's a possibility of more nodes sending traffic to a specific
>reflector (just as an example).  Please include some text indicating any
>congestion issues - or at least explaining why there aren't any new ones.
>
>
>[SPK] It has no new congestion issues. SBFDRefelector will be able to use
>"Required Min RX interval" to control rate from senders.
>

I do.

Also, in Carlos' answer (see [1] above), he wrote: "Very much agree. I
believe there are subtle differences in the congestion considerations,
because if the simplified negotiation.  Further, I believe those should
live in the -base doc. That is missing, and we should fill in this gap."

> 
>3. Section 4.1. (S-BFD Discriminator Uniqueness)  I think the text in
>this section is a little confusing.  The requirement (the "S-BFD
>discriminator...MUST be unique within an administrative domain") is
>clearly stated at the start, but then the justification of why goes into
>how is IP is used (with no reference to where S-BFD for IP is specified)
>and concludes that (in that case) the "S-BFD discriminator only has to be
>unique within a local node" - at first read it sounds like there is a
>contradiction in the text.  The paragraph closes with a reiteration of
>the uniqueness.  Please clarify - maybe specifically state that the
>discussion (maybe in a separate paragraph) is to justify the uniqueness..
>
>[SPK] It is not a contradicting it just gives an example to say if IP
>then you really don't need a discr unique to domain but SBFD is generic
>and hence it needs to be unique. Do you want to reword this?

You did it again! ;-)   "...if IP then you really don't need a discr
unique to domain but SBFD is generic and hence it needs to be unique..."
Maybe I'm just reading too  much into it..

IMHO, because this document doesn't describe S-BFD for IP, then maybe it's
a good idea to move this discussion to draft-ietf-bfd-seamless-ip and
avoid the confusion altogether.

. . .

There is one other comment I marked as Minor that I would like to see
addressed:

* The base document is not describing the operation in IP and MPLS
environments, are  the references to rfc5881, rfc5883, rfc5884 and rfc5885
needed in 7.3 and 11?  And do the procedures and security considerations
really apply?

>o The example and the figure seem out of place in this section as the
>responder procedures haven't been introduced yet.
>

I think that would be nice.

> 
>6. Section 8. (Scaling Aspect)  The text indirectly implies that the
>scaling is better by saying that the number of sessions is less.. I
>understand the point, but it just sounds like a superfluous section to me.
>
>[SPK] Remove it? 
>
>7. Section 9. (Co-existence with Classical BFD Sessions) is another
>superfluous section; there's nothing here that you couldn't have said in
>7.1.
>
>[SPK] Remove it?

Both seem superfluous to me, but these are just nits, so it's up to you.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 8 Dec 2015 09:40:48 -0500

> I-D.ietf-bfd-seamless-use-case which may help.

My understanding is that the use case draft is unlikely to proceed.  With
your blessing even.  How do you want the text here adjusted?

-- Jeff

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 8 Dec 2015 15:10:44 +0000

Alvaro,

> On Dec 8, 2015, at 9:36 AM, Alvaro Retana (aretana) <[email-masked]> wrote:
> 

What’s your (Alvar, Jeff) view on whether this doc should define bfd.SessionType and not multipoint?

Seems to me that it is probably best (although an almost negligible preference) to define it here and have multipoint referencing s-bfd.

Also, agree that we should reword the bfs-generic-crypto-auth reference beyond a SHOULD, as one potential solution and not as a necessary implementation.

> live in the -base doc. That is missing, and we should fill in this gap.”
> 

I still agree with my old comment :-)

Note I do not think we need to over-specify this… something simple.

Thanks!

— Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 8 Dec 2015 15:12:05 +0000

> On Dec 8, 2015, at 9:40 AM, [email-masked] wrote:
> 

How about:

OLD:
   This document
   extends BFD to provide solutions to use cases listed in
   [I-D.ietf-bfd-seamless-use-case].

NEW:

<null>

?

Thanks,

— Carlos.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 8 Dec 2015 16:14:33 +0000

On 12/8/15, 10:12 AM, "Carlos Pignataro (cpignata)" <[email-masked]>
wrote:

Hi!

>   [I-D.ietf-bfd-seamless-use-case].

No.

I would prefer if the document said something about what problem it
solves.  Vs just extending BFD because we can.  Which is why I suggested
rewording I-D.ietf-bfd-seamless-use-case to be clear about what is
expected in each scenario [1] (but we got bogged down on my comments about
publication and paid no attention to what could be done to move
forward..even now that the WG has indicated that it doesn't mind if the
document is published..  <sigh>   But that is a different story.).

If I-D.ietf-bfd-seamless-use-case is updated, then we can keep the "OLD"
text above.  With the caveat that there are some use cases described there
for which it is not clear to me how this document applies.  My original
comments mentioned section 3.6. (BFD for Anycast Address) as an example.

If I-D.ietf-bfd-seamless-use-case is not updated, then I would like to see
a set of use cases included in this document as justification.  I suspect
that would be a sub-set of what is already there; one of my comments
related to I-D.ietf-bfd-seamless-use-case was that "not all the use cases
seem to add new requirements, they are just examples of different
instances of expressing the same need".

Thanks!

Alvaro.

[1] 
https://mailarchive.ietf.org/arch/msg/rtg-bfd/kin3Me4WrKbe9WljhkSfkKvsefA

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 8 Dec 2015 16:29:22 +0000

Thanks Alvaro for the response — please see inline.

> On Dec 8, 2015, at 11:14 AM, Alvaro Retana (aretana) <[email-masked]> wrote:
> 
> On 12/8/15, 10:12 AM, "Carlos Pignataro (cpignata)" <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> Hi!
> 
>> 
> solves.  Vs just extending BFD because we can.

I thought that was already clear from the Intro/Abstract, even if quite concise.

If needed, a bit of text modeled after the shepherd write-up can complete:

   This document defines a simplified mechanism to use Bidirectional
   Forwarding Detection (BFD) with large portions of negotiation aspects
   eliminated, thus providing benefits such as quick provisioning as
   well as improved control and flexibility to network nodes initiating
   the path monitoring.

>  Which is why I suggested

What is holding the decision on publication of I-D.ietf-bfd-seamless-use-case? Based on your decision tree below, it is all pending on that decision.

> a set of use cases included in this document as justification.

I disagree with this approach. (and I disagree with the concept of having to publish text to “justify” publication, and with use cases, but not in a use-case document)

This would basically mean (exaggeration just for effect :-): “let’s not publish the use-cases document. Instead, let’s publish the use use-cases in the middle of a protocol document, so that we confuse both use cases and protocol"

> I suspect
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/kin3Me4WrKbe9WljhkSfkKvsefA <https://mailarchive.ietf.org/arch/msg/rtg-bfd/kin3Me4WrKbe9WljhkSfkKvsefA>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 8 Dec 2015 16:47:53 +0000

Santosh:

Hi!

There are 2 more things (Major) that I need you to address.  Sorry, I
almost forgot.

(A) Please take a look at the SecDir comments here [1].

[1] 
https://mailarchive.ietf.org/arch/msg/secdir/o7CSlWeRPh4-BZBTI_eDyoBM7ak

(B)

During the IESG review of draft-ietf-isis-sbfd-discriminator the question
came up about how the mapping of S-BFD discriminators (advertised by IS-IS
in that draft, but there are also similar OSPF and L2TP drafts) to
specific applications/entities is to be done.  This conversation ended up
in me placing a DISCUSS on that document [2].

The problem is that draft-ietf-isis-sbfd-discriminator (and the OSPF and
L2TP drafts) declare the mapping out of scope. *AND*  This document
(draft-ietf-bfd-seamless-base) says this in Section 3. (Seamless BFD
Overview):

   An S-BFD module on each network node allocates one or more S-BFD
   discriminators for local entities, and creates a reflector BFD
   session.  Allocated S-BFD discriminators may be advertised by
   applications (e.g., OSPF/IS-IS).  Required result is that
   applications, on other network nodes, possess the knowledge of the
   mapping from remote entities to S-BFD discriminators.  The reflector
   BFD session is to, upon receiving an S-BFD control packet targeted to
   one of local S-BFD discriminator values, transmit a response S-BFD
   control packet back to the initiator.

This text reads to me that S-BFD is expecting ("Required result") the
mapping to be somehow provided by the "applications (e.g., OSPF/IS-IS)".
Note that one possible interpretation is not for OSPF/IS-IS to "know"
anything about S-BFD discriminators/entities, but to transport that
information (similar to transporting discriminators).  I can see at least
one relevant use case (in draft-ietf-bfd-seamless-use-case) that seems to
require the ability to distinguish and map:  Section 3.8. (Multiple BFD
Sessions to Same Target).

The point to address is this: what is the expectation (from the S-BFD
point of view) with respect to the mapping?

Answering may require a WG-wide discussion.  Depending on the answer,
there may be obvious effects (and work needed) in the isis, ospf and
l2tpext WGs, so please (with the help of the chairs) work with them.

Thanks!

Alvaro.

[2] 
https://datatracker.ietf.org/doc/draft-ietf-isis-sbfd-discriminator/ballot/

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 8 Dec 2015 16:50:23 +0000

On 12/8/15, 10:10 AM, "Carlos Pignataro (cpignata)" <[email-masked]>
wrote:

Carlos:

Hi!

>>> o I-D.ietf-bfd-multipoint should clearly be Normative because of the
>>>new
>>> bfd.SessionType state variable
>What¹s your (Alvar, Jeff) view on whether this doc should define
>bfd.SessionType and not multipoint?
>
>Seems to me that it is probably best (although an almost negligible
>preference) to define it here and have multipoint referencing s-bfd.

Either way works for me.

Alvaro.

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 8 Dec 2015 12:00:55 -0800

Sorry for the top post.

Interesting to see 'use case doc' still being discussed. 

As one of the authors of the use case doc, the mixed messages I received, which was followed up with post Yoko ietf email from Jeff, the inclination was to drop the doc, unless authors wants it to be published. As none of other co-authors showed any interest or lack there of, it is not prudent to push further a WG document. Addressing Alvaro's comments require time and effort to resolve. Unless WG is  subscribed to publishing it, not worth anybody's time, either to edit or review.

Having said the above, all the existing SBFD documents NEED to clearly state the problem statement, what the ID is trying to solve and outline the requirement and also state, which 'use case' the solution is trying to solve.

For a reader to understand the ID, there needs to be a context and details pertaining to what it is trying to solve. Presently they do not as they are referencing and relying on use case doc.

Cheers
Sam

Sent from my iPhone

> On Dec 8, 2015, at 8:50 AM, Alvaro Retana (aretana) <[email-masked]> wrote:
>

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 14 Dec 2015 00:02:45 -0800

Hello Santosh, authors, Alvaro and list members,

for the quoted section 3 of draft-ietf-bfd-seamless-base it gets even 
"worse", as it says for the example in that section:

   The IS-IS with SystemID xxx (node A) allocates an S-BFD discriminator
   123, and advertises the S-BFD discriminator 123 in an IS-IS TLV.  The
   IS-IS with SystemID yyy (node D) allocates an S-BFD discriminator
   456, and advertises the S-BFD discriminator 456 in an IS-IS TLV.

So it puts the IGP (IS-IS in this case) into an authoritative role. The IS-IS 
teams respond with "whoa, wait, I'm just the messenger" :-)

Section 3 also says 

   session.

A bit if a contradiction - who is allocating now, S-BFD or the IGP?
I would think it is the S-BFD module that allocates and orchestrates. It uses 
an IGP or other means to transport discriminators to S-BFD modules on other 
nodes.

The reason is that S-BFD creates the BFD reflector, so it should know what 
this reflector is for (maybe pure IPv6, or used for specific QoS etc.). 

There is another aspect: the protocols (OSPF, IS-IS, L2TP) plan to transport 
a list of discriminators. Okay ... but how is the receiver S-BFD module 
making sense out of this list?  Would have expected something like (type, 
discriminator). The protocols don't need to understand the details, only that 
the API transports one or more of these tuples in/out of the protocol module. 
S-BFD would know/define what a particular type means.

Just asking before we send OSPF, IS-IS, L2TP into the wrong direction :-)

Regards, Marc

---

From: Santosh P K <[email-masked]>
Date: Fri, 18 Dec 2015 07:07:54 +0000

Alvaro,
    Please see my inline comments tagged [SPK]. I will send diff and updated draft after all the received review comments are addressed. 

Thanks
Santosh P K 

> -----Original Message-----
> From: Alvaro Retana (aretana) [mailto:[email-masked]]
> Sent: Tuesday, December 08, 2015 8:06 PM
> To: Santosh P K <[email-masked]>; draft-ietf-bfd-seamless-
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: AD Review of draft-ietf-bfd-seamless-base
> 
> >addressed rest of the comments from you and have attached the new
> >version and also diff between 05 and 06 version.
> 
> I looked at the proposed new text and the diffs.  I left below only the parts
> that I think still need more work, added back a couple of items and answered
> some questions.
> 
> Thanks!
> 
> Alvaro.
> 
> 
> 
> >
> >Major:
> >[I-D.ietf-bfd-seamless-use-case]."  Maybe it's just me, but I fail to
> >see how all the use cases are satisfied - in part because the
> >requirements in I-D.ietf-bfd-seamless-use-case are not clear (see my
> >review for that document), and in part because this document isn't
> >explicit about how the specification solves the use cases.  For
> >example, how does this document provide a solution for the use case in
> >section 3.6. (BFD for Anycast Address)?
> >2. Normative References
> >new bfd.SessionType state variable o I-D.ietf-bfd-generic-crypto-auth
> >should also be Normative because of how the Security Considerations are
> >written: pointing to is as a "MUST".
> >potential solutions, not as a mandate to use them.  [Disclaimer: we
> >will still need the SecDir to review.]
> >
> cases satisfied?  I'm looking forward to an updated version of I-D.ietf-bfd-
> seamless-use-case which may help.

[SPK] I don't think we have arrived at any conclusion yet on this. I will wait before addressing this comment :). 

> 
> FWIW, I agree with his comments related to the references.  And still think
> that both should be Normative.  BTW, I don't think that changing the "MUST"
> to "SHOULD" when referring to I-D.ietf-bfd-generic-crypto-auth changed
> that need.

[SPK] I have changed the text. If you have any suggestion then please let me know. 

> whether the values from rfc5880 are also valid or not.

[SPK] This is taken care. In this section I have explicitly said that all the values defined in RFC 58880 will be applicable and there MAY be more values other than that defined in RFC 5880.

> creating new variables here and not explicitly defining them?).

[SPK] Your comment in last mail was to highlight only the differences. Any variable that is used as is from RFC 5880 will not be texted here. Only state varibles which differ from RFC 5880 will be texted and so section 7.2.2 and 7.3.2 have been changed accordingly. Do I need to explicitly mention all state variables? 

> mean bfd.RemoteDiscr? BTW, I think you should explain how this variable is

[SPK] Done. 

> redundant given the header of the section.

[SPK] There are no state varibles on reflector side other than bfd.RequiredMinRxInterval and bfd.SessionState. bfd.RequiredMinRxInterval  and bfd.SessionState are just a common state variable for all the BFD session that is reflecting. That is the reason why we have text which says copy from received packet. 

> between received BFD Control packets".  IOW, the definitions don't match.

[SPK] Done.

> to point at it in a section that people may read.

[SPK] It is a security issue and we have a solution for it by overloading D bit. Hence it is put in Appendix. If you think it is worth putting in security section with solution I shall do that. 

> live in the -base doc. That is missing, and we should fill in this gap."

[SPK] There will be not much content for separate section. Any suggestion? 

> avoid the confusion altogether.

[SPK] I have removed this is confusing statement in base document. 

> needed in 7.3 and 11?  And do the procedures and security considerations

[SPK] I don't think they are required. I will remove them. 

> I think that would be nice.

[SPK] Done.

---

From: Santosh P K <[email-masked]>
Date: Fri, 18 Dec 2015 09:30:45 +0000

Marc,
   Thanks for your valuable comments :). Please see my inline comments tagged [SPK].

Thanks
Santosh P K 

> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Monday, December 14, 2015 1:33 PM
> To: Alvaro Retana <[email-masked]>; Santosh P K
> <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]
> So it puts the IGP (IS-IS in this case) into an authoritative role. The IS-IS teams
> respond with "whoa, wait, I'm just the messenger" :-)

[SPK] IGP is indeed just a messenger at least in this contest. How could we reword this to ensure that it does not look like that. You have any suggestion on this? 

> I would think it is the S-BFD module that allocates and orchestrates. It uses an
> IGP or other means to transport discriminators to S-BFD modules on other
> nodes.
> 

[SPK] Yes you are right. SBFD module will allocates the discriminator. I will correct this in document. 

> Just asking before we send OSPF, IS-IS, L2TP into the wrong direction :-)

[SPK] This is implementation specific right? Do we need this to be captured in document?

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 18 Dec 2015 12:08:28 +0000

On 12/18/15, 2:07 AM, "Santosh P K" <[email-masked]> wrote:

Santosh:

Hi!

>Please see my inline comments tagged [SPK]. I will send diff and updated
>draft after all the received review comments are addressed.

I looked at the update/diffs that you sent in a later message.

Just a couple of comments left below..

Thanks!!

Alvaro.

. . .
>> between received BFD Control packets".  IOW, the definitions don't

Yes, you made the correction in (what is now) 7.2.2, but the text in 7.2.3
still reads:

   o  S-BFD control packets transmitted by the SBFDReflector MUST have
      "Required Min RX Interval" set to a value which expresses how many
      incoming S-BFD control packets this SBFDReflector can handle.  The
      SBFDReflector can control how fast SBFInitiators will be sending
      S-BFD control packets to self by ensuring "Required Min RX
      Interval" indicates a value based on the current load.

. . .
>[SPK] It is a security issue and we have a solution for it by overloading
>D bit. Hence it is put in Appendix. If you think it is worth putting in
>security section with solution I shall do that.

You don't have to move the text, just mention it and point to the Appendix
(so people know it's there).

>[SPK] There will be not much content for separate section. Any suggestion?

If there isn't enough for a separate section, then don't make it one..it's
up to you.  I just want the differences included.

---

From: Santosh P K <[email-masked]>
Date: Fri, 18 Dec 2015 10:00:02 +0000

Hello All,
  I have made changes as per second round of review comments. There are still some open ended questions and will be addressed as and when I get answer. I have attached diff and updated document. 

Thanks
Santosh P K 

> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P K
> Sent: Friday, December 18, 2015 3:01 PM
> To: Marc Binderberger <[email-masked]>; Alvaro Retana
> <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: AD Review of draft-ietf-bfd-seamless-base
> 
> Marc,
> > So it puts the IGP (IS-IS in this case) into an authoritative role.
> > The IS-IS teams respond with "whoa, wait, I'm just the messenger" :-)
> 
> [SPK] IGP is indeed just a messenger at least in this contest. How could we
> reword this to ensure that it does not look like that. You have any suggestion
> on this?
> 
> 
> >
> > Section 3 also says
> >
> > I would think it is the S-BFD module that allocates and orchestrates.
> > It uses an IGP or other means to transport discriminators to S-BFD
> > modules on other nodes.
> >
> > The reason is that S-BFD creates the BFD reflector, so it should know
> > what this reflector is for (maybe pure IPv6, or used for specific QoS etc.).
> 
> > There is another aspect: the protocols (OSPF, IS-IS, L2TP) plan to
> > transport a list of discriminators. Okay ... but how is the receiver
> > S-BFD module making sense out of this list?  Would have expected
> > something like (type, discriminator). The protocols don't need to
> > understand the details, only that the API transports one or more of
> > these tuples in/out of the protocol module.
> > > There are 2 more things (Major) that I need you to address.  Sorry,
> > > I almost forgot.
> > >
> > > During the IESG review of draft-ietf-isis-sbfd-discriminator the
> > > question came up about how the mapping of S-BFD discriminators
> > > (advertised by IS-
> > IS
> > > specific applications/entities is to be done.  This conversation
> > > ended up in me placing a DISCUSS on that document [2].
> > >
> > > The problem is that draft-ietf-isis-sbfd-discriminator (and the OSPF
> > > and L2TP drafts) declare the mapping out of scope. *AND*  This
> > > document
> > > This text reads to me that S-BFD is expecting ("Required result")
> > > the mapping to be somehow provided by the "applications (e.g.,
> OSPF/IS-IS)".
> > > information (similar to transporting discriminators).  I can see at
> > > least one relevant use case (in draft-ietf-bfd-seamless-use-case)
> > > that seems to require the ability to distinguish and map:  Section
> > > 3.8. (Multiple BFD Sessions to Same Target).
> > >
> > > The point to address is this: what is the expectation (from the
> > > S-BFD point of view) with respect to the mapping?
> > >
> > > Answering may require a WG-wide discussion.  Depending on the
> > > answer, there may be obvious effects (and work needed) in the isis,
> > > ospf and l2tpext WGs, so please (with the help of the chairs) work with
> them.
> > >
> > >
> > > Thanks!
> > >
> > > Alvaro.
> > >
> > > [2]

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 18 Dec 2015 14:00:16 +0000

On 12/18/15, 4:30 AM, "Santosh P K" <[email-masked]> wrote:

Santosh:

Hi!

>>transport

What is implementation specific?

Right now the IGPs (generalizing: ISIS, OSPF, L2TP, etc.) are developing
drafts to only carry the discriminators.  If, as Mark suggests, the IGPs
also transport something like "type", then S-BFD would know what each
discriminator is for.

Several questions:  Is this (transporting [type, discriminator]) what is
expected from the IGPs?  If so, I assume the S-BFD module on the nodes
assigns those values for transportation, right?  How does a receiver know
what a particular type means?

Maybe the expectation from S-BFD is different...??  That is something that
needs to be clarified so the IGP work can proceed.

Thanks!

Alvaro.

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 19 Dec 2015 01:33:23 -0800

Hello Santosh, Alvaro et al.,

>> [SPK] This is implementation specific right? Do we need this to be

we could make it "just a TLV" which the IGP/L2TP transports to other S-BFD 
modules. The transport mechanism then would not need to know the inner 
structure, e.g. [type, discriminator], to function correctly.

But for S-BFD modules to interoperate we would need to define the inner 
structure of the "V" in the TLV.

Implementation specific could be if you want to have awareness of the inner 
structure in the IGP/L2TP code already, e.g. when the IGP wants to make use 
of S-BFD information it transports, for it's own purpose (shortcutting some 
API calls).

We have to ask the L2TP, OSPF, IS-IS authors if they would be fine with this 
change :-)

Regards, Marc

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 21 Dec 2015 00:25:44 +0000

I certainly agree with everyone that the IGPs are merely a transport and do not "allocate" reflector discriminators nor - for the purposes of advertising S-BFD discriminators - do they have any understanding of how S-BFD discriminators are to be used.

However, before we rush off in a direction which will invalidate any early implementations of the IGP drafts, I would like to see a justification of the need for a given node to require multiple reflector S-BFD discriminators and an explanation of what criteria would be used to determine whether the reflector should/should not respond to an Initiator S-BFD packet to a particular S-BFD reflector discriminator. Perhaps I have missed it, but to date I am not aware of any cogent explanation of this capability. The desire for multiple S-BFD discriminators seems to be made out of either:

   o An abundance of caution ("We don't know why we would need them - but if we come up with something in the future it would be nice if we didn't preclude it.")

   o Use cases which no one knows how to support (e.g. mapping a particular discriminator to a particular incoming interface or line card)

What are the requirements and what about them necessitates multiple S-BFD discriminators?

   Les

> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Marc
> Binderberger
> Sent: Saturday, December 19, 2015 1:33 AM
> To: Alvaro Retana (aretana); Santosh P K
> Cc: [email-masked]; [email-masked]; bfd-
> [email-masked]

---

From: Manav Bhatia <[email-masked]>
Date: Mon, 21 Dec 2015 09:36:12 +0530

Hi Les,

I had asked the exact same question in an offline email that i did not get
a reply for.

I can say, as the primary co-author of the base S-BFD draft that the case
for multiple SBFD discriminators stands on very tenuous grounds. The idea
was very weird and i had argued that it really was an
architectural/implementation limitation that was being addressed by way of
supporting multiple discriminators per node. Given that there are others
that share this concern I would recommend striking that off from the base
S-BFD draft. You can look at Sec 3.8 of
https://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-03#page-7 to
understand why we may want to support multiple discriminators per node.

I had conceded to that being added since i did not want to preclude the
possibility of adding that mechanism in the future. And it was felt that
this would get debated in the WG and we would go based on the consensus.

My considered opinion is to strike that off from the base draft and move
on, since S-BFD solves a real problem and should not be stalled for
something that may never end up getting implemented.

Cheers, Manav

On Mon, Dec 21, 2015 at 5:55 AM, Les Ginsberg (ginsberg) <[email-masked]

> I certainly agree with everyone that the IGPs are merely a transport and
> do not "allocate" reflector discriminators nor - for the purposes of
> advertising S-BFD discriminators - do they have any understanding of how
> S-BFD discriminators are to be used.
>
> However, before we rush off in a direction which will invalidate any early
> implementations of the IGP drafts, I would like to see a justification of
> the need for a given node to require multiple reflector S-BFD
> discriminators and an explanation of what criteria would be used to
> determine whether the reflector should/should not respond to an Initiator
> S-BFD packet to a particular S-BFD reflector discriminator. Perhaps I have
> missed it, but to date I am not aware of any cogent explanation of this
> capability. The desire for multiple S-BFD discriminators seems to be made
> out of either:
>
>    o An abundance of caution ("We don't know why we would need them - but
> if we come up with something in the future it would be nice if we didn't
> preclude it.")
>
>    o Use cases which no one knows how to support (e.g. mapping a
> particular discriminator to a particular incoming interface or line card)
>
> > >>> discriminator). The protocols don't need to understand the details,
> only
> > >>> that

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 21 Dec 2015 23:09:13 -0800

Hello Manav!

> understand why we may want to support multiple discriminators per node.

ah, that problem :-)

> something that may never end up getting implemented.

So OSPF, IS-IS, L2TP could transport a single discriminator instead of a list?

Regards, Marc

On Mon, 21 Dec 2015 09:36:12 +0530, Manav Bhatia wrote:
> On Mon, Dec 21, 2015 at 5:55 AM, Les Ginsberg (ginsberg) 
> <[email-masked]> wrote:

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 22 Dec 2015 13:24:27 +0000

Marc -

> Sent: Monday, December 21, 2015 11:09 PM
> To: Manav Bhatia; Les Ginsberg (ginsberg)
> Cc: Alvaro Retana (aretana); Santosh P K; [email-masked]; draft-ietf-bfd-
> [email-masked]; [email-masked]
> > https://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-03#page-7
> > to understand why we may want to support multiple discriminators per
> node.
> 
> ah, that problem :-)
> 
> > My considered opinion is to strike that off from the base draft and
> > move on, since S-BFD solves a real problem and should not be stalled
> > for something that may never end up getting implemented.
> 

[Les:] Perhaps - or we could leave these drafts as is - allowing the possibility of sending multiple discriminators in the future. The key would be for the base S-BFD draft to say something like "currently only support for a single discriminator per node is defined".

If in the future support for multiple discriminators is required and defined then the IGP/L2TP drafts could either:

   o Be left alone - a simple list is all that is required
   o Be revised to carry whatever additional info S-BFD requires

My point is that since we have no idea what additional info might be required in the future leaving the IGP/L2TP drafts in their current state does no harm - and restricting them to one discriminator only provides no benefit.

That said, if folks feel strongly that we should restrict the IGP/L2TP advertisement format to one discriminator I would find that acceptable.

   Les

> > I had asked the exact same question in an offline email that i did not
> > get a reply for.
> >
> > I can say, as the primary co-author of the base S-BFD draft that the
> > case for multiple SBFD discriminators stands on very tenuous grounds.
> > The idea was very weird and i had argued that it really was an
> > architectural/implementation limitation that was being addressed by
> > way of supporting multiple discriminators per node. Given that there
> > are others that share this concern I would recommend striking that off
> > from the base S-BFD draft. You can look at Sec 3.8 of
> > https://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-03#page-7
> > to understand why we may want to support multiple discriminators per
> node.
> >
> > I had conceded to that being added since i did not want to preclude
> > the possibility of adding that mechanism in the future. And it was
> > felt that this would get debated in the WG and we would go based on the
> consensus.
> >
> > My considered opinion is to strike that off from the base draft and
> > move on, since S-BFD solves a real problem and should not be stalled
> > for something that may never end up getting implemented.
> >
> > Cheers, Manav
> >
> >
> >> I certainly agree with everyone that the IGPs are merely a transport
> >> and do not "allocate" reflector discriminators nor - for the purposes
> >> of advertising S-BFD discriminators - do they have any understanding
> >> of how S-BFD discriminators are to be used.
> >>
> >> However, before we rush off in a direction which will invalidate any
> >> early implementations of the IGP drafts, I would like to see a
> >> justification of the need for a given node to require multiple
> >> reflector S-BFD discriminators and an explanation of what criteria
> >> would be used to determine whether the reflector should/should not
> >> respond to an Initiator S-BFD packet to a particular S-BFD reflector
> >> discriminator. Perhaps I have missed it, but to date I am not aware
> >> of any cogent explanation of this capability. The desire for multiple
> >> S-BFD discriminators seems to be made out of either:
> >>
> >>    o An abundance of caution ("We don't know why we would need them -
> >> but if we come up with something in the future it would be nice if we
> >> didn't preclude it.")
> >>
> >>> modules. The transport mechanism then would not need to know the
> >>> inner structure, e.g. [type, discriminator], to function correctly.
> >>>
> >>> But for S-BFD modules to interoperate we would need to define the
> >>> inner structure of the "V" in the TLV.
> >>>
> >>> Implementation specific could be if you want to have awareness of
> >>> the
> >> inner
> >>> structure in the IGP/L2TP code already, e.g. when the IGP wants to
> >>> make
> >> use
> >>> of S-BFD information it transports, for it's own purpose
> >>> (shortcutting
> >> some
> >>> API calls).
> >>>
> >>>
> >>> We have to ask the L2TP, OSPF, IS-IS authors if they would be fine
> >>> with
> >> this
> >>> change :-)
> >>>
> >>>
> >>> Regards, Marc
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> >>> There is another aspect: the protocols (OSPF, IS-IS, L2TP) plan
> >>> >>> to transport a list of discriminators. Okay ... but how is the
> >>> >>> receiver S-BFD
> >> module
> >>> >>> making sense out of this list?  Would have expected something
> >>> >>> like
> >>> (type,
> >>> > drafts to only carry the discriminators.  If, as Mark suggests,
> >>> > the
> >> IGPs
> >>> > also transport something like "type", then S-BFD would know what
> >>> > each discriminator is for.
> >>> >
> >>> > Several questions:  Is this (transporting [type, discriminator])
> >>> > what
> >> is
> >>> > expected from the IGPs?  If so, I assume the S-BFD module on the
> >>> > nodes assigns those values for transportation, right?  How does a
> >>> > receiver
> >> know
> >>> > Maybe the expectation from S-BFD is different...??  That is
> >>> > something
> >> that

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 22 Dec 2015 20:19:13 +0530

Hi Marc,

Its been a long time since we played bfd-bfd, eh ?! :-)

> to

Yup, my lord.

And i was convinced by some folks working for the same vendor to include
the possibility of supporting multiple discriminators per node since the
line cards can keep conking off ! ;-)

> So OSPF, IS-IS, L2TP could transport a single discriminator instead of a

Yup, that would be the flavor of my argument.

Cheers, Manav

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 22 Dec 2015 20:35:54 +0530

Les,

> [Les:] Perhaps - or we could leave these drafts as is - allowing the
> possibility of sending multiple discriminators in the future. The key would
> be for the base S-BFD draft to say something like "currently only support
> for a single discriminator per node is defined".
>

The problem as i see is this:

1. The use case for supporting multiple discriminators per node imo is
pretty contrived. I havent yet heard a compelling argument of why we need
to support that.

2. The bigger problem is to see how the multiple discriminators can be
mapped to the respective end-points. If IGPs advertise multiple
discriminators, then we would map all those to the same node, and you
cannot support the use case defined in the use-case document, which
currently is the only case that requires multiple discriminators to be
advertised.

> If in the future support for multiple discriminators is required and
> defined then the IGP/L2TP drafts could either:
>

In future when we are revising  the IGP drafts to carry the additional
information then why dont we change the drafts then to advertise multiple
discriminators?

> My point is that since we have no idea what additional info might be
> required in the future leaving the IGP/L2TP drafts in their current state
> does no harm - and restricting them to one discriminator only provides no
> benefit.
>

I would not argue against this.

>
> That said, if folks feel strongly that we should restrict the IGP/L2TP
> advertisement format to one discriminator I would find that acceptable.
>

Likewise, if folks feel that we should keep the IGP drafts as is, i would
find that acceptable.

Cheers, Manav

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 22 Dec 2015 17:58:04 +0000

Manav –

We are mainly in agreement I think.
Inline.

From: Manav Bhatia [mailto:[email-masked]]
Sent: Tuesday, December 22, 2015 7:06 AM
To: Les Ginsberg (ginsberg)
Cc: Marc Binderberger; Alvaro Retana (aretana); Santosh P K; [email-masked]; [email-masked]; [email-masked]
Subject: Re: AD Review of draft-ietf-bfd-seamless-base

Les,

1. The use case for supporting multiple discriminators per node imo is pretty contrived. I havent yet heard a compelling argument of why we need to support that.

2. The bigger problem is to see how the multiple discriminators can be mapped to the respective end-points. If IGPs advertise multiple discriminators, then we would map all those to the same node, and you cannot support the use case defined in the use-case document, which currently is the only case that requires multiple discriminators to be advertised.

[Les:] If base S-BFD draft says “only one discriminator is supported” then IGPs will never be asked to send multiple discriminators (even though they can).

In future when we are revising  the IGP drafts to carry the additional information then why dont we change the drafts then to advertise multiple discriminators?

[Les:] LES: I am just trying to avoid modifying the IGP/L2TP drafts at this time unnecessarily. And since S-BFD will never ask to advertise multiple discriminators this seems safe.

Likewise, if folks feel that we should keep the IGP drafts as is, i would find that acceptable.

[Les:] Either way I think we are both OK. ☺

   Les

Cheers, Manav

   Les

> > <[email-masked]<mailto:[email-masked]>> wrote:
> >>> From: Rtg-bfd [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Marc
> >>> Binderberger
> >>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; bfd-
> >>> [email-masked]<mailto:[email-masked]>
> >>> > On 12/18/15, 4:30 AM, "Santosh P K" <[email-masked]<mailto:[email-masked]>> wrote:
> >>> >
> >>> > Santosh:
> >>> >
> >>> > Hi!
> >>> >

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 23 Dec 2015 06:02:04 +0530

Les,

I am fine with this as well.

Can we hear what others think on this issue and move on? In the absence of
a clear majority i would like to go ahead with the changes that you
propose, which are:

1. Remove the multiple sessions terminating on the same target example from
the use-case document.
2. Change the base s-bfd draft to only advertise 1 discriminator
3. Leave the IGP drafts as is.

Cheers, Manav

On Tue, Dec 22, 2015 at 11:28 PM, Les Ginsberg (ginsberg) <
[email-masked]> wrote:

> *From:* Manav Bhatia [mailto:[email-masked]]
> *Sent:* Tuesday, December 22, 2015 7:06 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Marc Binderberger; Alvaro Retana (aretana); Santosh P K;
> [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: AD Review of draft-ietf-bfd-seamless-base
>
>
>
> Les,
>
>
>
> >
> *[Les:] If base S-BFD draft says “only one discriminator is supported”
> then IGPs will never be asked to send multiple discriminators (even though
> they can).*
>
>
>
> *[Les:] LES: I am just trying to avoid modifying the IGP/L2TP drafts at
> this time unnecessarily. And since S-BFD will never ask to advertise
> multiple discriminators this seems safe.*
>
>
> *[Les:] Either way I think we are both OK. **J*
>
>
>
> *   Les*
>
>
>
> Cheers, Manav
>
>
>    Les
>
>
> >
> >
> > Regards, Marc
> >
> >
> >
> >

---

From: Mach Chen <[email-masked]>
Date: Wed, 23 Dec 2015 03:34:37 +0000

Hi Manav, Les and others,

Happy Holidays!

The solution below makes perfect sense to me!

Best regards,
Mach

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Manav Bhatia
Sent: Wednesday, December 23, 2015 8:32 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: AD Review of draft-ietf-bfd-seamless-base

Les,

Can we hear what others think on this issue and move on? In the absence of a clear majority i would like to go ahead with the changes that you propose, which are:

1. Remove the multiple sessions terminating on the same target example from the use-case document.
2. Change the base s-bfd draft to only advertise 1 discriminator
3. Leave the IGP drafts as is.

Cheers, Manav

On Tue, Dec 22, 2015 at 11:28 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Manav –

From: Manav Bhatia [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, December 22, 2015 7:06 AM
To: Les Ginsberg (ginsberg)
Cc: Marc Binderberger; Alvaro Retana (aretana); Santosh P K; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: AD Review of draft-ietf-bfd-seamless-base

Les,

   Les

Cheers, Manav

   Les

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 23 Dec 2015 20:35:10 -0800

Hello everyone!

> 3. Leave the IGP drafts as is.

as we have to do point (2) in any case, if the IGP drafts are changed or 
remain, I would think this is the most efficient way to get out of the 
troubles.

Makes a nice test case: send multiple S-BFD discriminators in the subtlv and 
see how the  test unit behaves ;-)

> And i was convinced by some folks working for the same vendor to include the
> possibility of supporting multiple discriminators per node since the

well, they can ;-) but the way it is implemented right now I think we can 
solve the problem without a 2nd discriminator.

Regards, Marc

On Wed, 23 Dec 2015 03:34:37 +0000, Mach Chen wrote:
> On Tue, Dec 22, 2015 at 11:28 PM, Les Ginsberg (ginsberg) 
> Cc: Marc Binderberger; Alvaro Retana (aretana); Santosh P K; 
> [email-masked]; [email-masked]; [email-masked]
>> possibility of sending multiple discriminators in the future. The key 
>> would be for the base S-BFD draft to say something like "currently only 
>> support for a single discriminator per node is defined".
>  
> [Les:] If base S-BFD draft says “only one discriminator is supported” 
> they can).
> [Les:] LES: I am just trying to avoid modifying the IGP/L2TP drafts at this 
> time unnecessarily. And since S-BFD will never ask to advertise multiple 
> discriminators this seems safe.
>> 
> [Les:] Either way I think we are both OK. J
>  
>    Les
>  
> Cheers, Manav
>> 
>>    Les
>> 
>>>
>>>
>>> Regards, Marc
>>>
>>>
>>>
>>>

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 24 Dec 2015 10:14:35 +0530

> remain, I would think this is the most efficient way to get out of the

Great. Will do that.

> solve the problem without a 2nd discriminator.

Wow. Some serious architectural changes have gone in since then and now,
eh?  ;-)

Cheers, Manav