Subject: FW: New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 8 May 2014 14:48:54 +0000

FYI - this new draft describes how to advertise S-BFD Discriminators using IS-IS.

Comments are welcomed.

    Les

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, May 08, 2014 7:46 AM
To: Mach Chen; Nobo Akiya (nobo); Mach Chen; Les Ginsberg (ginsberg); Nobo Akiya (nobo); Les Ginsberg (ginsberg)
Subject: New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt

A new version of I-D, draft-ginsberg-isis-sbfd-discriminator-00.txt
has been successfully submitted by Les Ginsberg and posted to the
IETF repository.

Name:		draft-ginsberg-isis-sbfd-discriminator
Revision:	00
Title:		Advertising S-BFD Discriminators in IS-IS
Document date:	2014-05-08
Group:		Individual Submission
Pages:		5
URL:            http://www.ietf.org/internet-drafts/draft-ginsberg-isis-sbfd-discriminator-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ginsberg-isis-sbfd-discriminator/
Htmlized:       http://tools.ietf.org/html/draft-ginsberg-isis-sbfd-discriminator-00

Abstract:
   This document defines a means of advertising one or more S-BFD
   Discriminators using the IS-IS Router Capability TLV.

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.

The IETF Secretariat

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 8 May 2014 15:25:34 -0400

> FYI - this new draft describes how to advertise S-BFD Discriminators using IS-IS.

So, the discriminators are intended to be box-wide?

I would have expected from some of the use cases that they'd be bound in
some cases to specific interfaces.

-- Jeff

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 8 May 2014 20:10:35 +0000

Jeff -

How S-BFD Discriminators get used is a subject that no doubt the BFD WG will discuss at length in the near future. However, the additional information that may be required to differentiate how - when multiple discriminators are advertised by a node - each discriminator should be used is out of scope for the IGP advertisement. This gets into the area of application information which has to be defined/standardized elsewhere and does not belong in the IGP advertisements. So the deliberate intent here as far as the IGP advertisement is to limit it to simply a list of assigned discriminators - nothing more.

    Les

> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Thursday, May 08, 2014 12:26 PM
> To: Les Ginsberg (ginsberg)
> Cc: [email-masked]; [email-masked]
> Subject: Re: FW: New Version Notification for draft-ginsberg-isis-sbfd-
> discriminator-00.txt
>

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 8 May 2014 13:26:30 -0700

Hi Jeff,

We have had very lengthy discussions on this. As Les said, we could discuss as part of BFD effort. In fact I am looking forward to such discussion :D

Cheers
Sam

Sent from my iPhone

> On May 8, 2014, at 1:10 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:
> 
> Jeff -
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 8 May 2014 16:27:12 -0400

Les,

On Thu, May 08, 2014 at 08:10:35PM +0000, Les Ginsberg (ginsberg) wrote:
> How S-BFD Discriminators get used is a subject that no doubt the BFD WG
> will discuss at length in the near future. However, the additional
> information that may be required to differentiate how - when multiple
> discriminators are advertised by a node - each discriminator should be
> used is out of scope for the IGP advertisement. This gets into the area of
> application information which has to be defined/standardized elsewhere and
> does not belong in the IGP advertisements. So the deliberate intent here
> as far as the IGP advertisement is to limit it to simply a list of
> assigned discriminators - nothing more.

I don't buy the argument, even though the underlying reasoning may not be
your responsibility. :-)

IGPs distribute node and link reachability.  The underlying mechanism that
is being used isn't even binding the information so much to the node as it
is to protocol plumbing.

If the feature is intended to be node-addressable or potentially
link-addressable is very much relevant to how the feature is developed and
used.  If we're not to the point of answering those two very basic
questions, then the IGP drafts are premature.  And almost certainly,
squatting on a code point even tentatively is premature.  I strongly suggest
moving it to TBD in the next version of the draft.

That said, I suspect the use cases will shake out very shortly and hopefully
the point will be moot in -01.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 8 May 2014 16:28:12 -0400

Sam,

> We have had very lengthy discussions on this. As Les said, we could discuss as part of BFD effort. In fact I am looking forward to such discussion :D

Fire away.  The re-chartering for S-BFD is in progress and the whole purpose
was to help move such discussion into the daylight of the working group.

-- Jeff

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 8 May 2014 20:40:22 +0000

Jeff -

The issue of IGPs advertising application information has been much discussed over the last few years. Using IGP flooding for distributing application info is "appealing" because IGP flooding has been proven to be both efficient and reliable. But it compromises the basic function of the protocol by overloading the link state database with "non-routing information".

In the case of IS-IS, the means to support using the IGP to advertise application info was addressed via GENINFO (RFC 6823) and MI (RFC 6822). So if S-BFD use cases ever evolve into something complex enough to require a full fledged set of application specific info and you think IGP flooding is your best vehicle for advertising you can then follow the guidelines defined in those two RFCs - which will include writing an S-BFD application RFC, obtaining an application ID codepoint from IANA, and using a separate instance of the protocol to advertise whatever you want. 

For the base protocols, all we intend to support is advertisement of the assigned discrominators - nothing more. This is sufficient to support use cases that the IGPs themselves may find valuable - but is certainly not sufficient to support other possible use cases - nor is it intended to be.

If your argument is that the advertisement MUST support all possible S-BFD use cases then we should simply not do this at all in the IGPs.

    Les

> Sent: Thursday, May 08, 2014 1:27 PM
> Cc: Jeffrey Haas; [email-masked]; [email-masked]

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 14 May 2014 16:07:42 +0200

hi les,

making the S-BFD discriminator a sole node-property feels a bit coarse
for my taste. i'd rather carry this in a IP prefix advertisement,
such that i have more granular control *what* (particular links/loopback etc.)
gets BFD-tested. also i'd would like that the receiver gets some idea what
address family (v4/v6) a S-BFD is related to.

/hannes

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 14 May 2014 15:22:54 +0000

Hannes -

Thanx for the comments.
I don't see how your proposal solves the problem you are attempting to address. The sender of the S-BFD packet has no control over what interface is used to receive the packet on the target node. Associating it with a prefix will not help in that regard. 

Further, the potential use of multiple S-BFD discriminator values by a given node gets into an application area that we have deliberately avoided. One can imagine that S-BFD may want to use different discriminator values for much more than just different address families - in which case the mapping between a given discriminator and a given usage will not be addressed simply by associating the discriminator with an IPv4/IPv6 address. Such cases will no doubt be discussed within BFD WG as part of the S-BFD work - but at this point we really want to keep the IGP advertisements out of this area.

   Les

> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Wednesday, May 14, 2014 7:08 AM
> Subject: Re: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-
> discriminator-00.txt
> 
> hi les,
> 
> > To: Mach Chen; Nobo Akiya (nobo); Mach Chen; Les Ginsberg (ginsberg);
> Nobo Akiya (nobo); Les Ginsberg (ginsberg)

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 14 May 2014 17:26:52 +0200

> I don't see how your proposal solves the problem you are attempting to address. The sender of the S-BFD packet has no control over what interface is used to receive the packet on the target node. A…

well it would help first endpoint discovery and pinning down BFD traffic to particular line card.

> Further, the potential use of multiple S-BFD discriminator values by a given node gets into an application area that we have deliberately avoided. One can imagine that S-BFD may want to use differe…

i am just saying 1 discriminator seems overly restrictive to me and
having support for more-than 1 would be a good idea to start with;

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 14 May 2014 11:36:41 -0400

> well it would help first endpoint discovery and pinning down BFD traffic to particular line card.

Indeed.  In the SPRING related case (or even some MPLS scenarios), traffic
may be heavily steered to a given interface.  This interface may not even be
to a router, but may be an ingress for a SFC device and that ingress is
critical for the execution of the chain.

-- Jeff

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 14 May 2014 15:40:31 +0000

Hannes -

> Sent: Wednesday, May 14, 2014 8:27 AM
> > I don't see how your proposal solves the problem you are attempting to
> address. The sender of the S-BFD packet has no control over what interface
> is used to receive the packet on the target node. Associating it with a prefix
> will not help in that regard.
> 

As I stated, the sender does not control the path to the reflector (S-BFD is not just single-hop). So we do not have the ability to control what line card will receive the packet simply by associating an S-BFD discriminator with a prefix advertisement.

> 
> > Further, the potential use of multiple S-BFD discriminator values by a
> given node gets into an application area that we have deliberately avoided.
> One can imagine that S-BFD may want to use different discriminator values
> for much more than just different address families - in which case the
> mapping between a given discriminator and a given usage will not be
> addressed simply by associating the discriminator with an IPv4/IPv6
> address. Such cases will no doubt be discussed within BFD WG as part of the
> S-BFD work - but at this point we really want to keep the IGP
> advertisements out of this area.
> >
> 

The draft allows the advertisement of multiple discriminators. How those discriminators get mapped to particular use cases is out of scope. From Section 2:

"When multiple S-BFD discriminators are
   advertised how a given discriminator is mapped to a specific use case
   is out of scope for this document."

   Les

> >>> FYI - this new draft describes how to advertise S-BFD Discriminators
> using
> >> IS-IS.
> >>>
> >>> Comments are welcomed.
> >>>
> >>>   Les
> >>>
> >>>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 14 May 2014 15:48:10 +0000

Hi Jeff,

> to a router, but may be an ingress for a SFC device and that ingress is critical
> for the execution of the chain.

In those cases, one should be sending S-BFD packet in-band, which would go through the specific interface/LC to reach the reflector session on the target node (i.e. outage will be detected regardless of the discriminator used). So having separate reflector discriminator won't be adding further benefit.

Flip side is, if a reflector is hosted on LC 1 and traffic engineered tunnel is terminating on LC2, then outage of LC1 can cause the "no S-BFD response" on the tunnel terminating on LC2. However, I would think this is a limitation with implementation.
 
-Nobo

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 14 May 2014 17:57:39 +0200

On Wed, May 14, 2014 at 03:48:10PM +0000, Nobo Akiya (nobo) wrote:
| Hi Jeff,
| 
| > On Wed, May 14, 2014 at 05:26:52PM +0200, Hannes Gredler wrote:
| > > On May 14, 2014, at 5:22 PM, Les Ginsberg (ginsberg) wrote:
| > > > Thanx for the comments.
| > > > I don't see how your proposal solves the problem you are attempting to
| > address. The sender of the S-BFD packet has no control over what interface
| > is used to receive the packet on the target node. Associating it with a prefix
| > will not help in that regard.
| > >
| > > well it would help first endpoint discovery and pinning down BFD traffic to
| > particular line card.
| > 
| > Indeed.  In the SPRING related case (or even some MPLS scenarios), traffic
| > may be heavily steered to a given interface.  This interface may not even be
| > to a router, but may be an ingress for a SFC device and that ingress is critical
| > for the execution of the chain.
| 
| In those cases, one should be sending S-BFD packet in-band, which would go through the specific interface/LC to reach the reflector session on the target node (i.e. outage will be detected regardless of the discriminator used). So having separate reflector discriminator won't be adding further benefit.
| 
| Flip side is, if a reflector is hosted on LC 1 and traffic engineered tunnel is terminating on LC2, then outage of LC1 can cause the "no S-BFD response" on the tunnel terminating on LC2. However, I would think this is a limitation with implementation.

what about AF discovery ? - how would a receiver know what AF a S-BFD session to bring up with ?

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 14 May 2014 16:15:43 +0000

Hi Hannes,

Please see in-line.

> Sent: Wednesday, May 14, 2014 11:58 AM
> To: Nobo Akiya (nobo)
> Cc: Jeffrey Haas; Les Ginsberg (ginsberg); [email-masked]; [email-masked]
> | > > > I don't see how your proposal solves the problem you are
> | > > > attempting to
> | > address. The sender of the S-BFD packet has no control over what
> | > interface is used to receive the packet on the target node.
> | > Associating it with a prefix will not help in that regard.
> | > >
> | > > well it would help first endpoint discovery and pinning down BFD
> | > > traffic to
> | > Indeed.  In the SPRING related case (or even some MPLS scenarios),
> | > traffic may be heavily steered to a given interface.  This interface
> | > may not even be to a router, but may be an ingress for a SFC device
> | > and that ingress is critical for the execution of the chain.
> |
> | In those cases, one should be sending S-BFD packet in-band, which would
> go through the specific interface/LC to reach the reflector session on the
> target node (i.e. outage will be detected regardless of the discriminator
> used). So having separate reflector discriminator won't be adding further
> benefit.
> |
> | Flip side is, if a reflector is hosted on LC 1 and traffic engineered tunnel is
> terminating on LC2, then outage of LC1 can cause the "no S-BFD response"
> on the tunnel terminating on LC2. However, I would think this is a limitation
> with implementation.
> 

I was under the impression that IP header (i.e version) can distinguish the AF if implementations required demux'ing received S-BFD packet based on AF. If I missed your point/question, do clarify.

-Nobo

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 14 May 2014 18:22:57 +0200

nobo,

assume that the advertising node only supports BFD4
and the receiving node does support only BFD6. - 
how to detect such a condition ?

/hannes

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 14 May 2014 17:02:10 +0000

Hi Hannes,

> assume that the advertising node only supports BFD4 and the receiving
> node does support only BFD6. - how to detect such a condition ?

Ah I see. You are talking about S-BFD capability.

i.e.

IPv4
IPv6
MPLSv4
MPLSv6
SR-MPLS
SR-IPv6
Etc

One doesn't necessary have to solve this via assigning and advertising different discriminator per "feature" .. you would then have to advertise what "feature" each discriminator is for, with IANA maintained "feature" value.

Other approach is for a node to advertise the capability separate from discriminator value. You would also need IANA maintained "feature" value for this.

Another approach is to not define/advertise the S-BFD capabilities, but rely on operators to provision S-BFD for only those "features" which are known to be supported by relevant network nodes.

In summary, S-BFD capability might be something needed, but that doesn't necessary have to be tied to discriminator advertisement.

Those are some possibilities that I can think of. Do you have any thoughts around this?

- Nobo

> >> Subject: Re: [Isis-wg] New Version Notification for
> >> draft-ginsberg-isis-sbfd- discriminator-00.txt
> >>
> >> | > > well it would help first endpoint discovery and pinning down
> >> | > > BFD traffic to
> >> | > Indeed.  In the SPRING related case (or even some MPLS
> >> | > scenarios), traffic may be heavily steered to a given interface.
> >> | > This interface may not even be to a router, but may be an ingress
> >> | > for a SFC device and that ingress is critical for the execution of the
> chain.
> >> |
> >> | In those cases, one should be sending S-BFD packet in-band, which
> >> | would
> >> go through the specific interface/LC to reach the reflector session
> >> on the target node (i.e. outage will be detected regardless of the
> >> discriminator used). So having separate reflector discriminator won't
> >> be adding further benefit.
> >> |
> >> | Flip side is, if a reflector is hosted on LC 1 and traffic
> >> | engineered tunnel is
> >> on the tunnel terminating on LC2. However, I would think this is a
> >> limitation with implementation.
> >>
> > I was under the impression that IP header (i.e version) can distinguish the
> AF if implementations required demux'ing received S-BFD packet based on
> AF. If I missed your point/question, do clarify.
> >
> > -Nobo
> >

---

From: Mach Chen <[email-masked]>
Date: Thu, 15 May 2014 09:21:08 +0000

Hi Nobo and Hannes,

IMHO, the capability issue should not be a S-BFD specific issue, even not BFD specified issue. It is actually a forwarding capability issue, it is about whether the target node can process IPv4, IPv6, MPLS, SR encapsulated BFD packets. 

Best regards,
Mach

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
> Sent: Thursday, May 15, 2014 1:02 AM
> To: Hannes Gredler
> draft-ginsberg-isis-sbfd-discriminator-00.txt
> 
> Hi Hannes,
> 
> One doesn't necessary have to solve this via assigning and advertising different
> discriminator per "feature" .. you would then have to advertise what "feature"
> each discriminator is for, with IANA maintained "feature" value.
> 
> Other approach is for a node to advertise the capability separate from
> discriminator value. You would also need IANA maintained "feature" value for
> this.
> 
> Another approach is to not define/advertise the S-BFD capabilities, but rely on
> operators to provision S-BFD for only those "features" which are known to be
> supported by relevant network nodes.
> 
> In summary, S-BFD capability might be something needed, but that doesn't
> necessary have to be tied to discriminator advertisement.
> 
> > >> | > address. The sender of the S-BFD packet has no control over
> > >> | > what interface is used to receive the packet on the target node.
> > >> | > This interface may not even be to a router, but may be an
> > >> | > ingress for a SFC device and that ingress is critical for the
> > >> | > execution of the
> > chain.
> > >> |
> > >> discriminator used). So having separate reflector discriminator
> > >> won't be adding further benefit.
> > >> |
> > AF if implementations required demux'ing received S-BFD packet based
> > on AF. If I missed your point/question, do clarify.
> > >
> > > -Nobo
> > >

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 15 May 2014 14:07:15 +0000

Hi Mach, Hannes, et al,

> IMHO, the capability issue should not be a S-BFD specific issue, even not
> BFD specified issue. It is actually a forwarding capability issue, it is about
> whether the target node can process IPv4, IPv6, MPLS, SR encapsulated BFD
> packets.

I agree Mach, mostly :)

I can also see one arguing that forwarding supporting X does not always mean S-BFD is supported on X. If we want to address this, then it is an S-BFD specific issue, and we _may_ want to solve this via introducing S-BFD capability advertisements.

With that said, S-BFD discriminator advertisement is one area which the capability problem can be solved, but not necessary a problem that has to be solved with S-BFD discriminator advertisement. Rather I don't think the two should be bundled together.

Let us continue the capability discussion separate from the discriminator advertisements?

-Nobo

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 20 May 2014 22:45:43 +0000

Dear All,
according to Section 7 of the S-BFD Base document differentiation among address families by S-BFD is optional and mention in connection to separate S-BFD reflectors to act as per-AF reflectors. Perhaps I've missed that part of S-BFD Base discussion but I don't see the benefit of supporting such mode. BFD control packets been AF-agnostic since RFC 5880 and I think that S-BFD should maintain that approach.

I agree with Mach that discriminators in S-BFD, as well as in BFD, are and must remain AF blind.

	Regards,
		Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Thursday, May 15, 2014 7:07 AM
To: Mach Chen; Hannes Gredler
Cc: Les Ginsberg (ginsberg); [email-masked]; [email-masked]
Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt

Hi Mach, Hannes, et al,

> IMHO, the capability issue should not be a S-BFD specific issue, even 
> not BFD specified issue. It is actually a forwarding capability issue, 
> it is about whether the target node can process IPv4, IPv6, MPLS, SR 
> encapsulated BFD packets.

I agree Mach, mostly :)

-Nobo

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 21 May 2014 01:18:06 +0000

Hi Greg,

That's true, the whole paragraph in the section 7 of S-BFD base document is just describing some possible implementation techniques. How about we change the paragraph:

[old]
   Note that incoming BFD control packets destined to BFD target
   identifier types may be IPv4, IPv6 or MPLS based.  For those BFD
   target identifier types, implementations MAY either allow the same
   reflector BFD session to handle all incoming BFD control packets in
   address family agnostic fashion, or setup multiple reflector BFD
   sessions to handle incoming BFD control packets with different
   address families.  This policy is again a local matter, and is
   outside the scope of this document.

[new]
   Note that incoming BFD control packets destined to BFD target
   identifier types may be IPv4, IPv6 or MPLS based.  How such packets
   reach an appropriate reflector BFD session is a local matter, and is
   outside the scope of this document.

-Nobo

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Tuesday, May 20, 2014 6:46 PM
> To: Nobo Akiya (nobo); Mach Chen; Hannes Gredler
> according to Section 7 of the S-BFD Base document differentiation among
> address families by S-BFD is optional and mention in connection to separate
> S-BFD reflectors to act as per-AF reflectors. Perhaps I've missed that part of
> S-BFD Base discussion but I don't see the benefit of supporting such mode.
> BFD control packets been AF-agnostic since RFC 5880 and I think that S-BFD
> should maintain that approach.
> 
> I can also see one arguing that forwarding supporting X does not always
> mean S-BFD is supported on X. If we want to address this, then it is an S-BFD
> specific issue, and we _may_ want to solve this via introducing S-BFD
> capability advertisements.
> 
> With that said, S-BFD discriminator advertisement is one area which the
> capability problem can be solved, but not necessary a problem that has to
> be solved with S-BFD discriminator advertisement. Rather I don't think the
> two should be bundled together.
>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 21 May 2014 01:21:42 +0000

Hi Nobo,
I like it.

	Regards,
		Greg

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]] 
Sent: Tuesday, May 20, 2014 6:18 PM
To: Gregory Mirsky; Mach Chen; Hannes Gredler
Cc: Les Ginsberg (ginsberg); [email-masked]; [email-masked]
Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt

Hi Greg,

[old]

[new]

-Nobo

> Subject: RE: [Isis-wg] New Version Notification for 
> according to Section 7 of the S-BFD Base document differentiation 
> among address families by S-BFD is optional and mention in connection 
> to separate S-BFD reflectors to act as per-AF reflectors. Perhaps I've 
> missed that part of S-BFD Base discussion but I don't see the benefit of supporting such mode.
> BFD control packets been AF-agnostic since RFC 5880 and I think that 
> S-BFD should maintain that approach.
> 
> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo 
> Akiya
> (nobo)
> Subject: RE: [Isis-wg] New Version Notification for 
> > IMHO, the capability issue should not be a S-BFD specific issue, 
> > even not BFD specified issue. It is actually a forwarding capability 
> > issue, it is about whether the target node can process IPv4, IPv6, 
> > MPLS, SR encapsulated BFD packets.
> 
> I agree Mach, mostly :)
> 
> I can also see one arguing that forwarding supporting X does not 
> always mean S-BFD is supported on X. If we want to address this, then 
> it is an S-BFD specific issue, and we _may_ want to solve this via 
> introducing S-BFD capability advertisements.
> 
> With that said, S-BFD discriminator advertisement is one area which 
> the capability problem can be solved, but not necessary a problem that 
> has to be solved with S-BFD discriminator advertisement. Rather I 
> don't think the two should be bundled together.
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 21 May 2014 01:24:37 +0000

Thanks for prompt response Greg.

Will incorporate the text in draft-ietf-...-01.

-Nobo

> Sent: Tuesday, May 20, 2014 9:22 PM
> That's true, the whole paragraph in the section 7 of S-BFD base document is
> just describing some possible implementation techniques. How about we
> change the paragraph:
> 
> [old]