Subject: Re: [bess] Shepherd's review of draft-ietf-bess-mvpn-fast-failover

From: <[email-masked]>
Date: Mon, 6 Jan 2020 15:48:57 +0100

Hi Greg,

I wish you an happy new year.

Thanks for your feedback, please find my replies inline.

(Trimming solved issues)

Brgds,

From: Greg Mirsky <[email-masked]> 
Sent: mercredi 4 décembre 2019 23:22
To: [email-masked]; BESS <[email-masked]>; [email-masked]
Subject: RE: Shepherd's review of draft-ietf-bess-mvpn-fast-failover

Hi Stephane,

thank you for the review and your thoughtful comments. Please find my answers and notes in-lined under GIM>> tag.

Attached, please find the diff and copy of the working version.

Regards,

Greg

Hi,

Please find below my review of the document.

Nits:

Section 3.1.1: 

As the document is standard track, could you introduce normative language in the expected behavior description ?

GIM>> I can propose the following modification of the text: 

 OLD TEXT:

   If BGP next-hop tracking is done for VPN routes and the root address
   of a given tunnel happens to be the same as the next-hop address in
   the BGP auto-discovery route advertising the tunnel, then this
   mechanisms may be omitted for this tunnel, as it will not bring any
   specific benefit.

NEW TEXT:

   If BGP next-hop tracking is done for VPN routes and the root address
   of a given tunnel happens to be the same as the next-hop address in
   the BGP auto-discovery route advertising the tunnel, then this
   mechanisms may be omitted for this tunnel, as it will not bring any
   specific benefit.

[SLI] I don’t see a difference between the two.

I was expecting a “MAY” instead of “may”.

Section 3.1.2:

As the document is standard track, could you introduce normative language in the expected behavior description ?

“This method should not be used”. Wouldn’t this be a normative statement ?

GIM>> Would the following modification of the text be acceptable:

OLD TEXT:

   This method should not be used when there is a fast restoration
   mechanism (such as MPLS FRR [RFC4090]) in place for the link.

NEW TEXT:
    Using this method when a fast restoration mechanism (such as MPLS FRR
   [RFC4090]) is in place for the link requires careful consideration
   and coordination of defect detection intervals for the link and the
   tunnel.  In many cases, it is not practical to use both methods at
   the same time.

[SLI] Are we strongly disencouraging the practice ? if yes, “it is not practical” is a bit too soft. I’m wondering if “is NOT RECOMMENDED” could be a good wording. But it is up to you.

Section 3.1.4:

As the document is standard track, could you introduce normative language in the expected behavior description ?
GIM>> Updating to the normative language as follows:

OLD TEXT:

   A PE can be removed from the UMH candidate list for a given (C-S,
   C-G) if the P-tunnel (I or S, depending) for this (S, G) is leaf
   triggered (PIM, mLDP), but for some reason internal to the protocol
   the upstream one-hop branch of the tunnel from P to PE cannot be
   built.  In this case, the downstream PE can immediately update its
   UMH when the reachability condition changes.

NEW TEXT:

   A PE MAY be removed from the UMH candidate list for a given (C-S,
   C-G) if the P-tunnel (I-PMSI or S-PMSI) for this (S, G) is leaf-
   triggered (PIM, mLDP), but for some reason internal to the protocol
   the upstream one-hop branch of the tunnel from P to PE cannot be
   built.  In this case, the downstream PE MAY immediately update its
   UMH when the reachability condition changes.

[SLI] I understand the first “MAY” as optional feature, however the second “MAY” is more a “SHOULD” IMO. Thoughts? 

 

Section 3.1.5:

As the document is standard track, could you introduce normative language in the expected behavior description ?
GIM>> I propose the following update to the second paragraph of this sub-section:

OLD TEXT:

   When such a procedure is used, in the context where fast restoration
   mechanisms are used for the P-tunnels, downstream 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.

NEW TEXT:

   When such a procedure is used, in the context where fast restoration
   mechanisms are used for the P-tunnels, a configurable timer MUST be
   configured on the downstream PE to wait before updating the UMH, to
   let the P-tunnel restoration mechanism happen.  It is RECOMMENDED to
   provide a reasonable default value for this timer.  An implementation
   MAY use three seconds as the default value for this timer.

[SLI] Do you want to standardize the default timer value ? If yes, a “SHOULD” will be better than “MAY”.

 
Section 3.1.6:

As the document is standard track, could you introduce normative language in the expected behavior description ?

GIM>> Sub-sections of 3.1.6 define the use of RFC 8562 and the new attribute. In the introduction to these sub-sections, I propose s/can/MAY/

>From a wider perspective, do you foresee other use case of signaling BFD information in BGP ? I’m just wondering if we may need something extensible for future use or not.

GIM>> Great question. BGP, and I'm speculating here, may be used to for other BFD-related scenarios. I think that we may use the Flags field.
[SLI] Is it enough or should you add some optional TLVs behind the discriminator ? (with nothing defined yet).

[SLI] New typo s/Reserved fieled/Reserved field/

Section  <http://3.1.6.2> 3.1.6.2:

s/Then The/ Then the/

GIM>> Thank you. Done.

“A different p2mp BFD session MAY monitor the state of the
   Standby Upstream PE. »

Section 3.1.7

This is not clear to me.

Are you using BFD only to signal a Down state without really “probing” ?
GIM>> This section describes how the existing p2Mp BFD session from the upstream PE to downstream PEs can be used to relay the state change (failure) of the upstream PE-CE link. The exact mechanism to detect the failure of the PE-CE link is not specified though it could be a single-hop BFD session. 

Section 4

“This non-revertive behavior can also be optionally supported by an
   implementation and would be enabled through some configuration.”

Section 4.1:

It would be great to add a text talking about what happens if an implementation does not understand the standby community. 

GIM>> As I understand, if a BGP peer does not support Standby PE community then it does not support this specification. If that is the case, then the following may happen (as described in the document):

... two different downstream PEs consider different upstream PEs to be the

   primary one; in that case, without any precaution taken, both
   upstream PEs would process a standby C-multicast route and possibly

   stop forwarding at the same time.

Would adding to "Such a situation can happen when, for instance, due to transient unicast routing inconsistencies ..." "or lack of support of the Standby PE community" address your concern?

[SLI] Yes it works.

[SLI] The text talks about “Standby PE” attribute while it is a BGP community.  This should be fixed to be consistent.

[SLI] As soon as we agree, I’ll send the draft to be proof-readed by IDR before moving to IESG.

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 6 Jan 2020 17:54:29 -0800

Hi Stephane,
thank you and happy New Year to you too.
Please find my follow-up answers and notes below under GIM2>> tag.
Attached are the working version of the draft and its diff to -08 (the
latest in the datatracker).

Kind regards,
Greg

On Mon, Jan 6, 2020 at 6:48 AM <[email-masked]> wrote:

> *From:* Greg Mirsky <[email-masked]>
> *Sent:* mercredi 4 décembre 2019 23:22
> *To:* [email-masked]; BESS <[email-masked]>; [email-masked]
> *Subject:* RE: Shepherd's review of draft-ietf-bess-mvpn-fast-failover
>
>
>
> Hi Stephane,
>
> thank you for the review and your thoughtful comments. Please find my
> answers and notes in-lined under GIM>> tag.
>
GIM2>> My apologies, I've pasted the same text twice. I propose to remove
"may be omitted" altogether. Hence the updated text:
   If BGP next-hop tracking is done for VPN routes and the root address
   of a given tunnel happens to be the same as the next-hop address in
   the BGP auto-discovery route advertising the tunnel, then the use of this
   mechanism for the tunnel will not bring any specific benefit.
Do you see this version without any normative language as acceptable?

> [SLI] Are we strongly disencouraging the practice ? if yes, “it is not
> practical” is a bit too soft. I’m wondering if “is NOT RECOMMENDED” could
> be a good wording. But it is up to you.
>
GIM2>> The use of OAM in multi-layer fashion is a question I'd be
interested to discuss. But I feel that it deserves a separate document and
would prefer to leave the text as a note of caution for now.

> “MAY” is more a “SHOULD” IMO. Thoughts?
GIM2>>  Thank you for the clarification. The UMH list will certainly be
updated once the reachability of the downstream PE changes. In some
scenarios, such an update may be immediate, i.e., ASAP, but in some, it
might be better to delay it. Would you suggest adding a note about the
option to delay the update?

> “SHOULD” will be better than “MAY”.
GIM2>> Thank you for the suggestion. I agree the specific value that
improves interoperability while reducing the number of extra operations
required is good. Thus, s/MAY/SHOULD/

> GIM>> Sub-sections of 3.1.6 define the use of RFC 8562 and the new
> attribute. In the introduction to these sub-sections, I propose s/can/MAY/
>
>
>
> >From a wider perspective, do you foresee other use case of signaling BFD
> information in BGP ? I’m just wondering if we may need something
> extensible for future use or not.
>
> GIM>> Great question. BGP, and I'm speculating here, may be used to for
> other BFD-related scenarios. I think that we may use the Flags field.
> [SLI] Is it enough or should you add some optional TLVs behind the
> discriminator ? (with nothing defined yet).
>
GIM2>> Great idea, thank you! Please see the updated figure and the text:
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    BFD Mode   |                  Reserved                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       BFD Discriminator                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Reserved  TLV                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Format of the BFD Discriminator Attribute

   Where:

      BFD Mode is the one octet long field.  This specification defines
      the P2MP value (TBA3) Section 7.1.

      Reserved field is three octets long and the value MUST be zeroed
      on transmission and ignored on receipt.

      BFD Discriminator is four octets long field.

      Reserved TLV field is four octets long.  It MAY be used for future
      extensions of the BFD Discriminator Attribute using Type-Length-
      Value format.  This specification defines that the value in
      Reserved TLV field MUST be zeroed on transmission and ignored on
      receipt.

> [SLI] New typo s/Reserved fieled/Reserved field/
GIM2>> Thanks, fixed.

> Section 3.1.6.2:
> GIM>> This section describes how the existing p2Mp BFD session from the
> upstream PE to downstream PEs can be used to relay the state change
> (failure) of the upstream PE-CE link. The exact mechanism to detect the
> failure of the PE-CE link is not specified though it could be a single-hop
> BFD session.
>
>
> Section 4
>
> It would be great to add a text talking about what happens if an
> implementation does not understand the standby community.
>
> GIM>> As I understand, if a BGP peer does not support Standby PE community
> then it does not support this specification. If that is the case, then the
> following may happen (as described in the document):
>
> Would adding to "Such a situation can happen when, for instance, due to
> transient unicast routing inconsistencies ..." "or lack of support of the
> Standby PE community" address your concern?
>
> [SLI] Yes it works.
>
>
>
> [SLI] The text talks about “Standby PE” attribute while it is a BGP
> community.  This should be fixed to be consistent.
>
GIM2>> Thank you. Fixed:
OLD TEXT:
   The normal and the standby C-multicast routes must have their Local
   Preference attribute adjusted so that, if two C-multicast routes with
   same NLRI are received by a BGP peer, one carrying the "Standby PE"
   attribute and the other one *not* carrying the "Standby PE"
   community, then preference is given to the one *not* carrying the
   "Standby PE" attribute.  Such a situation can happen when, for
   instance, due to transient unicast routing inconsistencies, two
   different downstream PEs consider different upstream PEs to be the
   primary one; in that case, without any precaution taken, both
   upstream PEs would process a standby C-multicast route and possibly
   stop forwarding at the same time.  For this purpose, routes that
   carry the "Standby PE" BGP Community MUST have the LOCAL_PREF
   attribute set to zero.

NEW TEXT:
   The normal and the standby C-multicast routes MUST have their Local
   Preference attribute adjusted so that, if two C-multicast routes with
   same NLRI are received by a BGP peer, one carrying the "Standby PE"
   community and the other one *not* carrying the "Standby PE"
   community, then preference is given to the one *not* carrying the
   "Standby PE" community.  Such a situation can happen when, for
   instance, due to transient unicast routing inconsistencies or lack of
   support of the Standby PE community, two different downstream PEs
   consider different upstream PEs to be the primary one; in that case,
   without any precaution taken, both upstream PEs would process a
   standby C-multicast route and possibly stop forwarding at the same
   time.  For this purpose, routes that carry the "Standby PE" BGP
   Community MUST have the LOCAL_PREF attribute set to zero.

> [SLI] As soon as we agree, I’ll send the draft to be proof-readed by IDR
GIM2>> That will be great, thank you.

---

From: <[email-masked]>
Date: Tue, 7 Jan 2020 14:59:27 +0100

Hi Greg,

More inline,

From: Greg Mirsky <[email-masked] <mailto:[email-masked]> > 
Sent: mercredi 4 décembre 2019 23:22
To: [email-masked] <mailto:[email-masked]> ; BESS <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: RE: Shepherd's review of draft-ietf-bess-mvpn-fast-failover

Hi Stephane,

Regards,

Greg

Hi,

Nits:

Section 3.1.1: 

GIM2>> My apologies, I've pasted the same text twice. I propose to remove "may be omitted" altogether. Hence the updated text:

[SLI] Looks good thanks

Section 3.1.2:

OLD TEXT:

NEW TEXT:

GIM2>> The use of OAM in multi-layer fashion is a question I'd be interested to discuss. But I feel that it deserves a separate document and would prefer to leave the text as a note of caution for now.

[SLI] Ok

Section 3.1.4:

OLD TEXT:

NEW TEXT:

GIM2>>  Thank you for the clarification. The UMH list will certainly be updated once the reachability of the downstream PE changes. In some scenarios, such an update may be immediate, i.e., ASAP, but in some, it might be better to delay it. Would you suggest adding a note about the option to delay the update?

[SLI] Could you check with Jeffrey Zhang on this point ? I’m not enough expert here to tell what may be the best option. On my side, I just want the text to be clear 😊

 

Section 3.1.6:

       0                   1                   2                   3

   Where:

      receipt.

[SLI] If your field is 4-bytes long, it is not extensible, I was thinking of options encoded as TLVs.

If there is no TLV, the attribute ends on BFD discriminator, the attribute length should tell if there are TLVs or not.

       0                   1                   2                   3
      |                         optional TLVs                         |

Another point I have missed, you should define error handling procedures for your attribute as per RFC7606.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 7 Jan 2020 07:57:32 -0800

Hi Stephane,
thank you for your quick response, comments and helpful suggestions. I'll
work on the updated format, error handling, and reach out to Jeffrey.

Regards,
Greg

On Tue, Jan 7, 2020 at 5:59 AM <[email-masked]> wrote:

> [SLI] Could you check with Jeffrey Zhang on this point ? I’m not enough
> expert here to tell what may be the best option. On my side, I just want
> the text to be clear 😊
>
>
>
>
>
>
>
>
>
>
>
> Section 3.1.6:
>
> If there is no TLV, the attribute ends on BFD discriminator, the attribute
> length should tell if there are TLVs or not.
>
>
>
>        0                   1                   2                   3

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 22 Jan 2020 12:40:35 -0800

Hi Jeffrey,
happy New Years (the Spring Festival is just upon us) and best wishes.
Stephane suggested to ask you another, hopefully quick, review of the part
of this draft. Please see our discussion copied below:

Section 3.1.4:

As the document is standard track, could you introduce normative language
in the expected behavior description ?
GIM>> Updating to the normative language as follows:

OLD TEXT:

NEW TEXT:

[SLI] I understand the first “MAY” as optional feature, however the second
“MAY” is more a “SHOULD” IMO. Thoughts?

What do you think of the use of the normative language in the newly updated
text?

Best regards,

Greg

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 22 Jan 2020 16:06:24 -0800

Hi Stephane,
I've followed your suggestions and updated the working version of the draft
with adding:

   - explicit TLV in the format of BFD Discriminator attribute;
   - text to define check the proper format of the BFD Discriminator
   attribute and the handling in case it is malformed per RFC 7606.

I greatly appreciate your feedback. Attached please find the diff to the
updated working version of the draft and its copy.

Regards,
Greg

---

From: <[email-masked]>
Date: Thu, 23 Jan 2020 15:03:48 +0100

Hi Greg,

I think there is still a misunderstanding on the proposed encoding 😊 I may not have been fully clear, sorry.

Here is what you have:

       0                   1                   2                   3

      |    BFD Mode   |                  Reserved                     |

      |                       BFD Discriminator                       |

      |              Type             |           Length              |

      ~                             Value                             ~

 

Here is what I expected :

       0                   1                   2                   3

      |    BFD Mode   |                  Reserved                     |

      |                       BFD Discriminator                       |

      |              Optional TLVs (variable)

 

Associated with a text:

Optional TLVs:

The BFD Discriminator attribute MAY context optional TLVs for future extension. Each TLV consists of a sequence of:

*	1 octet of TLV type
*	1 octet of length of the value field of the TLV
*	Followed by the value 

This document does not define any TLV yet.

Thinking more about it, while it remains a good idea to use TLVs for future extensions, we need to define a registry to manage the TLV type in the context of the BFD attribute. Which means we will create an empty registry.

I would be happy to hear other opinions on that.

Brgds,

Stephane

From: Greg Mirsky <[email-masked]> 
Sent: jeudi 23 janvier 2020 01:06
To: [email-masked]
Cc: BESS <[email-masked]>; [email-masked]
Subject: Re: Shepherd's review of draft-ietf-bess-mvpn-fast-failover

Hi Stephane,

I've followed your suggestions and updated the working version of the draft with adding:

*	explicit TLV in the format of BFD Discriminator attribute;
*	text to define check the proper format of the BFD Discriminator attribute and the handling in case it is malformed per RFC 7606.

I greatly appreciate your feedback. Attached please find the diff to the updated working version of the draft and its copy.

Regards,

Greg

On Tue, Jan 7, 2020 at 5:59 AM <[email-masked] <mailto:[email-masked]> > wrote:

Hi Greg,

More inline,

Hi Stephane,

Regards,

Greg

Hi,

Nits:

Section 3.1.1: 

[SLI] Looks good thanks

Section 3.1.2:

OLD TEXT:

NEW TEXT:

[SLI] Ok

Section 3.1.4:

OLD TEXT:

NEW TEXT:

 

 
Section 3.1.6:

       0                   1                   2                   3

   Where:

      receipt.

       0                   1                   2                   3

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 23 Jan 2020 13:15:16 -0800

Hi Stephane,
many more thanks for the detailed clarification. I've re-formated the BFD
Discriminator attribute, updated the text to its explanation, and the new
sub-registry of BFD Discriminator Extention Types. As, usual, diff and the
working version of the draft are attached for review and comments.

Best regards,
Greg

On Thu, Jan 23, 2020 at 6:03 AM <[email-masked]> wrote:

> The BFD Discriminator attribute MAY context optional TLVs for future
> extension. Each TLV consists of a sequence of:
>
>    - 1 octet of TLV type
>    - 1 octet of length of the value field of the TLV
>    - Followed by the value
>
> Thinking more about it, while it remains a good idea to use TLVs for
> future extensions, we need to define a registry to manage the TLV type in
> the context of the BFD attribute. Which means we will create an empty
> registry.
>
> *Sent:* jeudi 23 janvier 2020 01:06
> *To:* [email-masked]
> *Cc:* BESS <[email-masked]>; [email-masked]
> *Subject:* Re: Shepherd's review of draft-ietf-bess-mvpn-fast-failover
>
>
>
> Hi Stephane,
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 31 Jan 2020 19:43:53 +0000

Hi Greg, Stephane,

The first MAY should actually be a SHOULD; for the second MAY, it actually can go back to “can”.

Then this will match the previous RSVP-TE section. The “in this case” sentence is more about the result, not the action to take. Perhaps also change “in this case” to “as a result” in both sections?

Jeffrey

From: Greg Mirsky <[email-masked]>
Sent: Wednesday, January 22, 2020 3:41 PM
To: [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: BESS <[email-masked]>; [email-masked]
Subject: Re: Shepherd's review of draft-ietf-bess-mvpn-fast-failover

Hi Jeffrey,
happy New Years (the Spring Festival is just upon us) and best wishes.
Stephane suggested to ask you another, hopefully quick, review of the part of this draft. Please see our discussion copied below:
Section 3.1.4:

What do you think of the use of the normative language in the newly updated text?

Best regards,
Greg

On Tue, Jan 7, 2020 at 5:59 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

More inline,

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: mercredi 4 décembre 2019 23:22
To: [email-masked]<mailto:[email-masked]>; BESS <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Shepherd's review of draft-ietf-bess-mvpn-fast-failover

Hi Stephane,

Regards,
Greg

Hi,

Nits:

Section 3.1.1:

[SLI] Looks good thanks

Section 3.1.2:

[SLI] Ok

Section 3.1.4:

Section 3.1.6:

   Where:

       0                   1                   2                   3

---

From: <[email-masked]>
Date: Fri, 31 Jan 2020 20:49:29 +0100

I’m fine with the proposal

From: Jeffrey (Zhaohui) Zhang <[email-masked]> 
Sent: vendredi 31 janvier 2020 20:44
To: Greg Mirsky <[email-masked]>; [email-masked]
Cc: BESS <[email-masked]>; [email-masked]
Subject: RE: Shepherd's review of draft-ietf-bess-mvpn-fast-failover

Hi Greg, Stephane,

Jeffrey

From: Greg Mirsky <[email-masked] <mailto:[email-masked]> > 
Sent: Wednesday, January 22, 2020 3:41 PM
To: [email-masked] <mailto:[email-masked]> ; Jeffrey (Zhaohui) Zhang <[email-masked] <mailto:[email-masked]> >
Cc: BESS <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: Shepherd's review of draft-ietf-bess-mvpn-fast-failover

Hi Jeffrey,

Section 3.1.4:

OLD TEXT:

NEW TEXT:

Best regards,

Greg

Hi Greg,

More inline,

Hi Stephane,

Regards,

Greg

Hi,

Nits:

Section 3.1.1: 

[SLI] Looks good thanks

Section 3.1.2:

OLD TEXT:

NEW TEXT:

[SLI] Ok

Section 3.1.4:

OLD TEXT:

NEW TEXT:

 

 
Section 3.1.6:

       0                   1                   2                   3

   Where:

      receipt.

       0                   1                   2                   3

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 31 Jan 2020 12:55:03 -0800

Hi Jeffrey,
many thanks for your suggestions. I've updated the document accordingly. I
much appreciate you checking that changes are in the right places. I'll
upload the new version ones you approve the changes.

Regards,
Greg

On Fri, Jan 31, 2020 at 11:49 AM <[email-masked]> wrote:

> *From:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Sent:* vendredi 31 janvier 2020 20:44
> *To:* Greg Mirsky <[email-masked]>; [email-masked]
> Then this will match the previous RSVP-TE section. The “in this case”
> sentence is more about the result, not the action to take. Perhaps also
> change “in this case” to “as a result” in both sections?
>
>
>
> Jeffrey
>
>
>
> *Sent:* Wednesday, January 22, 2020 3:41 PM
> *To:* [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]
> >

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 31 Jan 2020 21:16:41 +0000

In 3.1.4 you missed “as a result”.

From: BESS <[email-masked]> On Behalf Of Greg Mirsky
Sent: Friday, January 31, 2020 3:55 PM
To: [email-masked]
Cc: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; BESS <[email-masked]>
Subject: Re: [bess] Shepherd's review of draft-ietf-bess-mvpn-fast-failover

Hi Jeffrey,
many thanks for your suggestions. I've updated the document accordingly. I much appreciate you checking that changes are in the right places. I'll upload the new version ones you approve the changes.

Regards,
Greg

On Fri, Jan 31, 2020 at 11:49 AM <[email-masked]<mailto:[email-masked]>> wrote:
I’m fine with the proposal

From: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Sent: vendredi 31 janvier 2020 20:44
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: BESS <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Shepherd's review of draft-ietf-bess-mvpn-fast-failover

Hi Greg, Stephane,

Jeffrey

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, January 22, 2020 3:41 PM
To: [email-masked]<mailto:[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: BESS <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Shepherd's review of draft-ietf-bess-mvpn-fast-failover

Hi Jeffrey,

Best regards,
Greg

More inline,

Hi Stephane,

Regards,
Greg

Hi,

Nits:

Section 3.1.1:

[SLI] Looks good thanks

Section 3.1.2:

[SLI] Ok

Section 3.1.4:

Section 3.1.6:

As the document is standard track, could you introduce normative language in the expected behavior description ?
GIM>> Sub-sections of 3.1..6 define the use of RFC 8562 and the new attribute. In the introduction to these sub-sections, I propose s/can/MAY/

   Where:

       0                   1                   2                   3

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 31 Jan 2020 13:41:09 -0800

Hi Jeffrey,
my apologies, I misunderstood your proposed change. Should it be the
following change:
OLD TEXT
The downstream PE can immediately update its UMH
 when the reachability condition changes.
NEW TEXT
As a result, the downstream PE can immediately update its UMH
when the reachability condition changes.

Thank you for your help.

Regards,
Greg

On Fri, Jan 31, 2020 at 1:16 PM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> *From:* BESS <[email-masked]> *On Behalf Of * Greg Mirsky
> *Sent:* Friday, January 31, 2020 3:55 PM
> *Cc:* Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked];
> BESS <[email-masked]>
> *Subject:* Re: [bess] Shepherd's review of
> draft-ietf-bess-mvpn-fast-failover
>
>
>
> Hi Jeffrey,
>
> GIM>> Sub-sections of 3.1..6 define the use of RFC 8562 and the new