Subject: Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-mvpn-fast-failover-13: (with DISCUSS and COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Thu, 17 Dec 2020 15:47:16 -0500

Hi!

For some reason the original DISCUSS message didn’t make it into
everyone’s mailbox (including mine), so I’m “hijacking” this reply to
resend the comments.

Note that the archive has the messages:
https://mailarchive.ietf.org/arch/msg/iesg/PByc1h2E-xSBnqXUtFTcltutEkQ/

Alvaro.

===

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) This document describes several methods to determine the status of a
tunnel (in §3), none of which "provide a "fast failover" solution when used
alone, but can be used together with the mechanism described in Section 4"
(§1).  §3 also says this:

   An implementation may support any combination of the methods
   described in this section and provide a network operator with control
   to choose which one to use in the particular deployment.

While §3.1 is clear in the fact that it is not a requirement for all
downstream PEs to use the same mechanism, there are no guidelines to aid the
operator to chose which mechanism to use.  Some cases may be obvious (e.g.
§3.1.3 applies to tunnels of a specific type), but others are not.  I would
like to see deployment considerations related to the advantages/disadvantages
that each method may have in specific situations (including their possible
combination).

(2) The BFD Discriminator Attribute has a very narrow application in this
document when compared to the potential other uses given the extensibility
possibilities related to bootstrapping BFD.  I have serious concerns about
the attribute being defined in this document, amongst a series of other
mechanisms.

(2a) The tunnel can be monitored without the new BGP Attribute (assuming
proper configuration of course).  Why is that option is not even mentioned in
the document?

In fact, the document recommends deleting the BFD session if the Attribute is
not present.  Why is that recommendation in place, and what are the cases when
it can not be followed?

(2b) The fact that BFD monitoring can be achieved without the new attribute
makes me think that the bootstrapping of BFD using BGP would be better served
in a document produced by the BFD WG.  One of the editors has expressed the
same opinion [1] [2].  Has a discussion taken place in the BFD WG (or at least
with the Chairs) about this work?  Why was it not taken up there?

[1] https://mailarchive.ietf.org/arch/msg/rtg-bfd/T1jVpgyXuPatTpuD_wA0JC3CT1c/
[2] https://tools.ietf.org/wg/bess/minutes?item=minutes-96-bess.html

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(0) I support Ben's DISCUSS.

(1) This document (currently) specifies a new BGP attribute, but I couldn't
find any discussion about it in the idr mailing list.  Has idr been given the
opportunity to review?

(2) s/is an OPTIONAL procedure/is an optional procedure
This is not a normative statement to require capitalization.

(3) "VRF Route Import BGP attribute" is mentioned twice (§3 and §5), but it is
not an attribute; it is an extended community (rfc6514).

(4) §3.1.1: "similar to BGP next-hop tracking"  Is this specified somewhere?
I don't remember seeing a specification for next-hop tracking, but do know
that implementations do it -- in an implementation-specific way.  Please add a
little more text about what is meant/expected.

(5) §3.1.1: "If BGP next-hop tracking is done...and the root
address...[is]...the same as the next-hop address...then checking...whether
the tunnel root is reachable, will be unnecessary duplication...."  I guess
this means that the existing next-hop tracking functionality can be used and
that it doesn't have to be function-specific (root vs next-hop).  This
paragraph seems to assume a specific implementation -- but again, given that
next-hop tracking implementations are internal then this paragraph doesn't
make much sense to me.

(6) The "reachability condition" is mentioned in §3.1.1/§3.1.3/§3.1.4.  Does
this mean that that root tracking (§3.1.1) should be used with the other
mechanisms?  The specific text says that "the downstream PE can immediately
update its UMH when the reachability condition changes", giving the impression
that the combination is possible but not required.

Note that §4.3 is titled "Reachability Determination", which I hoped would
shed more light, but all it does is point back to §3.1.

(7) §3.1.2: What is the "last-hop link" of the tunnel?  Is it the physical
link, or the virtual hop from the previous waypoint?

(8) §3.1.2 mentions that "careful consideration and coordination" is needed
when using other mechanisms such as rfc4090 "because uncorrelated timers might
cause unnecessary switchovers and destabilize the network."  What are the
associated timers related to the mechanisms in this section?

(9) §3.1.3:

   When using this method and if the signaling state for a P2MP TE LSP
   is removed (e.g., if the ingress of the P2MP TE LSP sends a PathTear
   message) or the P2MP TE LSP changes state from Up to Down as
   determined by procedures in [RFC4875], the status of the
   corresponding P-tunnel MUST be re-evaluated.  If the P-tunnel
   transitions from Up to Down state, the Upstream PE that is the
   ingress of the P-tunnel MUST NOT be considered a valid UMH.

These two sentences are redundant.  It seems to me that they could be
replaced by:

   When using this method and if the signaling state for a P2MP TE LSP
   is removed (e.g., if the ingress of the P2MP TE LSP sends a PathTear
   message) or the P2MP TE LSP changes state from Up to Down as
   determined by procedures in [RFC4875], the Upstream PE that is the
   ingress of the P-tunnel MUST NOT be considered a valid UMH.

(10) §3.1.4: "An Upstream PE SHOULD be removed from the UMH candidate
list...if...the upstream one-hop branch of the tunnel from P to PE cannot be
built."   When is it ok to not remove the PE?  IOW, why is this action not
required?

(11) [nit] s/mechanism to execute its actions/mechanism execute its actions

(12) §3.1.5 says that "where this mechanism is used in conjunction with the
method described in Section 5...downstream PEs can compare reception on the
two P-tunnels to determine when one of them is down", but §5 says that
"downstream PEs accept traffic from the primary or standby tunnel, based on
the status of the tunnel (based on Section 3)".  IOW, §3.1.5 points at §5 as
providing a way to determine if a tunnel is down, while §5 points back at §3
as the way to determine which tunnel to receive from.  This pointing back and
forth is not a total contradiction, but it needs to be clarified.

(13) §3.1.6: "An implementation that does not recognize or is configured not
to support this attribute MUST follow procedures defined for optional
transitive path attributes in Section 5 of [RFC4271]."

There cannot be a Normative action specified for a node that "does not
recognize...this attribute" because, by definition, it can't be assumed that
it is aware of this specification.  In this case, it is not necessary to say
anything about unrecognized attributes because that is already specified in
rfc4271.

For the "configured not to support this attribute" case, it should be pointed
out that the node should operate as if the attribute was unrecognized.

Suggestion>
   An implementation that is configured not to support this attribute MUST
   follow the procedures defined in Section 5 of [RFC4271] as if the attribute
   was unrecognized.

(14) [nit] s/BFD Mode field is the one octet long./The BFD Mode field is one
octet long.

(15) §3.1.6: "The BFD Discriminator attribute MUST be considered malformed if
its length is not a non-zero multiple of four."  Ok, except that the
specification of the attribute doesn't mention the length (only the length of
the TLVs).  Please specify the length and any considerations related to the
Extended Length bit.  Also, given that this is a new attribute, with an
unspecified potential number of TLVs, and that the length is apparently
unbounded, all leading to the potential need for extended messages, please
specify how to handle peers that cannot accommodate more than 4k octet
messages (rfc8654).

(16) §3.1.6.1: "MUST set the IP destination address of the inner IP header to
one of the internal loopback addresses..."   Where do these addresses come
from?  How does the Upstream PE figure out which one to use?  At least please
include a reference to where that is explained.

(17) §3.1.6.1: "MUST use its IP address as the source IP address"  Which
address?  Please be specific.

(18) §3.1.6.2: If the IP address doesn't map correctly at the downstream PE
(for example, a different local address is used that doesn't correspond to the
information in the PMSI attribute), what action should it take?  Can the
tunnel still be monitored?

(19) §3.1.6.2: "SHOULD NOT switch the traffic to the Standby Upstream PE"
When is it ok to do it?  IOW, why is this action recommended, and not
required.

(20) §3.1.7: "set the bfd.LocalDiag of the P2MP BFD session to Concatenated
Path Down and/or Reverse Concatenated Path Down"    Which one?  bfd.LocalDiag
carries a single value.

(21) §3.1.7: "...it is desired for the downstream PEs to switch to a backup
Upstream PE.  To achieve that...it SHOULD set the bfd.LocalDiag..."  If not
set, then the objective won't be achieved.  When is it ok to not set the
bfd.LocalDiag to indicate the concatenated failure?

(22) §4: "Such behavior is referred to as "revertive" behavior and MUST be
supported."  The text around this sentence seems to indicate that the
revertive behavior is the default, is that the intent?  Or if the intent for
it just to be supported (as written)?  Please be clear.

(23) §4.1: "...routes that carry the "Standby PE" BGP Community MUST have the
LOCAL_PREF attribute set to zero."  What should a receiver do if the
LOCAL_PREF is not zero?

(24) §4.1: In the last paragraph of this section, if I follow correctly, the
text talks about the case where the standby becomes the primary and the
updated advertisement doesn't have the Standby PE community.  If that is
correct, then s/ presence/absence of the Standby PE BGP Community/ absence of
the Standby PE BGP Community

Also, the last sentence says that the "LOCAL_PREF attribute MUST be set to
zero".  If the community is not present, how can a receiver enforce this?
What action should it take if the LOCAL_PREF has a different value?

(25) §4.3: "other mechanisms MAY be used"   s/MAY/may   This is just a
statement of fact.

(26) §4.4.2: "MUST try to locate"   To try is not an action that can be
normatively enforced.   Also, I don't think that using "MUST" here adds value
since the normative action is in the next sentence ("MUST perform as
follows"). s/MUST/must

(27) s/"hot root standby" mode is used (Section 4)/"hot root standby" mode is
used (Section 5)

(28) §7.3: s/sub-TLV/TLV/g   The attribute includes TLVs, not sub-TLVs.

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 20 Dec 2020 16:24:21 -0800

Hi Alvaro,
thank you for the review and comments. And thank you for the re-sent
comments as I was one of those who missed it the first time (may try
blaming Gmail). Please find my answers, notes below tagged by GIM>>,

Also, attached is the diff highlighting the updates.

Regards,
Greg

> https://mailarchive.ietf.org/arch/msg/iesg/PByc1h2E-xSBnqXUtFTcltutEkQ/
GIM>> I think it might be not that simple to compare deployment challenges
and benefits resulting from the deployment of different P-tunnel monitoring
methods because we have to somehow abstract from an impact of choices made
by respective implementations. Also, there probably should be a reference
environment, a use case we agree with. I agree that such a comparative
analysis of P-tunnel monitoring methods is useful it doesn't seem to
benefit this document as the choice of a developer which ones to implement
and an operator which one to use don't affect the functionality discussed
in the draft. Would you agree?

> proper configuration of course).  Why is that option is not even mentioned
GIM>> You are right, there could be other methods to bootstrap a p2mp BFD
session. But since RFC 8562 has no discussion of bootstrapping a session,
having it in this draft seemed somewhat out of place. We can add an
informational reference to Section 4 of draft-mirsky-mpls-p2mp-bfd
<https://datatracker.ietf.org/doc/draft-mirsky-mpls-p2mp-bfd/>where several
bootstrapping options discussed. Would that be acceptable?

> not present.  Why is that recommendation in place, and what are the cases
GIM>> That recommendation is to ensure that resources are not leaked and
this monitoring mechanism does not amplify possible DoS attacks. In course
of the discussion with Murray, we've changed the normative language and now
the deletion of the BFD state information is required
   o  the P2MP BFD session MUST be deleted.  The session MAY be deleted
      after some configurable delay, which should have a reasonable
      default.

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

GIM>> Work on draft-mirsky-mpls-p2mp-bfd
<https://datatracker.ietf.org/doc/draft-mirsky-mpls-p2mp-bfd/?include_text=1>
is
progressing at MPLS WG. AFAIK, it is in the state Candidate for WG
Adoption. Moving the definition of the BFD Discriminator attribute to that
draft, as I understand, would require using it as the normative reference.
Comparing the current states of both documents, would severely delay the
publication of MVPN Fast Failover specification and likely affect
implementations of P-tunnel monitoring mechanisms. I hope you can agree
with the current organization of the document.

GIM>> I hope BESS Chairs and the Responsible AD can help with the answer.

> This is not a normative statement to require capitalization.
GIM>>  I think that the use of the normative form is reasonable. The
sentence can be re-worded using MAY. For example:
OLD TEXT:
   The procedure described here is an OPTIONAL procedure that is based
   on a downstream PE taking into account the status of P-tunnels rooted
   at each possible Upstream PE, for including or not including each
   given PE in the list of candidate UMHs for a given (C-S, C-G) state.
NEW TEXT:
   The procedure described here MAY be used in a BGP/MPLS MVPN [RFC6513].
It  is based
   on a downstream PE taking into account the status of P-tunnels rooted
   at each possible Upstream PE, for including or not including each
   given PE in the list of candidate UMHs for a given (C-S, C-G) state.
We wanted to stress that without this mechanism BGP/MPLS MVPN, as defined
in RFCs 6513 and 6514, is fully functional and architecturally complete.
This draft discusses mechanisms that support the protection and faster
convergence in MVPN's control plane. And since these mechanisms only an
improvement compared to the BGP mechanisms, we wanted to emphasize that by
using the normative form. Would you agree?

> not an attribute; it is an extended community (rfc6514).
GIM>>  Thank you for pointing that out. Updated.

> little more text about what is meant/expected.
GIM>> Indeed, BGP next-hop tracking is internal to a system behavior that
has not been, to the best of my knowledge, been documented at IETF or any
SDO. Would the following text provide reasonable context information:
   That is similar to BGP next-hop tracking for VPN routes, except that
   the address considered is not the BGP next-hop address but the root
   address in the x-PMSI Tunnel attribute.  BGP next-hop tracking is a
   feature that reduces the BGP convergence time comparing to the
   "regular" BGP by monitoring BGP next-hop address changes in the
   routing table.  It's event-based because it detects changes in the
   routing table.  When it detects a change, it performs a next-hop scan
   to find if any of the next hops in the BGP table is affected and updates
   it accordingly.

> next-hop tracking implementations are internal then this paragraph doesn't
GIM>> This section is intended as informative since, as you've mentioned
earlier, there are many implementations of BGP next-hop tracking and the
functionality is enabled by default in some of the implementations. Our
intent was to point out that this well-known and broadly used mechanism can
be used in combination with PE redundancy to provide a faster convergence
in MVPN's control plane.

> shed more light, but all it does is point back to §3.1.
GIM>> I don't see any benefit of concurrently using more than one of the
described in the document mechanisms that can monitor the state of a
P-tunnel. That is certainly possible but, in my opinion, would add
unnecessary complexity. The last paragraph in Section 3.1 is intended as
the introduction to sub-sections that discuss different monitoring
mechanisms:
   An implementation may support any combination of the methods
   described in this section and provide a network operator with control
   to choose which one to use in the particular deployment.
Would you suggest an update to this paragraph to clarify the statement?

> link, or the virtual hop from the previous waypoint?
GIM>> A last-hop link is a link between a PE and the penultimate P node.

> associated timers related to the mechanisms in this section?
GIM>> This is in reference to the defect detection timers. When using
multi-layer protection particular consideration must be given to the
interaction of defect detections at different layers of a network. It s
recommended to use longer detection intervals at the higher layers. Some
recommendations suggest using a multiplier of 3 or larger, e.g., 10 msec
detection for FRR and at least 100 msec for e2e detection.

GIM>> Thank you for the suggested update of the text. I think that the
original text includes an important requirement to re-evaluate the status
of the corresponding P-tunnel rather than remove the Upstream PE from the
UMH candidate list only based on the change in p2mp TE LSP.

> built."   When is it ok to not remove the PE?  IOW, why is this action not
GIM>> Thank you for bringing this case. It was discussed during Shepherd's
review and we've asked for the expert's opinion. Jeffrey Zhang kindly suggested
the current text.
<https://mailarchive.ietf.org/arch/browse/bess/?gbt=1&index=LxKYi9F6u1tl2qKtR2Q8wkQPMOA>
I'll
check with him and get back with the answer.

> (11) [nit] s/mechanism to execute its actions/mechanism execute its actions
GIM>> Thank you. Done

> forth is not a total contradiction, but it needs to be clarified.
 GIM>> Though it might appear as a circular reference, it was not the
intention. An implementation of the method described in the last paragraph
of Section 3.1.5 can periodically accept traffic from primary and standby
tunnels s the method of determining the state of the primary P-tunnel. I've
updated that paragraph to note that the comparison can be done periodically:
OLD TEXT:
   In cases where this mechanism is used in conjunction with the method
   described in Section 5, no prior knowledge of the rate or maximum
   inter-packet time on the multicast streams is required; downstream
   PEs can compare actual packet reception statistics on the two
   P-tunnels to determine when one of them is down.  The detailed
   specification of this mechanism is outside the scope of this
   document.
NEW TEXT:
   In cases where this mechanism is used in conjunction with the method
   described in Section 5, no prior knowledge of the rate or maximum
   inter-packet time on the multicast streams is required; downstream
   PEs can periodically compare actual packet reception statistics on
   the two P-tunnels to determine when one of them is down.  The
   detailed specification of this mechanism is outside the scope of this
   document.

>    follow the procedures defined in Section 5 of [RFC4271] as if the
GIM>> Thank you for pointing this out. In the course of addressing comments
from other IESG reviewers, this text was updated to:
   This document defines the format and ways of using a new BGP
   attribute called the "BFD Discriminator".  It is an optional
   transitive BGP attribute.  Thus it is expected that an implementation
   that does not recognize or is configured not to support this
   attribute follows procedures defined for optional transitive path
   attributes in Section 5 of [RFC4271].
Would the current text address your concern?

> (14) [nit] s/BFD Mode field is the one octet long./The BFD Mode field is
GIM>> Thank you. Done.

> specify how to handle peers that cannot accommodate more than 4k octet
GIM>> I've noticed a note from Jeff Hass. Would you agree with his opinion?

> include a reference to where that is explained.
GIM>> Thank you for pointing out the missing reference to RFC 1122, added
it. I think that the selection of the inner destination IP address is an
implementation issue and how the address is selected should not affect a
MultipointTail node. Would you agree?

> address?  Please be specific.
GIM>> Section 3.1.6.1 includes the list that an Upstream PE is required to
follow:
   To enable downstream PEs to track the P-tunnel status using a point-
   to-multipoint (P2MP) BFD session the Upstream PE:
....
   o  MUST use its IP address as the source IP address when transmitting
      BFD Control packets;
Would adding the reference to the Upstream PE address your concern:
    o  MUST use its, i.e., the Upstream PE's, IP address as the source IP
address
        when transmitting BFD Control packets;

> tunnel still be monitored?
GIM>> There's a possibility that the same downstream PE is monitoring more
than one P-tunnel. Since each Upstream PE assigns its own BFD
Discriminator, there's a chance that the same value is picked by more than
one Upstream PE. According to Section 5.7 of the RFC 8562:
   IP and MPLS multipoint tails MUST demultiplex BFD packets based on a
   combination of the source address, My Discriminator, and the identity
   of the multipoint path that the multipoint BFD Control packet was
   received from.  Together they uniquely identify the head of the
   multipoint path.
We may consider adding the source address in the BFD Discriminator
attribute as an optional TLV. I think that might be a good extension that
can be introduced in a new document.

> When is it ok to do it?  IOW, why is this action recommended, and not
GIM>> Thank you for pointing this out. I agree that it is the requirement.
s/SHOULD NOT/MUST NOT/

> Path Down and/or Reverse Concatenated Path Down"    Which one?
GIM>> Thank you. This is the editorial error, clearly, it is "or". Which of
the two values is used may depend upon the detection mechanism used
monitoring the CE-PE link.

> bfd.LocalDiag to indicate the concatenated failure?
GIM>> I agree with you, that is the required behavior. s/SHOULD/MUST/

> it just to be supported (as written)?  Please be clear.
GIM>> This part of the document has been updated in the course of
addressing IESG comments:
   Such behavior is referred to as
   "revertive" behavior and MUST be supported.  Non-revertive behavior
   refers to the behavior of continuing to select the backup PE as the
   UMH even after the Primary has come up.  This non-revertive behavior
   MAY also be supported by an implementation and would be enabled
   through some configuration.  Selection of the behavior, revertive or
   non-revertive, is an operational issue, but it MUST be consistent on
   all PEs in the given MVPN.
Do you find the updated text clear enough?

> LOCAL_PREF attribute set to zero."  What should a receiver do if the
GIM>> I believe that the preceding text describes the situation when the
LOCAL_PREF != 0:
   ... 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.
> What action should it take if the LOCAL_PREF has a different value?
GIM>> Thank you for the suggestion, it clarifies the text. As I understand,
the requirement is for the Standby Upstream PE, not for a downstream PE.
Would the following update make that clearer:
OLD TEXT:
   The LOCAL_PREF attribute MUST be set to zero.
NEW TEXT:
   The new Upstream PE MUST set the LOCAL_PREF attribute to
   zero for that C-multicast route.

> (25) §4.3: "other mechanisms MAY be used"   s/MAY/may   This is just a
GIM>> Agree.

> since the normative action is in the next sentence ("MUST perform as
GIM>> Agree.

> (27) s/"hot root standby" mode is used (Section 4)/"hot root standby" mode
GIM>> Thank you for catching the wrong reference. Updated.

> (28) §7.3: s/sub-TLV/TLV/g   The attribute includes TLVs, not sub-TLVs.
GIM>> Agree and updated.

---

From: Reshad Rahman <[email-masked]>
Date: Thu, 17 Dec 2020 15:52:48 +0000 (UTC)

Thanks Alvaro, Jeff. Please see inline.
 
 On 2020-12-16 4:21 p.m., Jeffrey Haas wrote:
  
 Alvaro,

Thanks for drawing our attention to this document.  

On Tue, Dec 15, 2020 at 03:09:54PM -0800, Alvaro Retana via Datatracker wrote:
 
 Alvaro Retana has entered the following ballot position for
draft-ietf-bess-mvpn-fast-failover-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/

 
 I have the following comments about the BGP Path Attribute in question:

- BGP Packet space is sometimes at a premium.  The initial 3 octet reserved
  padding should be removed.
- The TLVs having a required length of multiples of 4 similarly are space
  wasting.
- The attribute does not make adequate provision for more than one type of a
  BFD Mode.  This likely limits the general purpose re-use of this attribute
  for other purposes.
- The length handling text is likely not correct:
  "The BFD Discriminator attribute MUST be considered malformed if its
   length is not a non-zero multiple of four."
  The implication is a length of four, which would have no BFD
  Discriminator, should be considered a valid PDU.  Note that the length
  considerations are further compounded by the padding issue for optional
  sub-tlvs in the prior point.

Since a BFD discriminator is 4-octets, I'm curious as to what discussion the
working group may have had with regard to using a BGP Extended Community
instead?  In particular, the BGP Extended Community's Transitive bit might
be useful in many multicast VPN scenarios operating over a single AS to
limit the distribution scope of this Discriminator.

The IANA allocation strategies for the Path Attribute and the Optional
Sub-TLVs seems reasonable.  Note that Experimental code points have proven
to be poorly used in BGP and that their use in the public Internet may
result in unexpected discard of the attribute.

 
 I will not speak for Reshad, but I don't recall this issue.  I may simply be
forgetting the e-mail brought to the list, if so. 
 
I tried to dig this up and here's the summarized history:
 
 There was some discussion right after IETF96 (I was at the BESS meeting): 
https://mailarchive.ietf.org/arch/msg/rtg-bfd/-D0iRI2aMSD9tkMWGObsmKGiXow/

Greg did bring this draft to the attention of the BFD WG in 2018 but there was no discussion:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/wQOhY6p9L3Z7f29VpNx_yRsCTZg/
 
AFAIK BFD WG wasn't involved in WGLC. 
Note that draft-ietf-bess-evpn-bfd reuses the mechanism for signaling BFD discriminator.

Regards, 
Reshad.

 The meta desire here is that communication of the BFD Discriminator for p2mp
sessions requires protocol help - in this case BGP.  While this could also
be discovered via provisioning, that would limit the flexibility of the
deployment of this feature.

For this specific internet-draft's purpose, dissemination of the
Discriminator is tightly scoped.  The fact that this happens under an
AFI/SAFI that is not expected to hit general purpose Internet routes limits
the blast radius of its use.  However, as you note, Alvaro, there may be
more general purpose desire to use this attribute for.

 Note: I wouldn't put special requirements here on the Extended Length bit.
That's core RFC 4271 Path Attribute behavior.

Similarly, overflow of Path Attributes is a general BGP consideration and it
is inapropriate to require this document to solve that.

-- Jeff

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 21 Dec 2020 08:00:35 -0800

Reshad/Jeff:

Hi!  Thanks for chiming in!

>From your replies, I'm not sure if you think the BFD WG should have
been involved more, or if you agree that it may be better to have a
general purpose attribute like this one developed in BFD, or if you
are ok with the current work. ??   With your bfd-chair hat, of course.

Thanks!

Alvaro.

On December 17, 2020 at 10:52:50 AM, Reshad Rahman wrote:
> > On Tue, Dec 15, 2020 at 03:09:54PM -0800, Alvaro Retana wrote:

> > > (2b) The fact that BFD monitoring can be achieved without the new
> > > attribute makes me think that the bootstrapping of BFD using BGP would
> > > be better served in a document produced by the BFD WG. One of the
> > > editors has expressed the same opinion [1] [2]. Has a discussion taken
> > > place in the  BFD WG (or at least with the Chairs) about this work? Why
> > > was it not taken up there?
> >
...
> > >
> > I will not speak for Reshad, but I don't recall this issue. I may simply
> > be forgetting the e-mail brought to the list, if so.
>
> > The meta desire here is that communication of the BFD Discriminator for
> > p2mp sessions requires protocol help - in this case BGP. While this could
> > also be discovered via provisioning, that would limit the flexibility of
> > the deployment of this feature.
> >
> > Discriminator is tightly scoped. The fact that this happens under an AFI/
> > SAFI that is not expected to hit general purpose Internet routes limits

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Dec 2020 11:48:29 -0500

Álvaro,

> are ok with the current work. ??   With your bfd-chair hat, of course.

The BFD RFC series makes it pretty clear that BFD will often require help
for bootstrapping or discovering sessions.  Part of our charter is to help
review the work from other Working Groups when they do that.  So, it's
appropriate to flag it for BFD WG review minimally as part of WGLC.

In this case, the responses you're seeing from me have a bit more to do with
my background in BGP rather than BFD. :-)  I would heartily suggest that IDR
get a chance to look at the mechanism in more detail since it likely will be
used in a more general fashion for other protocol extensions in BGP.

What I think we're seeing is the usual impedence mismatch in BESS where work
eventually moves to move general BGP mechanisms and additional IDR scrutiny
was needed.

My recommendation is to extend WGLC to BFD and IDR.

My personal opinion, not speaking as BFD chair, is that the mechanism is
generally fine and in need of the minimal PDU encoding advice I've already
given.

-- jeff

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 21 Dec 2020 12:00:38 -0800

I agree with that.

Thanks Jeff!

Alvaro.

On December 21, 2020 at 11:30:54 AM, Jeffrey Haas ([email-masked]) wrote:

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 21 Dec 2020 12:00:59 -0800

On December 20, 2020 at 7:24:34 PM, Greg Mirsky wrote:

Greg:

Hi!

I'm leaving in only the parts where we don't agree or where I have commments.

Thanks!

Alvaro.

...
> > tunnel (in §3), none of which "provide a "fast failover" solution when
> > used alone, but can be used together with the mechanism described in
> > Section 4" (§1). §3 also says this:
> >
> > downstream PEs to use the same mechanism, there are no guidelines to aid
> > the operator to chose which mechanism to use. Some cases may be obvious
> > (e.g. §3.1.3 applies to tunnels of a specific type), but others are not.
> > I would like to see deployment considerations related to the advantages/
> > disadvantages that each method may have in specific situations (including
> > their possible combination).
>
> analysis of P-tunnel monitoring methods is useful it doesn't seem to benefit
> this document as the choice of a developer which ones to implement and an
> operator which one to use don't affect the functionality discussed in the
> draft. Would you agree?

No, I don't.  That's the reason for this DISCUSS point. :-)

Why is this document specifying multiple mechanisms?  Why not specify
just one?  At a high level, I assume the answer is that one size
doesn't fit all, and that specific deployments might benefit from
specific mechanisms while others may not be as useful.   I don't think
that to provide guidance (I'm not asking for in-depth analysis) there
needs to be a priori agreement on use cases, etc...beyond what the WG
has already been considering for the development of this document.

Your initial statement that "it might be not that simple to compare"
is precisely the reason I think that operational guidance is needed.

> > proper configuration of course). Why is that option is not even mentioned
> > in the document?
>
> (https://datatracker.ietf.org/doc/draft-mirsky-mpls-p2mp-bfd/)where several

No, but thanks for pointing at that other draft which supports the
fact that the attribute is not the only way to bootstrap the session.

My point here is that you don't need the attribute for BFD to be an
useful tool.  However, the description of the tool (monitoring) is
tied to the attribute (including the point below about deleting the
BFD session).  It doesn't have to be: the use of BFD should be
independent of the bootstrapping mechanism.

Do you consider other possible ways of bootstrapping the session
valid?  Would it be ok to use them to enable the use of BFD?  Can a
BFD session that is setup using a different mechanism used to monitor
the tunnel?

...
> > attribute makes me think that the bootstrapping of BFD using BGP would be
> > better served in a document produced by the BFD WG. One of the editors has
> > expressed the same opinion [1] [2]. Has a discussion taken place in the
> > BFD WG (or at least with the Chairs) about this work? Why was it not taken
> > up there?
> >
> GIM>> Work on draft-mirsky-mpls-p2mp-bfd is progressing at MPLS WG. AFAIK,
> it is in the state Candidate for WG Adoption. Moving the definition of the
> BFD Discriminator attribute to that draft, as I understand, would require
> using it as the normative reference. Comparing the current states of both
> documents, would severely delay the publication of MVPN Fast Failover
> specification and likely affect implementations of P-tunnel monitoring
> mechanisms. I hope you can agree with the current organization of the
> document.

That doesn't address my question about whether this work should have
been done in the BFD WG -- as you had suggested (links above).

I'm sure you saw the message I sent to Reshad/Jeff on this topic.
I'll rely on their and Martin's opinion.  BTW, I agree with Jeff in
that bfd/idr should be given the opportunity to review this document.

...
> GIM>> I think that the use of the normative form is reasonable. The sentence
> can be re-worded using MAY. For example:
> OLD TEXT:
> The procedure described here MAY be used in a BGP/MPLS MVPN [RFC6513]. It is
> based on a downstream PE taking into account the status of P-tunnels rooted
> at each possible Upstream PE, for including or not including each given PE
> in the list of candidate UMHs for a given (C-S, C-G) state.
>
> We wanted to stress that without this mechanism BGP/MPLS MVPN, as defined in
> RFCs 6513 and 6514, is fully functional and architecturally complete. This
> draft discusses mechanisms that support the protection and faster

No, I don't.  Normative language was not meant for emphasis.  In any
case, this is not a blocking comment.

...
> > (4) §3.1.1: "similar to BGP next-hop tracking" Is this specified
> > somewhere? I don't remember seeing a specification for next-hop tracking,
> > but do know that implementations do it -- in an implementation-specific
> > way. Please add a little more text about what is meant/expected.
>

Suggestion:

OLD>
   BGP next-hop tracking is a feature that reduces the BGP convergence time
   comparing to the "regular" BGP by monitoring BGP next-hop address changes
   in the routing table. It's event-based because it detects changes in the
   routing table. When it detects a change, it performs a next-hop scan to
   find if any of the next hops in the BGP table is affected and updates it
   accordingly.

NEW>
   BGP next-hop tracking monitors BGP next-hop address changes in the routing
   table.  In general, when a change is detected, it performs a next-hop scan
   to find if any of the next hops in the BGP table is affected and updates it
   accordingly.>

...
> > (6) The "reachability condition" is mentioned in §3.1.1/§3.1.3/§3.1.4.
> > Does this mean that that root tracking (§3.1.1) should be used with the
> > other mechanisms? The specific text says that "the downstream PE can
> > immediately update its UMH when the reachability condition changes",
> > giving the impression that the combination is possible but not required.
> >
> unnecessary complexity. The last paragraph in Section 3.1 is intended as the
> introduction to sub-sections that discuss different monitoring mechanisms:
>

See the first DISCUSS point above.

You didn't explicitly answer the question:  is the text in
§3.1.1/§3.1.3/§3.1.4 an implication that root tracking should be used
with the other mechanisms?  If not, then that does it mean?

...
> > (8) §3.1.2 mentions that "careful consideration and coordination" is
> > needed when using other mechanisms such as rfc4090 "because uncorrelated
> > timers might cause unnecessary switchovers and destabilize the network."
> > What are the associated timers related to the mechanisms in this section?
>

Can you add something like that to the document?

...
> review and we've asked for the expert's opinion. Jeffrey Zhang kindly
> suggested the current text. (https://mailarchive.ietf.org/arch/browse/bess/?gbt=1&index=LxKYi9F6u1tl2qKtR2Q8wkQPMOA)
> I'll check with him and get back with the answer.

ok.

...
> > (12) §3.1.5 says that "where this mechanism is used in conjunction with
> > the method described in Section 5...downstream PEs can compare reception
> > on the two P-tunnels to determine when one of them is down", but §5 says
> > that "downstream PEs accept traffic from the primary or standby tunnel,
> > based on the status of the tunnel (based on Section 3)". IOW, §3.1.5
> > points at §5 as providing a way to determine if a tunnel is down, while §5
> > points back at §3 as the way to determine which tunnel to receive from.
> > This pointing back and forth is not a total contradiction, but it needs to
> > be clarified.
>

Let me try again.

§3.1.5 says that the "PEs can compare reception on the two P-tunnels
to determine when one of them is down".  OTOH, §5 says that the "PEs
accept traffic from the primary or standby tunnel, based on the status
of the tunnel".  The difference that I'm trying to point at is that §5
says that traffic is accepted from only *one* tunnel ("primary *or*
standby"), but §3.1.5 talks about receiving from *both*.

Adding "periodically" doesn't help because the basic contradiction
(receiving from one or both) is still there.

> > (13) §3.1.6: "An implementation that does not recognize or is configured
> > not to support this attribute MUST follow procedures defined for optional
> > recognize...this attribute" because, by definition, it can't be assumed
> > that it is aware of this specification. In this case, it is not necessary
> > to say anything about unrecognized attributes because that is already
> > specified in rfc4271.
> >
> > For the "configured not to support this attribute" case, it should be
> > pointed out that the node should operate as if the attribute was
> > unrecognized.
> >
> > Suggestion>
> from other IESG reviewers, this text was updated to: This document defines
> the format and ways of using a new BGP attribute called the "BFD
> Discriminator". It is an optional transitive BGP attribute. Thus it is
> expected that an implementation that does not recognize or is configured not
> to support this attribute follows procedures defined for optional transitive
> path attributes in Section 5 of [RFC4271].

Mmmm...sure.

rfc4271 doesn't talk about the case where a node is "configured not to
support" an attribute.  The reason I suggested the specific link
("configured not to support this attribute...as if the attribute was
unrecognized.") is that the behavior of ignoring (which may be an
interpretation of "configured not to support") is different than if
the attribute was unrecognized.  The text above doesn't make that link
and, while some implementations may interpret it the way you meant it,
others may not.

> > (15) §3.1.6: "The BFD Discriminator attribute MUST be considered malformed
> > if its length is not a non-zero multiple of four." Ok, except that the
> > specification of the attribute doesn't mention the length (only the length
> > of the TLVs). Please specify the length and any considerations related to
> > the Extended Length bit. Also, given that this is a new attribute, with an

Partially. ;-)

He's right about the Extended Length bit.

My reference to rfc8654 is because of this text from §5:

   It is RECOMMENDED that BGP protocol developers and implementers are
   conservative in their application and use of BGP Extended Messages.
   Future protocol specifications MUST describe how to handle peers that
   can only accommodate 4,096 octet messages.

As I mentioned before, it concerns me that the attribute (while having
a narrow use in this document) can have wider applicability.  The
extensibility is significant by allowing sequential or nested TLVs.
This combination may result in a large attribute, leading to large
Updates, specially when considering other MVPN-related
attribute/communities, etc.

Considering the text in rfc8654, the question is: is the attribute
necessary always, or can it be removed/omitted in some cases?  This is
not an attribute that is necessary for route selection, for example.
Given that rfc4271 says this:

   If, due to the limits on the maximum size of an UPDATE message (see
   Section 4), a single route doesn't fit into the message, the BGP
   speaker MUST not advertise the route to its peers and MAY choose to
   log an error locally.

...it may be possible that by not propagating the new attribute the
size of the update will be reduced so that the advertisement can be
made.  OTOH, if the attribute is removed then the tunnel can't be
monitored.

All I want is for you to consider any potential implications of the
new attribute.  The conclusion may be that no further change is
needed.

...
> follow: To enable downstream PEs to track the P-tunnel status using a point-
> o MUST use its, i.e., the Upstream PE's, IP address as the source IP address

No -- the question is which address of the Upstream PE?  I'm assuming
that an upstream PE can have several addresses, which one is to be
used?  I can guess it is the address of the interface used to reach
the destination (or something like that)...but I would just want it to
be clear.

> > (18) §3.1.6.2: If the IP address doesn't map correctly at the downstream
> > PE (for example, a different local address is used that doesn't correspond
> > to the information in the PMSI attribute), what action should it take? Can
> > the tunnel still be monitored?
>
> than one P-tunnel. Since each Upstream PE assigns its own BFD Discriminator,
> there's a chance that the same value is picked by more than one Upstream PE.
> According to Section 5.7 of the RFC 8562:
> We may consider adding the source address in the BFD Discriminator attribute
> as an optional TLV. I think that might be a good extension that can be
> introduced in a new document.

Why wait for a new document?  You made a pretty good case for
signaling the source address.

...
> > revertive behavior is the default, is that the intent? Or if the intent
> > for it just to be supported (as written)? Please be clear.
>
> GIM>> This part of the document has been updated in the course of addressing
> IESG comments:
> Such behavior is referred to as "revertive" behavior and MUST be supported.
> Non-revertive behavior refers to the behavior of continuing to select the
> backup PE as the UMH even after the Primary has come up. This non-revertive
> behavior MAY also be supported by an implementation and would be enabled
> non-revertive, is an operational issue, but it MUST be consistent on all PEs
> in the given MVPN.
>

Yes.  But it now brings up a new question: can you provide operational
guidance on the selection of this behavior?

> > (23) §4.1: "...routes that carry the "Standby PE" BGP Community MUST have
> > the LOCAL_PREF attribute set to zero." What should a receiver do if the
> > LOCAL_PREF is not zero?
>

No, it doesn't.  The text specifies that the update "MUST have the
LOCAL_PREF attribute set to zero".  The question is not about the
potential effect, but about the value being anything else (> 0).  Note
that the value can be low enough (> 0) and no adverse effect may take
place, but the text doesn't specify a "low value", it explicitly
specifies 0.

> > (24) §4.1: In the last paragraph of this section, if I follow correctly,
> > the text talks about the case where the standby becomes the primary and
> > the updated advertisement doesn't have the Standby PE community. If that
> > is correct, then s/ presence/absence of the Standby PE BGP Community/
> > absence of the Standby PE BGP Community
> >
> the requirement is for the Standby Upstream PE, not for a downstream PE. Would
> the following update make that clearer:
> OLD TEXT:

I don't know what the difference in the meaning is. :-(

There are three parts to my question:

(1) If the community is not present, then this would be a "normal"
Update.  How does the receiver know the difference so it can enforce
the "MUST"?

(2) What should the receiver do if the value is not as specified?

(3) Given that the LOCAL_PREF for Updates *with* the community MUST be
0, what's the use of sending Updates *without* the community with the
same value?

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 22 Dec 2020 19:59:06 -0800

Hi Alvaro,
thank you for giving me more details to work with. Please find my notes and
the new proposed updates in-line below under the GIM2>> tag. Attached is
the diff that highlights changes related to your DISCUSS and COMMENT.

Regards,
Greg

On Mon, Dec 21, 2020 at 12:01 PM Alvaro Retana <[email-masked]>
wrote:

> benefit
GIM2>> I propose a new sub-section to summarize the benefits and challenges
of methods described in Section 3.1:
3.1.8.  Operational Considerations for Monitoring P-Tunnel's Status

   Several methods to monitor the status of a P-tunnel are described in
   Section 3.1.  Though there might be no perfect method, a comparison
   of benefits and challenges of each technique could be helpful to both
   implementors and network operators.

   Tracking the root of an MVPN (Section 3.1.1) concludes about the
   status of a P-tunnel based on the control plane information.
   Because, in general, the MPLS data plane is not fate-sharing with the
   control plane, this method might produce false positive or false
   negative alarms.  On the other hand, because BGP next-hop tracking is
   broadly supported and deployed, this method might be the easiest to
   deploy.

   Method described in Section 3.1.2 monitors the state of the data
   plane but only for an egress P-PE link of a P-tunnel.  As a result,
   network failures that affect upstream links might not be detected
   using this method and the MVPN convergence would be determined by the
   convergence of the BGP control plane.

   Using the state change of a P2MP RSVP-TE LSP as the trigger to re-
   evaluate the status of the P-tunnel (Section 3.1.3) relies on the
   mechanism used to monitor the state of the P2MP LSP.

   The method described in Section 3.1.4 is simple and prone to false
   alarms but it is applicable to a sub-set of MVPNs, those that use the
   leaf-triggered x-PMSI tunnels.

   Though some MVPN might be used to provide a multicast service with
   predictable interpacket interval (Section 3.1.5), the number of such
   cases seem limited.

   Monitoring the status of a P-tunnel using p2mp BFD session
   (Section 3.1.6) may produce the most accurate and expedient failure
   notification of all monitoring methods discussed.  On the other hand,
   it requires careful consideration of the additional load of BFD onto
   network and PE nodes.

> BFD session that is setup using a different mechanism used to monitor

GIM2>> Thank you for clarifying the question. Yes, a p2mp BFD session can
be instantiated using some other than the BFD Discriminator attribute
method. draft-mirsky-mpls-p2mp-bfd gives several options and describes how
MPLS LSP Ping can be used. But that method, in my opinion, has some
operational issues and is less preferable compared to using an extension of
a control plane protocol. Other examples of extending a protocol to
bootstrap a p2mp BFD session can be found in the draft.
I've added a note in the first paragraph of Section 3.1.6 to clarify that
the use of the BFD Discriminator attribute is optional:
NEW TEXT:
   The P-tunnel status may be derived from the status of a multipoint
   BFD session [RFC8562] whose discriminator is advertised along with an
   x-PMSI A-D Route.  A P2MP BFD session can be instantiated using a
   mechanism other than the BFD Discriminator attribute, e.g., MPLS LSP
   Ping ([I-D.mirsky-mpls-p2mp-bfd]).  Description of these methods is
   outside the scope of this document.

> be
GIM2>> I'm leaving this decision to the AD and Chairs of BESS and BFD WGs.

> It is
GIM>> Switched to the lower case version of "optional"

>    to find if any of the next hops in the BGP table is affected and
GIM2>> Thank you for the proposed text. Accepted.

> the
GIM2>> I hope that a new sub-section added in the response to the first
DISCUSS clarifies this question.

> Can you add something like that to the document?
GIM2>> I've used that text to update the last paragraph of Section 3.1.2:
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.  When using multi-layer protection, particular consideration
   must be given to the interaction of defect detections at different
   layers of a network.  It is recommended to use longer detection
   intervals at the higher layers.  Some recommendations suggest using a
   multiplier of 3 or larger, e.g., 10 msec detection for the link
   failure detection and at least 100 msec for the tunnel failure
   detection.  In many cases, it is not practical to use both protection
   methods at the same time because uncorrelated timers might cause
   unnecessary switchovers and destabilize the network.

> > suggested the current text. (
> https://mailarchive.ietf.org/arch/browse/bess/?gbt=1&index=LxKYi9F6u1tl2qKtR2Q8wkQPMOA
> )
GIM2>> After the discussion, we've decided to make it the requirement,
i.e., s/SHOULD/MUST/

> (receiving from one or both) is still there.
GIM2>> Thank you for further clarifying your point. I propose to update
that bullet point in Section 5 as follows:
   o  a policy controls downstream PEs from which tunnel to accept
      traffic.  For example, the policy could be based on the status of
      the tunnel or tunnel monitoring method (Section 3.1.5).

> and, while some implementations may interpret it the way you meant it,
GIM2>> Thank you for the suggested clarification of the text. Hope the
updated text is clearer:
NEW TEXT:
   Thus it is expected that an implementation
   that does not recognize or is configured not to support this
   attribute, as if the attribute was unrecognized, follows procedures
   defined for optional transitive path attributes in Section 5 of
   [RFC4271].

> new attribute.  The conclusion may be that no further change is
GIM2>> Thank you for further clarifying your comment. We are not defining
any extensions to the BFD Discriminator attribute and it may not be
possible to imagine all the potential extensions that could be proposed in
the future. It seems that it will be more appropriate to review the impact
of the specific extension of the BFD Discriminator attribute when it will
be proposed. At that time, we'll need to consider that excluding the BFD
Discriminator attribute from an update will be interpreted as the removal
of the corresponding p2mp BFD session. That would not cause a switchover
but just make MVPN failover to rely on the convergence of the BGP control
plane.

> the destination (or something like that)...but I would just want it to
GIM2>> Thank you, I now better understand the question. It it the PE
address in the given VRF. I propose the following update:
NEW TEXT:
    o  MUST use its PE address as the source IP address when transmitting
      BFD Control packets;
Also, I think that the text in the next section that defines the process on
a downstream PE needs clarification. I propose to update text as follows:
OLD TEXT:
   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 [RFC6514] the BFD Control packet was received on to
      properly demultiplex BFD sessions.
NEW TEXT:
   o  to properly demultiplex BFD session MUST use:

         the address of the PE that included the BFD Discriminator
         attribute in the x-PMSI A-D Route;

         the value of the BFD Discriminator field in the BFD
         Discriminator attribute;

         the x-PMSI Tunnel Identifier [RFC6514] the BFD Control packet
         was received on.

> Discriminator,
> attribute
GIM2>> I'd like to defer this question to our AD and BESS WG Chairs.

> addressing
GIM2>> I think that the decision to prefer revertive behavior is based on
the resource allocation model for primary and standby P-tunnels. In cases
where the switchover to the standby tunnel does not affect other services
and provides the required quality of service, an operator might use
non-revertive behavior to avoid unnecessary in such case switchover and
thus minimize disruption to the multicast service. I'd propose that be
added as follows:
NEW TEXT:
While revertive is considered the default
   behavior, there might be cases where the switchover to the standby
   tunnel does not affect other services and provides the required
   quality of service.  An operator might use non-revertive behavior to
   avoid unnecessary in such case switchover and thus minimize
   disruption to the multicast service.

> place, but the text doesn't specify a "low value", it explicitly
GIM2>> I think I see it better now. Would the following text work:
NEW TEXT:
   For this purpose, routes that carry the Standby PE BGP
   Community MUST have the LOCAL_PREF attribute set to the value lower
   than the value specified as the LOCAL_PREF attribute for the route
   that does not carry the Standby PE BGP Community.  The value of zero
   is RECOMMENDED.
Also, the text regarding setting the LOCAL_PREF after the switchover may
need, in my view, the update to not require it is set to zero:
NEW TEXT:
   The new Upstream PE MUST set the LOCAL_PREF attribute
   for that C-multicast route to the same value as when the Standby PE
   BGP Community was included in the advertisement.

> 0, what's the use of sending Updates *without* the community with the
GIM2>> Had the change above addressed this comment?

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 23 Dec 2020 08:16:29 -0800

On December 22, 2020 at 10:59:19 PM, Greg Mirsky wrote:

Greg:

Hi!

I think we have converged on the first two DISCUSS points.  On the
third one, I do want to give bfd/idr an opportunity to comment -- I
agree with you that we should wait for Martin (I believe he's out for
the rest of the year).

There are just a couple of comments left.

Thanks!!

Happy Holidays!

Alvaro.

> > > > (1) ...
> of methods described in Section 3.1: 3.1.8. Operational Considerations for
> Monitoring P-Tunnel's Status

This is a good start.

There are some nits/grammar enhancements that I'll leave for now.  A
couple of other comments/questions in-line.

> implementors and network operators.

"a comparison of benefits and challenges of each technique could be helpful"

The "could" makes it sound as if that is work for another
day/document.  Simply get rid of that last sentence.

> broadly supported and deployed, this method might be the easiest to

"...might produce false positive or false negative alarms."

Maybe add something like "resulting in tunnels that seem up but are
not able to reach the root, or ones that are declared down
prematurely" -- just to explain a little the potential effect.

> convergence of the BGP control plane.

"...would be determined by the convergence of the BGP control plane."

This is a case where it seems that combining §3.1.1/§3.1.2 would make
sense. In fact, tracking the state of the root seems helpful in other
cases too (below) that are looking at different things.  You said
before that you didn't think combining the methods make sense -- can
you please explain why in this section?

> leaf-triggered x-PMSI tunnels.

"false alarms"

As with the false indicators above, maybe include a simple example of
the effect.

> it requires careful consideration of the additional load of BFD onto

"requires careful consideration of the additional load of BFD"

A reference would be nice.

> > > > (2) ...
> GIM2>> Thank you for clarifying the question. Yes, a p2mp BFD session can be
> instantiated using some other than the BFD Discriminator attribute method.
> draft-mirsky-mpls-p2mp-bfd gives several options and describes how MPLS LSP
> Ping can be used. But that method, in my opinion, has some operational
> issues and is less preferable compared to using an extension of a control
> plane protocol. Other examples of extending a protocol to bootstrap a p2mp
> BFD session can be found in the draft.
>

Ok, that's fine.  See a related comment below (15).

> > > > (2b) ...
> > > >
> > BTW, I agree with Jeff in > that bfd/idr should be given the opportunity
> > to review this document.
>

Yup.

...
> > > > (15) §3.1.6: "The BFD Discriminator attribute MUST be considered
> > > > malformed if its length is not a non-zero multiple of four." Ok,
> > > > except that the specification of the attribute doesn't mention the
> > > > length (only the length of the TLVs). Please specify the length...

Don't forget to specify the length of the attribute.

...
> any extensions to the BFD Discriminator attribute and it may not be possible
> to imagine all the potential extensions that could be proposed in the
> future. It seems that it will be more appropriate to review the impact of
> the specific extension of the BFD Discriminator attribute when it will be
> proposed. At that time, we'll need to consider that excluding the BFD
> Discriminator attribute from an update will be interpreted as the removal of
> the corresponding p2mp BFD session. That would not cause a switchover but
> just make MVPN failover to rely on the convergence of the BGP control plane.

Fair enough.

Two more comments (related, but different):

(a) Being that the attribute (just like other attributes) is not
protected, it can be removed in flight (for example, by a rogue node).
As you mentioned, that action will not cause a switchover, but (from
the end of §3.1.6) the BFD session will be deleted causing the tunnel
to be left unmonitored.  There isn't much that can be done about this,
but it should be mentioned somewhere (maybe the Security
Considerations section).

(b) Back to my DISCUSS point about not needing the attribute to
bootstrap the BFD session:  If the BFD session is already up (maybe it
was done using the attribute or maybe it was manually configured, it
doesn't matter), then not including the attribute disables the
monitoring, regardless of how the session was set up.  The last
paragraph in §3.1.6 says this:

   If the downstream PE's P-tunnel is already established, its state
   being monitored by the P2MP BFD session, and the downstream PE
   receives the new x-PMSI A-D Route without the BFD Discriminator
   attribute, and the x-PMSI A-D Route was processed without any error
   as per the relevant specifications, the downstream PE:

I guess the intent was to say: "if the BFD session was set up using
the attribute and the attribute is not present anymore".  But the text
doesn't make that clarification, and a direct reading would result in
deleting the BFD session even if the attribute was not used.

Suggestion>
   If the downstream PE's P-tunnel is already established, its state being
   monitored by the P2MP BFD session set up using the BFD Discriminator
   Attribute...

> > > > (17) ...
> GIM2>> Thank you, I now better understand the question. It it the PE address
> in the given VRF. I propose the following update:
>
> NEW TEXT:

I'm not sure that "PE address" is the best clarification.  I'll let
you figure it out. :-)

> Also, I think that the text in the next section that defines the process on a
> downstream PE needs clarification. I propose to update text as follows:
> OLD TEXT:

This looks good.

> > > > (18) §3.1.6.2(http://3.1.6.2): If the IP address doesn't map correctly
> > > > at the downstream PE (for example, a different local address is used
> > > > that doesn't correspond to the information in the PMSI attribute),
> > > > what action should it take? Can the tunnel still be monitored?
> > >
> > > GIM>> There's a possibility that the same downstream PE is monitoring
> > > more than one P-tunnel. Since each Upstream PE assigns its own BFD
> > > Discriminator, there's a chance that the same value is picked by more
> > > than one Upstream PE.
> > > attribute as an optional TLV. I think that might be a good extension
> > > that can be introduced in a new document.
> >

Again, you made a good case for why it is needed for the mechanism to
work.  Leaving it for later might just leave a hole.  Sure, let's hear
from the Chairs/AD.

...
> > > > (23) ...

Yeah...I still have a problem with "MUST have the LOCAL_PREF attribute
set to the value lower than..." because there's no practical way to
enforce that by the receiver: if the update with the community comes
in first then now the receiver was to remember to check when the other
update comes in later...

s/MUST/must
The "RECOMMENDED" part should be enough.

> BGP Community was included in the advertisement.

Same thing here: s/MUST/must

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 23 Dec 2020 10:51:01 -0800

Hi Alvaro,
happy Holidays to you and everyone you care about!

Thank you for the great discussion and thought stimulating clues. I've
added more follow-up notes in-line now tagged by GIM3>>.

Regards,
Greg

> agree with you that we should wait for Martin (I believe he's out for
GIM3>> I'm glad you feel we've converged on the two DISCUSSes.

> There are just a couple of comments left.
GIM3>> OKay

> prematurely" -- just to explain a little the potential effect.
GIM3>> Thank you for the specific examples.

> you please explain why in this section?
GIM3>> But that would be my personal opinion that the WG might not agree.
I'm always glad to discuss technical ideas, pros, and contras of that or
this approach to solve the problem but I feel uneasy adding my personal
opinions in the WG document. The document lists a set of techniques but how
they are combined in a product is left for product managers and developers
to decide. Would you agree?

> As with the false indicators above, maybe include a simple example of
GIM3>> Ooops, I meant to write "not prone" as "safe from causing false
alarms".
NEW TEXT:
   The method described in Section 3.1.4 is simple and is safe from
   causing false alarms, e.g., considering a tunnel operationally up
   even though its data path has a defect or, conversely, declaring a
   tunnel failed when it is unaffected.  But the method applies to a
   sub-set of MVPNs, those that use the leaf-triggered x-PMSI tunnels.

> A reference would be nice.
GIM3>> I've updated the text with some details. Please let me know if it
works:
NEW TEXT:
   Operators should consider the rate of BFD
   Control packets transmitted by root PEs combined with the number of
   such PEs in the network.  In addition, the number of P2MP BFD
   sessions per PE determines the amount of state information that a PE
   maintains.
> > GIM2>> I'm leaving this decision to the AD and Chairs of BESS and BFD
GIM3>> Resulting from the discussion with Jeff, the text we've agreed to is
now as follows:
NEW TEXT:
   The BFD Discriminator attribute MUST be considered malformed if its
   length is smaller than five octets or if Optional TLVs are present,
   but not well-formed.
> possible
GIM3>> Thank you for the detailed and clear explanation. I've used the
suggested text.

> I'm not sure that "PE address" is the best clarification.  I'll let
GIM3>> RFC 6513 refers to the Upstream PE Address. The PE Distinguisher
Labels Attribute, defined in RFC 6514, includes the PE Address field. BFD
must use the same PE address.

> > the x-PMSI Tunnel Identifier [RFC6514] the BFD Control packet
GIM3>> Thank you.

> The "RECOMMENDED" part should be enough.
GIM3>> Applied

> Same thing here: s/MUST/must
GIM3>> Applied

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 23 Dec 2020 12:36:21 -0800

On December 23, 2020 at 1:51:13 PM, Greg Mirsky wrote:

Greg:

I have just one reply.  I am also leaving in the text where we're
waiting for Chair/AD input.

Thanks!!

Alvaro.

...
> they are combined in a product is left for product managers and developers

The document already talks about combinations, specifically with root tracking.

The text above already mentions "convergence of the BGP control
plane", which I think makes direct reference to root tracking.  §3.1.3
and §3.1.4 both say that "the downstream PE can immediately update its
UMH when the reachability condition changes" -- this is the exact same
text used in §3.1.1 to describe root tracking.

The opinion of not combining is already not represented in the text,
and there is direct reference to using an additional method.  If you
didn't mean to use the same text to refer to different things then
perhaps some clarification would be in order.

...

...
> > > > > > (18) §3.1.6.2(http://3.1.6.2): If the IP address doesn't map
> > > > > > correctly at the downstream PE (for example, a different local
> > > > > > address is used that doesn't correspond to the information in the
> > > > > > PMSI attribute), what action should it take? Can the tunnel still
> > > > > > be monitored?
> > > > >