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

[Alvaro Retana <[e-mail]>]

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.



> > > > ----------------------------------------------------------------------
> > > > DISCUSS:
> > > > ----------------------------------------------------------------------
> > > >
> > > > (1) ...
> > > >
> > Your initial statement that "it might be not that simple to compare"
> > is precisely the reason I think that operational guidance is needed.
>
> 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

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.


> 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.

"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.


> 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.

"...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.


> 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.

"...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?


> 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.

"false alarms"

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


> 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.

"requires careful consideration of the additional load of BFD"

A reference would be nice.




> > > > (2) ...
> > > >
> > 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?
>
> 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.

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.
>
> GIM2>> I'm leaving this decision to the AD and Chairs of BESS and BFD WGs.

Yup.




> > > > ----------------------------------------------------------------------
> > > > COMMENT:
> > > > ----------------------------------------------------------------------
...
> > > > (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.



...
> > 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.
>
> 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.

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) ...
> > > >
> > 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.
>
> 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;

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:
> 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.

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.
> > > 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.
> >
> > Why wait for a new document? You made a pretty good case for
> > signaling the source address.
>
> GIM2>> I'd like to defer this question to our AD and BESS WG Chairs.

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) ...
> > > >
> > 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.
>
> 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.

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.


> 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.

Same thing here: s/MUST/must