Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[Jeffrey (Zhaohui) Zhang]

Looks good!

Thanks.
Jeffrey

From: BESS  On Behalf Of Greg Mirsky
Sent: Tuesday, August 20, 2019 1:38 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: Robert Kebler ; EXT - thomas.mo...@orange.com 
; bess-cha...@ietf.org; BESS 
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover

Hi Jeffrey,
many thanks for the most detailed explanation. Please find my notes and answers 
in-line tagged GIM5>>. Also, trimmed text to clear issues that we agree has 
been resolved already.

Attached is the new working version of the draft and the diff to highlight the 
changes.

Regards,
Greg

On Fri, Aug 9, 2019 at 1:38 PM Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>> wrote:
Hi Greg,

I've trimmed some text. Please see zzh3> below.

Zzh2> I checked the surrounding text in this draft and section 5.1.3 in 
RFC6513. I believe section 3 of this document, before its subsection 3.1 should 
be re-written as following:

Zzh2> The reason is that for the candidate set is not ordered - it's just a set 
to select from (either based on IP address or hashing).
GIM4>> Many thanks, Jeffrey! Please check the working verion or diff and let me 
know if I've correctly applied the changes.

Zzh3> There is an extra "o":

   o  The first two options select the Upstream PE from a candidate PE
  set either based on IP address or a hashing algorithm.  When used
  together   with the optional procedure of considering the P-tunnel
  status as in   this document, a candidate upstream PE is included
  in the set if it either:

   o  <-- EXTRA
GIM5>> I think I've managed to clear it.

  A.  advertise a PMSI bound to a tunnel, where the specified tunnel
  is not known to be down or up



3.1.7.  Per PE-CE link BFD Discriminator
 ...
 Zzh2> Because you still want to track the tunnel state (in addition to pe-ce 
interface state), you would need at least two discriminators - one for the 
tunnel and one for the PE-CE link. However, the new "BGP- BFD attribute" 
defined in this spec only accommodates one discriminator (and my understanding 
is that you can't have more than one of the same attribute).
GIM4>> It is implied that the PE-CE link is monitored by p2p BFD session, most 
likely as described in RFC 5881 for single-hop BFD. That would not require 
bootstrapping.

Zzh3> I was saying that if you use "Per PE-CE link BFD Discriminator", then ...
Zzh2> The simplest solution is that just use the same discriminator (vs. per 
PE-CE link discriminator). With that, the ENTIRE section 3.1.7 (including its 
subsections) become the following:
GIM4>> I'm confused by "use the same Discriminator". The root advertises its 
Discriminator to the downstream PEs. The value is only locally unique for the 
root, not for any downstream PE. For a PE-CE link, if BFD is used, each PE must 
pick its locally unique value to use it as My Discriminator. CE uses that value 
in Your Discriminator field and thus the PE demultiplexes p2p sessions using 
its locally unique value in the Your Discriminator field. Note that p2mp BFD 
session among the root and the downstream PEs is such that PEs receives BFD 
control packets with the value of Your Discriminator field zeroed, and PEs use 
a different mechanism to demultiplex p2mp BFD sessions (as described in RFC 
8562).

Zzh3> I meant that you don't use PE-CE link specific discriminator (e.g. value1 
for the tunnel status, value2 for PE-CE link1 and value3 for PE-CE link2). 
Whether you track the PE-CE link status or not, you just include the 
discriminator that corresponds to the tunnel. I don't mean that all PEs use the 
same discriminator.

3.1.7 Tracking upstream PE-CE link status

   In case the PE-CE link on an upstream PE failed, even though the provider 
tunnel is still up,
   It is desired for the downstream PEs to switch to a backup upstream PE. To 
achieve that,
   If the upstream PE detects that its PE-CE link fails, it SHOULD set the 
bfd.LocalDiag of the
   p2mp BFD session to Concatenated Path Down and/or Reverse Concatenated Path 
Down,
   unless it switches to a new PE-CE link immediately (in that case the 
upstream PE will start tracking
   the status of the new PE-CE link).
   When a downstream PE receives that bfd.LocalDiag code, it treats as if the 
tunnel itself
   failed and tries to switch to a backup PE.
GIM4>> Would the downstream PE be switching to the backup Provider Tunnel, not 
to a backup PE? If yes, that option already listed in section 3.1.7.2

Zzh3> No.
Zzh3> Take one step back. When we don't track PE-CE link status on the ingress 
PE, we only care about the tunnel status. If it is down, we don't use the 
corresponding PE. There is no "backup tunnel". There is only a "backup upstream 
PE".
Zzh3> Now add the PE-CE link to the picture. Even if the tunnel remains up but 
if the PE-CE link is down, we don't u

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[Jeffrey (Zhaohui) Zhang]

Hi Greg,

I've trimmed some text. Please see zzh3> below.

   Because all PEs may arrive at a different
   conclusion regarding the state of the tunnel,
   procedures described in Section 9.1.1 of [RFC 6513] MUST be used
   when using inclusive tunnels.
GIM3>> Got it, thx. Would s/may/could/ be acceptable to avoid questions about 
RFC2119-like language?
 Zzh2> I think it should be a MUST - otherwise you get duplicates when 
different PEs pick different upstream PEs.
GIM4>> I've tried s/may/MUST/ and it doesn't read right:
   Because all PEs MUST arrive at a different
   conclusion regarding the state of the tunnel,
   procedures described in Section 9.1.1 of [RFC 6513] MUST be used
   when using inclusive tunnels.
I'll do s/may/could/ to have this text:
   Because all PEs could arrive at a different
   conclusion regarding the state of the tunnel,
   procedures described in Section 9.1.1 of [RFC 6513] MUST be used
   when using inclusive tunnels.

Zzh3> My bad. I thought you were talking about must/MUST. "could" is fine since 
you were talking the "may".

Zzh2> I checked the surrounding text in this draft and section 5.1.3 in 
RFC6513. I believe section 3 of this document, before its subsection 3.1 should 
be re-written as following:

Zzh2> The reason is that for the candidate set is not ordered - it's just a set 
to select from (either based on IP address or hashing).
GIM4>> Many thanks, Jeffrey! Please check the working verion or diff and let me 
know if I've correctly applied the changes.

Zzh3> There is an extra "o":

   o  The first two options select the Upstream PE from a candidate PE
  set either based on IP address or a hashing algorithm.  When used
  together   with the optional procedure of considering the P-tunnel
  status as in   this document, a candidate upstream PE is included
  in the set if it either:

   o  <-- EXTRA

  A.  advertise a PMSI bound to a tunnel, where the specified tunnel
  is not known to be down or up



3.1.7.  Per PE-CE link BFD Discriminator
 ...
 Zzh2> Because you still want to track the tunnel state (in addition to pe-ce 
interface state), you would need at least two discriminators - one for the 
tunnel and one for the PE-CE link. However, the new "BGP- BFD attribute" 
defined in this spec only accommodates one discriminator (and my understanding 
is that you can't have more than one of the same attribute).
GIM4>> It is implied that the PE-CE link is monitored by p2p BFD session, most 
likely as described in RFC 5881 for single-hop BFD. That would not require 
bootstrapping.

Zzh3> I was saying that if you use "Per PE-CE link BFD Discriminator", then ...
Zzh2> The simplest solution is that just use the same discriminator (vs. per 
PE-CE link discriminator). With that, the ENTIRE section 3.1.7 (including its 
subsections) become the following:
GIM4>> I'm confused by "use the same Discriminator". The root advertises its 
Discriminator to the downstream PEs. The value is only locally unique for the 
root, not for any downstream PE. For a PE-CE link, if BFD is used, each PE must 
pick its locally unique value to use it as My Discriminator. CE uses that value 
in Your Discriminator field and thus the PE demultiplexes p2p sessions using 
its locally unique value in the Your Discriminator field. Note that p2mp BFD 
session among the root and the downstream PEs is such that PEs receives BFD 
control packets with the value of Your Discriminator field zeroed, and PEs use 
a different mechanism to demultiplex p2mp BFD sessions (as described in RFC 
8562).

Zzh3> I meant that you don't use PE-CE link specific discriminator (e.g. value1 
for the tunnel status, value2 for PE-CE link1 and value3 for PE-CE link2). 
Whether you track the PE-CE link status or not, you just include the 
discriminator that corresponds to the tunnel. I don't mean that all PEs use the 
same discriminator.

3.1.7 Tracking upstream PE-CE link status

   In case the PE-CE link on an upstream PE failed, even though the provider 
tunnel is still up,
   It is desired for the downstream PEs to switch to a backup upstream PE. To 
achieve that,
   If the upstream PE detects that its PE-CE link fails, it SHOULD set the 
bfd.LocalDiag of the
   p2mp BFD session to Concatenated Path Down and/or Reverse Concatenated Path 
Down,
   unless it switches to a new PE-CE link immediately (in that case the 
upstream PE will start tracking
   the status of the new PE-CE link).
   When a downstream PE receives that bfd.LocalDiag code, it treats as if the 
tunnel itself
   failed and tries to switch to a backup PE.
GIM4>> Would the downstream PE be switching to the backup Provider Tunnel, not 
to a backup PE? If yes, that option already listed in section 3.1.7.2

Zzh3> No.
Zzh3> Take one step back. When we don't track PE-CE link status on the ingress 
PE, we only care about the tunnel status. If it is down, we don't use the 
corresponding PE. There is no "backup tunnel". There is only a "backup 

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[Jeffrey (Zhaohui) Zhang]

Hi Greg,

Sorry for the late response.
Please see zzh2> in snipped text below.

From: Greg Mirsky 
Sent: Saturday, May 11, 2019 3:24 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: bess-cha...@ietf.org; EXT - thomas.mo...@orange.com 
; Robert Kebler ; BESS 

Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover

Hi Jeffrey,
thank you for your consideration and the detailed comments with great 
suggestions. Please find my answers below under GIM3>> tag. Attached is the 
diff to highlight the updates.

Regards,
Greg

On Tue, May 7, 2019 at 7:43 AM Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>> wrote:
Hi Greg,

Most of changes are fine; though I suggest to replace the following:

   For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is
   considered up if one or more of the P2MP RSVP-TE LSPs to the same PE,
   identified by the P-tunnel Attribute, are in Up state.

With the following:

   For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is
   considered up if the sub-LSP to this downstream PE is in Up state.
GIM3>> Accept with one question. As this is the first sentence in the section, 
what is the PE we refer to as "this downstream PE"? Should we use "a downstream 
PE"?

Zzh2> Not sure what the right word is, but the point is that it is from a 
particular downstream PE’s point of view (I remember often seeing text like 
“this router” in RFCs).

Not all comments have been addressed, though. I trimmed some text below and 
highlighted the outstanding ones with “=”. You may need to refer to 
my previous email for correlation/details.

Jeffrey

On Thu, Mar 14, 2019 at 3:04 AM Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>> wrote:
Thomas, Bob,

Some questions below for you. Some old, and some new.
 ==


Zzh> It’s not that the “rules … are not consistent”. It’s that by nature some 
PEs may think the tunnel is down while the others may think the tunnel is still 
up (because they’re on different tunnel branches), even when they follow the 
same rules. Traffic duplication in this case is also only with inclusive 
tunnels – so how about the following?

   Because all PEs may arrive at a different
   conclusion regarding the state of the tunnel,
   procedures described in Section 9.1.1 of [RFC 6513] MUST be used
   when using inclusive tunnels.
GIM3>> Got it, thx. Would s/may/could/ be acceptable to avoid questions about 
RFC2119-like language?

Zzh2> I think it should be a MUST – otherwise you get duplicates when different 
PEs pick different upstream PEs.

===
 Additionally, the text in section 3 seems to be more biased on Single 
Forwarder Election choosing the UMH with the highest IP address. Section 5 of 
RFC6513 also describes two other options, hashing or based on “installed UMH 
route” (aka unicast-based). It is not clear how the text in this document 
applies to hashing based selection, and I don’t see how the text applies to 
unicast-based selection. Some rewording/clarification are needed here.
GIM>> How would the use of an alternative UMH selection algorithm change 
documented use of p2mp BFD? Do you think that if the Upstream PE selected 
using, for example, hashing then defined use of BGP-BFD and p2mp BFD itself no 
longer applicable?

Zzh> It’s not that the alternative UMH selection algorithm change documented 
use of p2mp BFD. It’s the other way around – tunnel state changes the selection 
result. I guess hashing can still be used (this document only controls what 
goes into the candidate pool). For unicast based selection I thought it’d no 
longer work, but then I noticed the following:

   o  second, the UMH candidates that advertise a PMSI bound to a tunnel
  that is "down" -- these will thus be used as a last resort to
  ensure a graceful fallback to the basic MVPN UMH selection
  procedures in the hypothetical case where a false negative would
  occur when determining the status of all tunnels

Zzh> So this should still work, although Ideally, the PE advertising the next 
best route should be considered before going to the last resort (of using the 
PE advertising the best route but whose tunnel is down).
GIM3>> I hope I've got the idea. Below is the updated text (second becomes 
third and your proposal - second):
NEW TEXT:
   o  Second, the PE advertising the next best route is to be
  considered.

   o  Third, the UMH candidates that advertise a PMSI bound to a tunnel
  that is "down" -- these will thus be used as a last resort to
  ensure a graceful fallback to the basic MVPN UMH selection
  procedures in the hypothetical case where a false negative would
  occur when determining the status of all tunnels.

Zzh2> I checked the surrounding text in this draft and section 5.1.3 in 
RFC6513. I believe section 3 of this document, 

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[Jeffrey (Zhaohui) Zhang]

Hi Greg,

Most of changes are fine; though I suggest to replace the following:

   For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is
   considered up if one or more of the P2MP RSVP-TE LSPs to the same PE,
   identified by the P-tunnel Attribute, are in Up state.

With the following:

   For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is
   considered up if the sub-LSP to this downstream PE is in Up state.

Not all comments have been addressed, though. I trimmed some text below and 
highlighted the outstanding ones with “=”. You may need to refer to 
my previous email for correlation/details.

Jeffrey

On Thu, Mar 14, 2019 at 3:04 AM Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>> wrote:
Thomas, Bob,

Some questions below for you. Some old, and some new.
 ==


Zzh> It’s not that the “rules … are not consistent”. It’s that by nature some 
PEs may think the tunnel is down while the others may think the tunnel is still 
up (because they’re on different tunnel branches), even when they follow the 
same rules. Traffic duplication in this case is also only with inclusive 
tunnels – so how about the following?

   Because all PEs may arrive at a different
   conclusion regarding the state of the tunnel,
   procedures described in Section 9.1.1 of [RFC 6513] MUST be used
   when using inclusive tunnels.
===
 Additionally, the text in section 3 seems to be more biased on Single 
Forwarder Election choosing the UMH with the highest IP address. Section 5 of 
RFC6513 also describes two other options, hashing or based on “installed UMH 
route” (aka unicast-based). It is not clear how the text in this document 
applies to hashing based selection, and I don’t see how the text applies to 
unicast-based selection. Some rewording/clarification are needed here.
GIM>> How would the use of an alternative UMH selection algorithm change 
documented use of p2mp BFD? Do you think that if the Upstream PE selected 
using, for example, hashing then defined use of BGP-BFD and p2mp BFD itself no 
longer applicable?

Zzh> It’s not that the alternative UMH selection algorithm change documented 
use of p2mp BFD. It’s the other way around – tunnel state changes the selection 
result. I guess hashing can still be used (this document only controls what 
goes into the candidate pool). For unicast based selection I thought it’d no 
longer work, but then I noticed the following:

   o  second, the UMH candidates that advertise a PMSI bound to a tunnel
  that is "down" -- these will thus be used as a last resort to
  ensure a graceful fallback to the basic MVPN UMH selection
  procedures in the hypothetical case where a false negative would
  occur when determining the status of all tunnels

Zzh> So this should still work, although Ideally, the PE advertising the next 
best route should be considered before going to the last resort (of using the 
PE advertising the best route but whose tunnel is down).

zzh> BTW, the same applies to 3.1.7 as well.
GIM>> Agree

==

3.1.7.  Per PE-CE link BFD Discriminator

   The following approach is defined for the fast failover in response
   to the detection of PE-CE link failures, in which UMH selection for a
   given C-multicast route takes into account the state of the BFD
   session associated with the state of the upstream PE-CE link.

3.1.7.1.  Upstream PE Procedures

   For each protected PE-CE link, the upstream PE initiates a multipoint
   BFD session [I-D.ietf-bfd-multipoint] as MultipointHead toward
   downstream PEs.  A downstream PE monitors the state of the p2mp
   session as MultipointTail and MAY interpret transition of the BFD
   session into Down state as the indication of the associated PE-CE
   link being down.

Since the BFD packets are sent over the P2MP tunnel not the PE-CE link, my 
understanding is that the BFD discriminator is still for the tunnel and not 
tied to the PE-CE link; but different from the previous case, the root will 
stop sending BFD messages when it detects the PE-CE link failure. As far as the 
egress PEs are concerned, they don’t know if it is the tunnel failure or PE-CE 
link failure.

If my understanding is correct, the wording should be changed.
GIM>> There are other than stopping transmission of BFD control packets ways to 
distinguish two conditions for the egress PE. For example, the MultipointHead 
MAY set the State to AdminDown and continue sending BFD control packets. If and 
when PE-CE link restored to Up, the MultipointHead can set the state to Up in 
the BFD control packet.
= this needs more discussion =
= should be clear on which way is done – stop sending BFD message or use 
AdminDown
= an PMSI may be used for many flows, which may use different PE-CE 
interfaces on the ingress PE. A downstream PE would not know which interface it 

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[Jeffrey (Zhaohui) Zhang]

Sorry for the delay. Will take care of it this week.

Thanks.
Jeffrey

> -Original Message-
> From: Mankamana Mishra (mankamis) 
> Sent: Tuesday, March 12, 2019 12:15 PM
> To: Jeffrey (Zhaohui) Zhang 
> Cc: Greg Mirsky ; bess-cha...@ietf.org; EXT -
> thomas.mo...@orange.com ; Robert Kebler
> ; bess@ietf.org; ext-zhang.zh...@zte.com.cn
> 
> Subject: Re: [bess] WGLC,IPR and implementation poll for draft-ietf-bess-
> mvpn-fast-failover
> 
> Hi Jeffery,
> wondering if you got chance to updated text & if you are fine with it.
> 
> Mankamana
> 
> > On Feb 13, 2019, at 7:09 PM, zhang.zh...@zte.com.cn wrote:
> >
> > Hi Greg,
> >
> > Thank you very much for your clarification!
> > I made a mistake that I thought the BFD session is the base solution for UMH
> failover.
> > Now I get it. Thank you!
> > BTW: In section 3.1.2, "draft-ietf-rtgwg-bgp-pic-08" may be mentioned as
> another example like MPLS FRR.
> >
> > Thanks,
> > Sandy
> > --原始邮件--
> > 发件人：GregMirsky 
> > 收件人：张征00007940;
> > 抄送人：zzh...@juniper.net ;bess-cha...@ietf.org
> ;Thomas Morin ;Robert
> Kebler ;BESS ;
> > 日 期 ：2019年02月14日 10:38
> > 主 题 ：Re: [bess] WGLC,IPR and implementation poll for draft-ietf-bess-
> mvpn-fast-failover
> > Hi Sandy,
> > thank you for your kind consideration of the proposed updates. I've logged
> my answers under GIM3>> tag.
> >
> > Regards,
> > Greg
> >
> > On Mon, Feb 11, 2019 at 11:44 PM  wrote:
> > Hi Greg,
> > Thank you for your good modification and clarification!
> > About two sections I still have some comments, I copy the contents here
> because the mail is too long:
> > 1,
> > 3. I am confused with section 3.1.1/3.1.2/3.1.3. IMO only the X-PMSI 
> > tunnel's
> state influence the BFD session, there is no need for other decision.
> > GIM2>> The Upstream PE as MultipointHead of the p2mp BFD session may
> use a combination of conditions (the combination being determined by policy)
> to control the state of the BFD session, e.g., set it to AdminDown. I think 
> that
> the use of policy to control the conditions that affect the P-tunnel reception
> state is the advantage of the proposed solution. What do you think?
> > 4. For section 3.1.5, IMO the counter method has no relationship with the
> BFD function defined in this document. If the counter method will be used as a
> supplement for BFD session?
> > GIM2>> As above, this is one of the conditions, controlled by the policy, 
> > that
> may be considered to influence the state of the BFD session.
> > Sandy2> Since BFD packet is forwarding through by x-PMSI tunnel, egress PE
> can get the tunnel states by BFD detection timer expiration. So administrator
> may choose different policies to control the session state, but the bfd 
> packets
> detection should be the base. IMO section 3.1.1~4 are optional.
> > GIM3>> I re-read the 3.1 and I think now better understand the original 
> > idea.
> All methods listed in sub-sections, including the one that describes use of
> p2mp BFD, are alternatives, options to detect a failure in the tunnel. Would
> the following update be helpful:
> > OLD TEXT:
> > The procedure proposed here also allows that all downstream PEs don't
> > apply the same rules to define what the status of a P-tunnel is
> > (please see Section 6), and some of them will produce a result that
> > may be different for different downstream PEs.
> > NEW TEXT:
> > The optional procedures proposed in this section also allow that all
> downstream PEs don't
> > apply the same rules to define what the status of a P-tunnel is
> > (please see Section 6), and some of them will produce a result that
> > may be different for different downstream PEs.
> >
> > For section 3.1.5 counter information, how do the configurable timer work
> with the bfd detection timer? What should egress PE do with the expiration of
> the two timers when they are both used?
> > GIM3>> MPLS FRR is mentioned in the draft as an example of the "fast
> restoration mechanism". Likely, FRR will be enabled by single-hop p2p BFD per
> protected link. If that's the case, for the scenario described in this 
> sub-section,
> p2mp BFD is unnecessary.
> >
> > 2.
> > For section 3.1.7.1, the last sentence.
> > GIM2>> I think that Jeffrey asked why the new BFD Discriminator must be
> sent and the new p2mp BFD session must be initiated. Your question, as I
> interpret it, is to how operationally an implementation can minimize the
> disruption when the new 

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[Mankamana Mishra (mankamis)]

Hi Jeffery, 
wondering if you got chance to updated text & if you are fine with it. 

Mankamana 

> On Feb 13, 2019, at 7:09 PM, zhang.zh...@zte.com.cn wrote:
> 
> Hi Greg,
> 
> Thank you very much for your clarification!
> I made a mistake that I thought the BFD session is the base solution for UMH 
> failover. 
> Now I get it. Thank you!
> BTW: In section 3.1.2, "draft-ietf-rtgwg-bgp-pic-08" may be mentioned as 
> another example like MPLS FRR.
> 
> Thanks,
> Sandy
> --原始邮件--
> 发件人：GregMirsky 
> 收件人：张征7940;
> 抄送人：zzh...@juniper.net ;bess-cha...@ietf.org 
> ;Thomas Morin ;Robert Kebler 
> ;BESS ;
> 日 期 ：2019年02月14日 10:38
> 主 题 ：Re: [bess] WGLC,IPR and implementation poll for 
> draft-ietf-bess-mvpn-fast-failover
> Hi Sandy,
> thank you for your kind consideration of the proposed updates. I've logged my 
> answers under GIM3>> tag.
> 
> Regards,
> Greg
> 
> On Mon, Feb 11, 2019 at 11:44 PM  wrote:
> Hi Greg,
> Thank you for your good modification and clarification!
> About two sections I still have some comments, I copy the contents here 
> because the mail is too long:
> 1,
> 3. I am confused with section 3.1.1/3.1.2/3.1.3. IMO only the X-PMSI tunnel's 
> state influence the BFD session, there is no need for other decision.
> GIM2>> The Upstream PE as MultipointHead of the p2mp BFD session may use a 
> combination of conditions (the combination being determined by policy) to 
> control the state of the BFD session, e.g., set it to AdminDown. I think that 
> the use of policy to control the conditions that affect the P-tunnel 
> reception state is the advantage of the proposed solution. What do you think?
> 4. For section 3.1.5, IMO the counter method has no relationship with the BFD 
> function defined in this document. If the counter method will be used as a 
> supplement for BFD session?
> GIM2>> As above, this is one of the conditions, controlled by the policy, 
> that may be considered to influence the state of the BFD session.
> Sandy2> Since BFD packet is forwarding through by x-PMSI tunnel, egress PE 
> can get the tunnel states by BFD detection timer expiration. So administrator 
> may choose different policies to control the session state, but the bfd 
> packets detection should be the base. IMO section 3.1.1~4 are optional.
> GIM3>> I re-read the 3.1 and I think now better understand the original idea. 
> All methods listed in sub-sections, including the one that describes use of 
> p2mp BFD, are alternatives, options to detect a failure in the tunnel. Would 
> the following update be helpful:
> OLD TEXT:
> The procedure proposed here also allows that all downstream PEs don't
> apply the same rules to define what the status of a P-tunnel is
> (please see Section 6), and some of them will produce a result that
> may be different for different downstream PEs.
> NEW TEXT:
> The optional procedures proposed in this section also allow that all 
> downstream PEs don't
> apply the same rules to define what the status of a P-tunnel is
> (please see Section 6), and some of them will produce a result that
> may be different for different downstream PEs.
> 
> For section 3.1.5 counter information, how do the configurable timer work 
> with the bfd detection timer? What should egress PE do with the expiration of 
> the two timers when they are both used?
> GIM3>> MPLS FRR is mentioned in the draft as an example of the "fast 
> restoration mechanism". Likely, FRR will be enabled by single-hop p2p BFD per 
> protected link. If that's the case, for the scenario described in this 
> sub-section, p2mp BFD is unnecessary.
> 
> 2.
> For section 3.1.7.1, the last sentence.
> GIM2>> I think that Jeffrey asked why the new BFD Discriminator must be sent 
> and the new p2mp BFD session must be initiated. Your question, as I interpret 
> it, is to how operationally an implementation can minimize the disruption 
> when the new BFD session advertised to replace one that already exists. 
> Firstly, would we agree that sending the new BGP-BFD Discriminator and 
> starting the new p2mp BFD session when the RPF interface changes is the right 
> action? If we agree, then I can add a sentence or two to describe optional 
> procedure for the upstream PE to minimize the disruption when the egress PE 
> switches to the new p2mp BFD session.
> Sandy2>If the "old" BFD discriminator can be reused in the new advertisement 
> when the switchover is happened on a same upstream PE? If the "old" 
> discriminator can be reused, it seems like it isn't necessary to build a new 
> BFD session. But if a new BFD discriminator MUST be generated, then 

Re: [bess] WGLC,IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[zhang.zheng]

Hi Greg,

Thank you very much for your clarification!
I made a mistake that I thought the BFD session is the base solution for UMH 
failover. 
Now I get it. Thank you!
BTW: In section 3.1.2, "draft-ietf-rtgwg-bgp-pic-08" may be mentioned as 
another example like MPLS FRR.

Thanks,
Sandy
--原始邮件--
发件人：GregMirsky 
收件人：张征7940;
抄送人：zzh...@juniper.net ;bess-cha...@ietf.org 
;Thomas Morin ;Robert Kebler 
;BESS ;
日 期 ：2019年02月14日 10:38
主 题 ：Re: [bess] WGLC,IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover
Hi Sandy,
thank you for your kind consideration of the proposed updates. I've logged my 
answers under GIM3>> tag.

Regards,
Greg

On Mon, Feb 11, 2019 at 11:44 PM  wrote:
Hi Greg,
Thank you for your good modification and clarification!
About two sections I still have some comments, I copy the contents here because 
the mail is too long:
1,
3. I am confused with section 3.1.1/3.1.2/3.1.3. IMO only the X-PMSI tunnel's 
state influence the BFD session, there is no need for other decision.
GIM2>> The Upstream PE as MultipointHead of the p2mp BFD session may use a 
combination of conditions (the combination being determined by policy) to 
control the state of the BFD session, e.g., set it to AdminDown. I think that 
the use of policy to control the conditions that affect the P-tunnel reception 
state is the advantage of the proposed solution. What do you think?
4. For section 3.1.5, IMO the counter method has no relationship with the BFD 
function defined in this document. If the counter method will be used as a 
supplement for BFD session?
GIM2>> As above, this is one of the conditions, controlled by the policy, that 
may be considered to influence the state of the BFD session.
Sandy2> Since BFD packet is forwarding through by x-PMSI tunnel, egress PE can 
get the tunnel states by BFD detection timer expiration. So administrator may 
choose different policies to control the session state, but the bfd packets 
detection should be the base. IMO section 3.1.1~4 are optional.
GIM3>> I re-read the 3.1 and I think now better understand the original idea. 
All methods listed in sub-sections, including the one that describes use of 
p2mp BFD, are alternatives, options to detect a failure in the tunnel. Would 
the following update be helpful:
OLD TEXT:
The procedure proposed here also allows that all downstream PEs don't
apply the same rules to define what the status of a P-tunnel is
(please see Section 6), and some of them will produce a result that
may be different for different downstream PEs.
NEW TEXT:
The optional procedures proposed in this section also allow that all downstream 
PEs don't
apply the same rules to define what the status of a P-tunnel is
(please see Section 6), and some of them will produce a result that
may be different for different downstream PEs.

For section 3.1.5 counter information, how do the configurable timer work with 
the bfd detection timer? What should egress PE do with the expiration of the 
two timers when they are both used?
GIM3>> MPLS FRR is mentioned in the draft as an example of the "fast 
restoration mechanism". Likely, FRR will be enabled by single-hop p2p BFD per 
protected link. If that's the case, for the scenario described in this 
sub-section, p2mp BFD is unnecessary.

2.
For section 3.1.7.1, the last sentence.
GIM2>> I think that Jeffrey asked why the new BFD Discriminator must be sent 
and the new p2mp BFD session must be initiated. Your question, as I interpret 
it, is to how operationally an implementation can minimize the disruption when 
the new BFD session advertised to replace one that already exists. Firstly, 
would we agree that sending the new BGP-BFD Discriminator and starting the new 
p2mp BFD session when the RPF interface changes is the right action? If we 
agree, then I can add a sentence or two to describe optional procedure for the 
upstream PE to minimize the disruption when the egress PE switches to the new 
p2mp BFD session.
Sandy2>If the "old" BFD discriminator can be reused in the new advertisement 
when the switchover is happened on a same upstream PE? If the "old" 
discriminator can be reused, it seems like it isn't necessary to build a new 
BFD session. But if a new BFD discriminator MUST be generated, then the new add 
sentence looks good to me.
GIM3>> Would the following update to the last paragraph address your concern:
OLD TEXT:
If the route to the
src/RP changes such that the RPF interface is changed to be a new PE-
CE interface, then the upstream PE will update the S-PMSI A-D route
with included BGP-BFD Attribute so that value of the BFD
Discriminator is associated with the new RPF link.
NEW TEXT:
If the route to the
src/RP changes such that the RPF interface is changed to be a new PE-
CE interface, then the upstream PE will update the S-PMSI A-D route
with included BGP-BFD Attribute so that the p

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[Greg Mirsky]

Hi Sandy,
thank you for your kind consideration of the proposed updates. I've logged
my answers under GIM3>> tag.

Regards,
Greg

On Mon, Feb 11, 2019 at 11:44 PM  wrote:

> Hi Greg,
>
> Thank you for your good modification and clarification!
> About two sections I still have some comments, I copy the contents here
> because the mail is too long:
> 1,
> 3. I am confused with section 3.1.1/3.1.2/3.1.3. IMO only the X-PMSI
> tunnel's state influence the BFD session, there is no need for other
> decision.
> GIM2>> The Upstream PE as MultipointHead of the p2mp BFD session may use a
> combination of conditions (the combination being determined by policy) to
> control the state of the BFD session, e.g., set it to AdminDown. I think
> that the use of policy to control the conditions that affect the P-tunnel
> reception state is the advantage of the proposed solution. What do you
> think?
> 4. For section 3.1.5, IMO the counter method has no relationship with the
> BFD function defined in this document. If the counter method will be used
> as a supplement for BFD session?
> GIM2>> As above, this is one of the conditions, controlled by the policy,
> that may be considered to influence the state of the BFD session.
> Sandy2> Since BFD packet is forwarding through by x-PMSI tunnel, egress PE
> can get the tunnel states by BFD detection timer expiration. So
> administrator may choose different policies to control the session state,
> but the bfd packets detection should be the base. IMO section 3.1.1~4 are
> optional.
>
GIM3>> I re-read the 3.1 and I think now better understand the original
idea. All methods listed in sub-sections, including the one that describes
use of p2mp BFD, are alternatives, options to detect a failure in the
tunnel. Would the following update be helpful:
OLD TEXT:
   The procedure proposed here also allows that all downstream PEs don't
   apply the same rules to define what the status of a P-tunnel is
   (please see Section 6), and some of them will produce a result that
   may be different for different downstream PEs.
NEW TEXT:
   The optional procedures proposed in this section also allow that all
downstream PEs don't
   apply the same rules to define what the status of a P-tunnel is
   (please see Section 6), and some of them will produce a result that
   may be different for different downstream PEs.

For section 3.1.5 counter information, how do the configurable timer work
> with the bfd detection timer? What should egress PE do with the expiration
> of the two timers when they are both used?
>
GIM3>> MPLS FRR is mentioned in the draft as an example of the "fast
restoration mechanism". Likely, FRR will be enabled by single-hop p2p BFD
per protected link. If that's the case, for the scenario described in this
sub-section, p2mp BFD is unnecessary.

>
> 2.
> For section 3.1.7.1, the last sentence.
> GIM2>> I think that Jeffrey asked why the new BFD Discriminator must be
> sent and the new p2mp BFD session must be initiated. Your question, as I
> interpret it, is to how operationally an implementation can minimize the
> disruption when the new BFD session advertised to replace one that already
> exists. Firstly, would we agree that sending the new BGP-BFD Discriminator
> and starting the new p2mp BFD session when the RPF interface changes is the
> right action? If we agree, then I can add a sentence or two to describe
> optional procedure for the upstream PE to minimize the disruption when the
> egress PE switches to the new p2mp BFD session.
> Sandy2>If the "old" BFD discriminator can be reused in the new
> advertisement when the switchover is happened on a same upstream PE? If the
> "old" discriminator can be reused, it seems like it isn't necessary to
> build a new BFD session. But if a new BFD discriminator MUST be generated,
> then the new add sentence looks good to me.
>
GIM3>> Would the following update to the last paragraph address your
concern:
OLD TEXT:
   If the route to the
   src/RP changes such that the RPF interface is changed to be a new PE-
   CE interface, then the upstream PE will update the S-PMSI A-D route
   with included BGP-BFD Attribute so that value of the BFD
   Discriminator is associated with the new RPF link.
NEW TEXT:
   If the route to the
   src/RP changes such that the RPF interface is changed to be a new PE-
   CE interface, then the upstream PE will update the S-PMSI A-D route
   with included BGP-BFD Attribute so that the previously advertised value
of the BFD
   Discriminator is associated with the new RPF link.

>
> Thanks,
> Sandy
>
> ------原始邮件------
> 发件人：GregMirsky 
> 收件人：张征7940;
> 抄送人：zzh...@juniper.net ;bess-cha...@ietf.org <
> bess-cha...@ietf.org>;Thomas Morin ;

Re: [bess] WGLC,IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[zhang.zheng]

Hi Greg,

Thank you for your good modification and clarification!
About two sections I still have some comments, I copy the contents here because 
the mail is too long:
1,
3. I am confused with section 3.1.1/3.1.2/3.1.3. IMO only the X-PMSI tunnel's 
state influence the BFD session, there is no need for other decision. 
GIM2>> The Upstream PE as MultipointHead of the p2mp BFD session may use a 
combination of conditions (the combination being determined by policy) to 
control the state of the BFD session, e.g., set it to AdminDown. I think that 
the use of policy to control the conditions that affect the P-tunnel reception 
state is the advantage of the proposed solution. What do you think?
4. For section 3.1.5, IMO the counter method has no relationship with the BFD 
function defined in this document. If the counter method will be used as a 
supplement for BFD session?
GIM2>> As above, this is one of the conditions, controlled by the policy, that 
may be considered to influence the state of the BFD session.
Sandy2> Since BFD packet is forwarding through by x-PMSI tunnel, egress PE can 
get the tunnel states by BFD detection timer expiration. So administrator may 
choose different policies to control the session state, but the bfd packets 
detection should be the base. IMO section 3.1.1~4 are optional. 
For section 3.1.5 counter information, how do the configurable timer work with 
the bfd detection timer? What should egress PE do with the expiration of the 
two timers when they are both used?

2.
For section 3.1.7.1, the last sentence.
GIM2>> I think that Jeffrey asked why the new BFD Discriminator must be sent 
and the new p2mp BFD session must be initiated. Your question, as I interpret 
it, is to how operationally an implementation can minimize the disruption when 
the new BFD session advertised to replace one that already exists. Firstly, 
would we agree that sending the new BGP-BFD Discriminator and starting the new 
p2mp BFD session when the RPF interface changes is the right action? If we 
agree, then I can add a sentence or two to describe optional procedure for the 
upstream PE to minimize the disruption when the egress PE switches to the new 
p2mp BFD session.
Sandy2>If the "old" BFD discriminator can be reused in the new advertisement 
when the switchover is happened on a same upstream PE? If the "old" 
discriminator can be reused, it seems like it isn't necessary to build a new 
BFD session. But if a new BFD discriminator MUST be generated, then the new add 
sentence looks good to me.

Thanks,
Sandy

--原始邮件--
发件人：GregMirsky 
收件人：张征7940;
抄送人：zzh...@juniper.net ;bess-cha...@ietf.org 
;Thomas Morin ;Robert Kebler 
;BESS ;
日 期 ：2019年02月07日 08:16
主 题 ：Re: [bess] WGLC,IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover
Hi Sandy,much appreciate your comments. Please find my answers below tagged 
GIM2>>.
Attached, please find the updated working version and the diff to the last 
published version.

Kind regards,
Greg

On Thu, Jan 31, 2019 at 7:40 PM  wrote:
Hi Greg, Jeffrey, co-authors,

About the questions provided by Jeffrey, I have some concerns, please see below 
with Sandy>.
And I have some other questions:
1. According to "draft-ietf-bfd-multipoint-19" and the function defined in this 
draft, IMO the BFD session should be demultiplexed by the combination of 
upstream peer address, the discriminator and the X-PMSI which is used for flow 
forwarding. IMO these content should be written in the draft clearly.
GIM2>> Agreed and to clarify I propose the following update to the Downstream 
PE Procedures:
OLD TEXT:
On receiving the BGP-BFD Attribute in the x-PMSI A-D Route, the
Downstream PE:

o  MUST associate the received BFD discriminator value with the
P-tunnel originating from the Root PE;

o  MUST create p2mp BFD session and set bfd.SessionType =
MultipointTail as described in [I-D.ietf-bfd-multipoint];

o  MUST use the source IP address of a BFD control packet, the value
of BFD Discriminator from the BGP-BFD Attribute to properly
demultiplex BFD sessions;

NEW TEXT:
Upon receiving the BGP-BFD Attribute in the x-PMSI A-D Route, the
Downstream PE:

o  MUST associate the received BFD discriminator value with the
P-tunnel originating from the Root PE and the IP address of the
Upstream PE;

o  MUST create p2mp BFD session and set bfd.SessionType =
MultipointTail as described in [I-D.ietf-bfd-multipoint];

o  MUST use the source IP address of the BFD control packet, the
value of the BFD Discriminator field, and the x-PMSI tunnel
identifier the BFD control packet was received to properly
demultiplex BFD sessions.

2. The P2MP BFD packet should be delivered in the X-PMSI tunnel. The BFD 
multicast packet MUST be encapsulated in associated tunnel. It seems like there 
is no specifiction for it.
GIM2>> Agree and to clarify I propose the following text to be added to the 
Upstream

Re: [bess] WGLC,IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[zhang.zheng]

Hi Greg, Jeffrey, co-authors,







About the questions provided by Jeffrey, I have some concerns, please see below 
with Sandy>.


And I have some other questions:


1. According to "draft-ietf-bfd-multipoint-19" and the function defined in this 
draft, IMO the BFD session should be demultiplexed by the combination of 
upstream peer address, the discriminator and the X-PMSI which is used for flow 
forwarding. IMO these content should be written in the draft clearly.



2. The P2MP BFD packet should be delivered in the X-PMSI tunnel. The BFD 
multicast packet MUST be encapsulated in associated tunnel. It seems like there 
is no specifiction for it. 


3. I am confused with section 3.1.1/3.1.2/3.1.3. IMO only the X-PMSI tunnel's 
state influence the BFD session, there is no need for other decision. 


4. For section 3.1.5, IMO the counter method has no relationship with the BFD 
function defined in this document. If the counter method will be used as a 
supplement for BFD session?






Thanks,


Sandy



原始邮件



发件人：GregMirsky 
收件人：zzh...@juniper.net ;
抄送人：bess-cha...@ietf.org ;Thomas Morin 
;Robert Kebler ;BESS 
;
日 期 ：2018年12月06日 02:38
主 题 ：Re: [bess] WGLC,IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess







Hi Jeffrey,thank you for the review, detailed questions and helpful comments. 
Please find my notes, answers in-line tagged GIM>>.

Regards,
Greg



On Fri, Nov 30, 2018 at 5:14 PM Jeffrey (Zhaohui) Zhang  
wrote:




Hi,


 


I have the following questions/comments:


 


   The procedure described here is an OPTIONAL procedure that consists


   of having a downstream PE take into account the status of P-tunnels


   rooted at each possible upstream PEs, for including or not including


   each given PE in the list of candidate UMHs for a given (C-S,C-G)


   state.  The result is that, if a P-tunnel is "down" (see


   Section 3.1), the PE that is the root of the P-tunnel will not be


   considered for UMH selection, which will result in the downstream PE


   to failover to the upstream PE which is next in the list of


   candidates.


 


Is it possible that a p2mp tunnel is considered up by some leaves  but down by 
some other leaves, leaving to them choosing different UMH? In that case, 
procedures described in Section 9.1.1 ("Discarding Packets from Wrong PE") of 
RFC 6513 must be used. I see that this is actually pointed out later in section 
6 – good to have  a pointer to it right here.



GIM>> Would the following new text that follows the quoted text address your 
concern:
NEW TEXT: 
   If rules to determine the state of the P-tunnel are not
   consistent across all PEs, then some may arrive at a different
   conclusion regarding the state of the tunnel, In such a scenario,
   procedures described in Section 9.1.1 of [RFC 6513] MUST be used.

Sandy> I think Jeffrey means that a egress PE may choose a new UMH after the 
the "old" UMH fails. Then the egress PE may also receive (C-S, C-G) flows from 
old UMH p-tunnel, these flows MUST be discarded according to section 9.1.1 of 
RFC6513. 








 


Additionally, the text in section 3 seems to be more biased on Single  
Forwarder Election choosing the UMH with the highest IP address. Section 5 of 
RFC6513 also describes two other options, hashing or based on “installed UMH 
route” (aka unicast-based). It is not clear how the text in this document 
applies to hashing based selection,  and I don’t see how the text applies to 
unicast-based selection. Some rewording/clarification are needed here.



GIM>> How would the use of an alternative UMH selection algorithm change 
documented use of p2mp BFD? Do you think that if the Upstream PE selected 
using, for example, hashing then defined use of BGP-BFD and p2mp BFD itself no 
longer applicable?

Sandy> Diffrent UMH selection methods don't influent p2mp BFD documented in 
this draft. IMO both of section 3 and section 5 need to be mentioned here in 
order to avoid confusion.







 


   For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is


   considered up if one or more of the P2MP RSVP-TE LSPs, identified by


   the P-tunnel Attribute, are in Up state. 


 


Why is “one or more of …” used in the above text?



GIM>> Would s/one or more of/at least one of/ address your concern? 

Sandy> I am not sure there are the situations that  two or more LSPs are used 
to deliver a same (C-S, C-G). IMO only the LSP used by forwarding need to be 
mointor in egress PE. 







 


There are several occurrences of ((S, G)). I assume they should be  changed to 
(C-S, C-G).



GIM>> Indeed, globally replaced s/((S,G))/(C-S,C-G)/ 






 


   A PE can be removed from the UMH candidate list for a given ((S, G))


   if the P-tunnel for this (S, G) (I or S , dep

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[stephane.litkowski]

Hi WG,

The WGLC poll is over. Authors have now to address Jeffrey's comment before 
moving forward.

Brgds,


From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Thursday, November 22, 2018 08:54
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover


Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-mvpn-fast-failover-04  [1]



This poll runs until *the 6th of December*.



We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this Document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.



Currently two IPRs have been disclosed against this Document.



If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw




_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[Greg Mirsky]

Hi Jeffrey,
thank you for the review, detailed questions and helpful comments. Please
find my notes, answers in-line tagged GIM>>.

Regards,
Greg

On Fri, Nov 30, 2018 at 5:14 PM Jeffrey (Zhaohui) Zhang 
wrote:

> Hi,
>
>
>
> I have the following questions/comments:
>
>
>
>The procedure described here is an OPTIONAL procedure that consists
>
>of having a downstream PE take into account the status of P-tunnels
>
>rooted at each possible upstream PEs, for including or not including
>
>each given PE in the list of candidate UMHs for a given (C-S,C-G)
>
>state.  The result is that, if a P-tunnel is "down" (see
>
>Section 3.1), the PE that is the root of the P-tunnel will not be
>
>considered for UMH selection, which will result in the downstream PE
>
>to failover to the upstream PE which is next in the list of
>
>candidates.
>
>
>
> Is it possible that a p2mp tunnel is considered up by some leaves but down
> by some other leaves, leaving to them choosing different UMH? In that case,
> procedures described in Section 9.1.1 ("Discarding Packets from Wrong PE")
> of RFC 6513 must be used. I see that this is actually pointed out later in
> section 6 – good to have a pointer to it right here.
>
GIM>> Would the following new text that follows the quoted text address
your concern:
NEW TEXT:
   If rules to determine the state of the P-tunnel are not
   consistent across all PEs, then some may arrive at a different
   conclusion regarding the state of the tunnel, In such a scenario,
   procedures described in Section 9.1.1 of [RFC 6513] MUST be used.

>
>
> Additionally, the text in section 3 seems to be more biased on Single
> Forwarder Election choosing the UMH with the highest IP address. Section 5
> of RFC6513 also describes two other options, hashing or based on “installed
> UMH route” (aka unicast-based). It is not clear how the text in this
> document applies to hashing based selection, and I don’t see how the text
> applies to unicast-based selection. Some rewording/clarification are needed
> here.
>
GIM>> How would the use of an alternative UMH selection algorithm change
documented use of p2mp BFD? Do you think that if the Upstream PE selected
using, for example, hashing then defined use of BGP-BFD and p2mp BFD itself
no longer applicable?

>
>
>For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is
>
>considered up if one or more of the P2MP RSVP-TE LSPs, identified by
>
>the P-tunnel Attribute, are in Up state.
>
>
>
> Why is “one or more of …” used in the above text?
>
GIM>> Would s/one or more of/at least one of/ address your concern?

>
>
> There are several occurrences of ((S, G)). I assume they should be changed
> to (C-S, C-G).
>
GIM>> Indeed, globally replaced s/((S,G))/(C-S,C-G)/

>
>
>A PE can be removed from the UMH candidate list for a given ((S, G))
>
>if the P-tunnel for this (S, G) (I or S , depending) is leaf
>
>triggered (PIM, mLDP)
>
>
>
> Perhaps either remove the (I or S , depending)or move it to before the
> “for”.
>
GIM>> Moved before the "for".

>
>
>This document defines the format and ways of usingr a new BGP
>
>attribute called the "BGP- BFD attribute".
>
>
>
> s/usingr/using/
>
GIM>> Yes, great catch.

>
>
>o  MUST use [Ed.note] address as destination IP address when
>
>   transmitting BFD control packets;
>
>
>
> [Ed.note]?
>
GIM>> Replaced [Ed.note] to make it as follows:
o  MUST use address in 127.0.0.0/8 range for IPv4 or in
  0:0:0:0:0::7F00:0/104 range for IPv6 as destination IP address
  when transmitting BFD control packets;

>
>
>If tracking of the P-tunnel by using a p2mp BFD session is to be
>
>enabled after the P-tunnel has been already signaled, the the
>
>procedure described above MUST be followed.
>
>
>
> What if the tracking is to be enabled before the P-tunnel has been
> signaled? The text implies different behavior?
>
GIM>> Not really, I guess. I think that the second sentence is important:
   Note that x-PMSI A-D Route MUST be re-sent with exactly the same
attributes as before and
   the BGP-BFD Attribute included.

> s/the the/then the/
>
GIM>> Done.

>
>
>… The dedicated p2mp BFD session MAY monitor the state of
>
>the Standby Upstream PE.
>
>
>
> What does the above text mean? Do you mean “A different p2mp BFD session
> …”?
>
GIM>> Yes, thank you for the suggested re-wording. Applied s/The
dedicated/A different/

>
>
>When such a procedure is used, in the context where fast restoration
>
>mechanisms are used for the P-tunnels, leaf PEs should be configured
>
>to wait before updating the UMH, to let the P-tunnel restoration
>
>mechanism happen.  A configurable timer MUST be provided for this
>
>purpose, and it is recommended to provide a reasonable default value
>
>for this timer.
>
>
>
> What does “such a procedure” refers to?
>
GIM>> Would s/When such a procedure is used/In such a scenario/

> 

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[Jeffrey (Zhaohui) Zhang]

Hi,

I have the following questions/comments:

   The procedure described here is an OPTIONAL procedure that consists
   of having a downstream PE take into account the status of P-tunnels
   rooted at each possible upstream PEs, for including or not including
   each given PE in the list of candidate UMHs for a given (C-S,C-G)
   state.  The result is that, if a P-tunnel is "down" (see
   Section 3.1), the PE that is the root of the P-tunnel will not be
   considered for UMH selection, which will result in the downstream PE
   to failover to the upstream PE which is next in the list of
   candidates.

Is it possible that a p2mp tunnel is considered up by some leaves but down by 
some other leaves, leaving to them choosing different UMH? In that case, 
procedures described in Section 9.1.1 ("Discarding Packets from Wrong PE") of 
RFC 6513 must be used. I see that this is actually pointed out later in section 
6 - good to have a pointer to it right here.

Additionally, the text in section 3 seems to be more biased on Single Forwarder 
Election choosing the UMH with the highest IP address. Section 5 of RFC6513 
also describes two other options, hashing or based on "installed UMH route" 
(aka unicast-based). It is not clear how the text in this document applies to 
hashing based selection, and I don't see how the text applies to unicast-based 
selection. Some rewording/clarification are needed here.

   For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is
   considered up if one or more of the P2MP RSVP-TE LSPs, identified by
   the P-tunnel Attribute, are in Up state.

Why is "one or more of ..." used in the above text?

There are several occurrences of ((S, G)). I assume they should be changed to 
(C-S, C-G).

   A PE can be removed from the UMH candidate list for a given ((S, G))
   if the P-tunnel for this (S, G) (I or S , depending) is leaf
   triggered (PIM, mLDP)

Perhaps either remove the (I or S , depending)or move it to before the "for".

   This document defines the format and ways of usingr a new BGP
   attribute called the "BGP- BFD attribute".

s/usingr/using/

   o  MUST use [Ed.note] address as destination IP address when
  transmitting BFD control packets;

[Ed.note]?

   If tracking of the P-tunnel by using a p2mp BFD session is to be
   enabled after the P-tunnel has been already signaled, the the
   procedure described above MUST be followed.

What if the tracking is to be enabled before the P-tunnel has been signaled? 
The text implies different behavior?
s/the the/then the/

   ... The dedicated p2mp BFD session MAY monitor the state of
   the Standby Upstream PE.

What does the above text mean? Do you mean "A different p2mp BFD session "?

   When such a procedure is used, in the context where fast restoration
   mechanisms are used for the P-tunnels, leaf PEs should be configured
   to wait before updating the UMH, to let the P-tunnel restoration
   mechanism happen.  A configurable timer MUST be provided for this
   purpose, and it is recommended to provide a reasonable default value
   for this timer.

What does "such a procedure" refers to?
s/recommended/RECOMMENDED/?

3.1.7.  Per PE-CE link BFD Discriminator

   The following approach is defined for the fast failover in response
   to the detection of PE-CE link failures, in which UMH selection for a
   given C-multicast route takes into account the state of the BFD
   session associated with the state of the upstream PE-CE link.

3.1.7.1.  Upstream PE Procedures

   For each protected PE-CE link, the upstream PE initiates a multipoint
   BFD session [I-D.ietf-bfd-multipoint] as MultipointHead toward
   downstream PEs.  A downstream PE monitors the state of the p2mp
   session as MultipointTail and MAY interpret transition of the BFD
   session into Down state as the indication of the associated PE-CE
   link being down.

Since the BFD packets are sent over the P2MP tunnel not the PE-CE link, my 
understanding is that the BFD discriminator is still for the tunnel and not 
tied to the PE-CE link; but different from the previous case, the root will 
stop sending BFD messages when it detects the PE-CE link failure. As far as the 
egress PEs are concerned, they don't know if it is the tunnel failure or PE-CE 
link failure.

If my understanding is correct, the wording should be changed.

   ...  If the route to the
   src/RP changes such that the RPF interface is changed to be a new PE-
   CE interface, then the upstream PE will update the S-PMSI A-D route
   with included BGP-BFD Attribute so that value of the BFD
   Discriminator is associated with the new RPF link.

If the RPF interface changes on the upstream PE, why should it update the route 
to send a new discriminator? As long as there is a new RPF interface couldn't 
the upstream PE do nothing but start tracking the new RPF interface?

Regardless which way (the currently described way and my imagined way), some 
text should be added to discuss how the 

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[Robert Kebler]

Hi,
I'm not aware of any undisclosed IPR related to this draft.

We have an implementation of this draft.

Thanks,
Bob



From: BESS  On Behalf Of stephane.litkow...@orange.com
Sent: Thursday, November 22, 2018 2:54 AM
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover


Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-mvpn-fast-failover-04  [1]



This poll runs until *the 6th of December*.



We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this Document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.



Currently two IPRs have been disclosed against this Document.



If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/



[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw




_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover => NEED your FEEDBACK

[Muley, Praveen (Nokia - US/Mountain View)]

Not aware of any IPR related to this draft other than the one that was 
disclosed.
We have an implementation of some use cases in the draft

-Praveen

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
"Hassen, Clayton" mailto:clayton.has...@bell.ca>>
Date: Wednesday, 28 November 2018 at 07:30
To: Stephane Litkowski 
mailto:stephane.litkow...@orange.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover => NEED your FEEDBACK

I am unaware of any undisclosed IPR’s.

Thanks

--CH


From: "stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>" 
mailto:stephane.litkow...@orange.com>>
Date: Wednesday, November 28, 2018 at 4:53 AM
To: "raggarw...@yahoo.com<mailto:raggarw...@yahoo.com>" 
mailto:raggarw...@yahoo.com>>, 
"nehal.b...@alcatel-lucent.com<mailto:nehal.b...@alcatel-lucent.com>" 
mailto:nehal.b...@alcatel-lucent.com>>, Clayton 
Hassen mailto:clayton.has...@bell.ca>>, 
"wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>" 
mailto:wim.henderi...@alcatel-lucent.com>>, 
"pradeep.j...@alcatel-lucent.com<mailto:pradeep.j...@alcatel-lucent.com>" 
mailto:pradeep.j...@alcatel-lucent.com>>, 
"jayant.kotal...@alcatel-lucent.com<mailto:jayant.kotal...@alcatel-lucent.com>" 
mailto:jayant.kotal...@alcatel-lucent.com>>,
 "praveen.mu...@alcatel-lucent.com<mailto:praveen.mu...@alcatel-lucent.com>" 
mailto:praveen.mu...@alcatel-lucent.com>>, 
"r...@juniper.net<mailto:r...@juniper.net>" 
mailto:r...@juniper.net>>, 
"kanwar.si...@alcatel-lucent.com<mailto:kanwar.si...@alcatel-lucent.com>" 
mailto:kanwar.si...@alcatel-lucent.com>>, 
"rkeb...@juniper.net<mailto:rkeb...@juniper.net>" 
mailto:rkeb...@juniper.net>>
Subject: FW: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover => NEED your FEEDBACK

Hi,

You are listed as contributor or co-author of this draft. Could you please 
respond to the IPR poll as soon as possible ? Please reply to the BESS WG list. 
If you are aware of an implementation, please also let us know.

Thank you

Brgds,

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Monday, November 26, 2018 03:47
To: LITKOWSKI Stephane OBS/OINIS
Cc: BESS; bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover

Hi Stephane, et al.,
I'm not aware of any IPR related to this draft other than already disclosed.

RE: implementation status
In Q1 of 2019, ZTE will release a product that includes support of this draft.

Regards,
Greg

On Wed, Nov 21, 2018 at 11:54 PM 
mailto:stephane.litkow...@orange.com>> wrote:

Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-mvpn-fast-failover-04  [1]



This poll runs until *the 6th of December*.



We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this Document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.



Currently two IPRs have been disclosed against this Document.



If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw




_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, p

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover => NEED your FEEDBACK

[Henderickx, Wim (Nokia - BE/Antwerp)]

I am not aware of IPR related to this draft other than the one that was 
disclosed.
We have an implementation of some use cases in the draft

From: BESS  on behalf of "Hassen, Clayton" 

Date: Wednesday, 28 November 2018 at 07:30
To: Stephane Litkowski , "bess@ietf.org" 

Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover => NEED your FEEDBACK

I am unaware of any undisclosed IPR’s.

Thanks

--CH


From: "stephane.litkow...@orange.com" 
Date: Wednesday, November 28, 2018 at 4:53 AM
To: "raggarw...@yahoo.com" , 
"nehal.b...@alcatel-lucent.com" , Clayton Hassen 
, "wim.henderi...@alcatel-lucent.com" 
, "pradeep.j...@alcatel-lucent.com" 
, "jayant.kotal...@alcatel-lucent.com" 
, "praveen.mu...@alcatel-lucent.com" 
, "r...@juniper.net" , 
"kanwar.si...@alcatel-lucent.com" , 
"rkeb...@juniper.net" 
Subject: FW: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover => NEED your FEEDBACK

Hi,

You are listed as contributor or co-author of this draft. Could you please 
respond to the IPR poll as soon as possible ? Please reply to the BESS WG list. 
If you are aware of an implementation, please also let us know.

Thank you

Brgds,

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Monday, November 26, 2018 03:47
To: LITKOWSKI Stephane OBS/OINIS
Cc: BESS; bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover

Hi Stephane, et al.,
I'm not aware of any IPR related to this draft other than already disclosed.

RE: implementation status
In Q1 of 2019, ZTE will release a product that includes support of this draft.

Regards,
Greg

On Wed, Nov 21, 2018 at 11:54 PM 
mailto:stephane.litkow...@orange.com>> wrote:

Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-mvpn-fast-failover-04  [1]



This poll runs until *the 6th of December*.



We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this Document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.



Currently two IPRs have been disclosed against this Document.



If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw




_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisatio

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover => NEED your FEEDBACK

[Hassen, Clayton]

I am unaware of any undisclosed IPR’s.

Thanks

--CH


From: "stephane.litkow...@orange.com" 
Date: Wednesday, November 28, 2018 at 4:53 AM
To: "raggarw...@yahoo.com" , 
"nehal.b...@alcatel-lucent.com" , Clayton Hassen 
, "wim.henderi...@alcatel-lucent.com" 
, "pradeep.j...@alcatel-lucent.com" 
, "jayant.kotal...@alcatel-lucent.com" 
, "praveen.mu...@alcatel-lucent.com" 
, "r...@juniper.net" , 
"kanwar.si...@alcatel-lucent.com" , 
"rkeb...@juniper.net" 
Subject: FW: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover => NEED your FEEDBACK

Hi,

You are listed as contributor or co-author of this draft. Could you please 
respond to the IPR poll as soon as possible ? Please reply to the BESS WG list. 
If you are aware of an implementation, please also let us know.

Thank you

Brgds,

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Monday, November 26, 2018 03:47
To: LITKOWSKI Stephane OBS/OINIS
Cc: BESS; bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover

Hi Stephane, et al.,
I'm not aware of any IPR related to this draft other than already disclosed.

RE: implementation status
In Q1 of 2019, ZTE will release a product that includes support of this draft.

Regards,
Greg

On Wed, Nov 21, 2018 at 11:54 PM 
mailto:stephane.litkow...@orange.com>> wrote:

Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-mvpn-fast-failover-04  [1]



This poll runs until *the 6th of December*.



We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this Document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.



Currently two IPRs have been disclosed against this Document.



If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw




_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[Greg Mirsky]

Hi Stephane, et al.,
I'm not aware of any IPR related to this draft other than already disclosed.

RE: implementation status
In Q1 of 2019, ZTE will release a product that includes support of this
draft.

Regards,
Greg

On Wed, Nov 21, 2018 at 11:54 PM  wrote:

> Hello Working Group,
>
>
>
> This email starts a two-week Working Group Last Call on
> draft-ietf-bess-mvpn-fast-failover-04  [1]
>
>
>
> This poll runs until *the 6th of December*.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an Author or a Contributor of this Document please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR. The Document won't progress without answers from
> all the Authors and Contributors.
>
>
>
> Currently two IPRs have been disclosed against this Document.
>
>
>
> If you are not listed as an Author or a Contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> We are also polling for any existing implementation as per [2].
>
>
>
> Thank you,
>
> Stephane & Matthew
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/
>
>
>
> [2]
> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[Thomas Morin]

Hi Working Group,

First of all many thanks to Rob and Greg who did all the most for the 
last iterations of this drafts.



On 22/11/2018 08:54, stephane.litkow...@orange.com wrote:
If you are listed as an Author or a Contributor of this Document 
please respond to this email and indicate whether or not you are aware 
of any relevant undisclosed IPR. The Document won't progress without 
answers from all the Authors and Contributors.


Not aware of any such IPR.



We are also polling for any existing implementation as per [2].

Some of my co-authors working for router vendors will I expect provide 
information on existing implementations.


Best,

-Thomas

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess