Re: [RTG-DIR] Rtgdir last call review of draft-ietf-bess-mvpn-fast-failover-11

[Adrian Farrel <[e-mail]>]

Hi again,

 

Thanks for rapid convergence.

 

All good.

 

Adrian

 

Section 3 notes that the procedure (presumably the procedure defined
in this section) is OPTIONAL. I didn't see anything similar in sections
4 and 5 stating that those procedures are optional. Presumably, since
this document is not updating any other RFCs, all of these procedures
are optional.

Actually it would be good to clarify how all these procedures fit in
with "legacy" deployments, and how they are all optional procedures. I
think that needs a short statement in the Introduction and a small
section of its own (maybe between 6 and 7).

GIM>> Thank you for the suggestion. I've updated the Introduction in this way:

OLD TEXT:

   Section 4 describes protocol extensions that can speed up failover by
   not requiring any multicast VPN routing message exchange at recovery
   time.

   Moreover, section 5 describes a "hot leaf standby" mechanism, that
   uses a combination of these two mechanisms.  This approach has
   similarities with the solution described in [RFC7431] to improve
   failover times when PIM routing is used in a network given some
   topology and metric constraints.

NEW TEXT:

   Section 4 describes optional protocol extensions that can speed up
   failover by not requiring any multicast VPN routing message exchange
   at recovery time.

   Moreover, Section 5 describes a "hot leaf standby" mechanism that can
   be used to improve failover time in MVPN.  The approach combines
   mechanisms defined in Section 3 and Section 4 has similarities with
   the solution described in [RFC7431] to improve failover times when
   PIM routing is used in a network given some topology and metric
   constraints.

I think that Section 5 is intended to explain how introduced BGP extensions and their use described in Section 3 and Section 4 enable operators to provide protection for multicast services. Would you suggest adding a new text to the section to highlight particular aspects of introducing protection in MVPN?

[af] OK I obviously wasn’t clear. What I’m looking for is something like…

The procedures described in this document are optional to enable an operator to provide protection for multicast services. An operator would enable these mechanisms using <foo> and it is assumed that these mechanisms would be supported by all <what?> in the network for the procedures to work. In the case that a BGP implementation does not recognise or is configured to not support the extensions defined in this document, it will respond <somehow> as described in <rfc????>. This would result in <something>.

GIM2>> I think I've got the idea now. Would appending the new paragraph to the Introduction address your comment:

NEW TEXT:

   The procedures described in this document are optional to enable an
   operator to provide protection for multicast services in BGP/MPLS IP
   VPNs.  An operator would enable these mechanisms using a method
   discussed in Section 3 in combination with the redundancy provided by
   a standby PE connected to the source of the multicast flow, and it is
   assumed that all PEs in the network would support these mechanisms
   for the procedures to work.  In the case that a BGP implementation
   does not recognize or is configured to not support the extensions
   defined in this document, it will continue to provide the multicast

   service, as described in [RFC6513]. 

 

[af] Perfect

 It is curious (to me) that 3.1.1 describes a way to know that a P-tunnel
is up.  You don't say, however, if being unable to determine that the
P-tunnel is up using this method is equivalent to determining that the
P-tunnel is down. (Previously in 3.1 you have talked about the "tunnel's
state is not known to be down".)

GIM>> This method, as noted in the document, is similar to BGP next-hop tracking, may be computationally intensive, and cannot be run frequently. So, in periods between checking whether the root address in the x-PMSI Tunnel attribute is reachable the state is "not known to be down".

[af] Well, OK. Can you add to say that, “If it is not possible to determine whether the state of a tunnel is ‘up’, the state shall be considered as ‘not known to be down’, and it may be treated as if it is ‘up’ so that attempts to use the tunnel are acceptable.” This is probably “obvious to one skilled in the art,” but would help this reader.

GIM2>> Thank you for the contributed text. I've added in before "not known to be Down" used in the text (with the yellowish background):

NEW 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.
   If it is not possible to determine whether a P-tunnel's current
   status is Up, the state shall be considered "not known to be Down",
   and it may be treated as if it is Up so that attempts to use the
   tunnel are acceptable.  The result is that, if a P-tunnel is Down
   (see Section 3.1), the PE that is the root of the P-tunnel will not
   be considered for UMH selection.  This will result in the downstream
   PE failing over to use the next Upstream PE in the list of
   candidates.  Some downstream PEs could arrive at a different
   conclusion regarding the tunnel's state because the failure impacts
   only a subset of branches.  Because of that, procedures described in
   Section 9.1.1 of [RFC6513] MUST be used when using I-PMSI P-tunnels.

 

[af] Thanks

 By the way, do you ever say that a P-tunnel has just these two statuses
(up and down) because that could make a big difference?

GIM>> I think that the document then needs to discuss what impact detection time has on MVPN. For example, if the detection time is in single-digit seconds, a two-state model can be used. But would it be a useful model if the detection time is in tens of seconds? Should a "not known to be down" state be introduced?

[af] Yes, that *seems* to be the implication. But is there any different action between “up” and “not known to be down”? If you have three states then there is (possibly) an implication that tunnels are prioritised by state. I think, however, that it is OK to use “not known to be down” as if it was “up”.

GIM2>> Thank you.

3.1.2

   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 protection
   methods at the same time.

OK, I considered them carefully. Now what? :-)

I think you have to give implementation guidance.

GIM>> I agree, an operational recommendation could be helpful. Usually, in case of multi-layered protection, detection intervals on the higher layer are 10 times of guaranteed restoration time of the lower layer. Would you recommend adding this to the text as an example of a deployment? 

[af] An example would be fine (and a forward reference from here). But it would be fine, maybe better, to offer half a sentence of guidance. So…”not practical to use both protection methods at the same time because <adverse interactions?>….”

GIM2>> Thank you for the explanation. Extended the last sentence:

NEW TEXT:

   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. 

 

[af] Great

3.1.6

What should I do if I don't recognise or support the setting of the BFD
Mode field?

GIM>> I think that the same handling applies as for the malformed attribute:

   If malformed, the UPDATE
   message SHALL be handled using the approach of Attribute Discard per

   [RFC7606]. 

I propose to extend the applicability of the rule with the following update to the sentence:

NEW TEXT:

   The BFD Discriminator attribute MUST be considered malformed if its
   length is not a non-zero multiple of four.  If the setting of the BFD
   Mode field is not recognized or not supported, or the attribute
   considered malformed, the UPDATE message SHALL be handled using the
   approach of Attribute Discard per [RFC7606].

 [af] This is a bit subtle and refers also to my first point in this email. If the setting of the BFD Mode is not recognised or not supported, then it is likely because this specification is not supported. Therefore, this specification cannot mandate how the implementation will behave. I think you have to separate:

*	The malformed SHALL be handled using Attribute Discard according to [RFC7606]
*	An unknown or unsupported attribute will be handled by implementations according to the procedures for unknown attributes described in <foo>

GIM2>> I thought of a different "unsupported" scenario. Consider BFD Discriminator attribute is supported but an implementation does not recognize the value in the BFD Mode field. In the case the BFD Discriminator is unknown or unsupported procedures defined for the optional transitive path attribute in Section 5 of RFC 4271 must be followed. I've removed the recent updated and added the reference to RFC 4271 (added as the Normative reference) following the definition of the new attribute:

NEW TEXT:

   This document defines the format and ways of using a new BGP
   attribute called the "BFD Discriminator".  It is an optional
   transitive BGP attribute.  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]. 

 

[af] That captures what I wanted to see. Thanks

==Nits:==

Section 3 has

   Because of that, procedures described in Section 9.1.1 of [RFC6513]
   MUST be used when using I-PMSI P-tunnels.

Aren't those procedures already mandatory? That section of 6513 already
uses "MUST" (although it oes go on to say that it might not be possible
to apply the procedure and delegates processing to 9.1.2 and 9.1.3 -
peculiarly using lowercase must for that delegation). I wonder whether
you are saying "this case is covered by the procedures of Section 9.1.1
of [RFC6513]" or are you actually defining new normative behaviour?

GIM>> I think that the use of lower case 'must' is ambiguous and somewhat confusing. You are right, the intention is to refer to Section 9.1.1 as the mandatory behavior. But neither 9.1.2, nor 9.1.3 use the normative language. What would you recommend?

[af] Maybe…

“Because of that, the procedures of Section 9.1.1 of [RFC6513] are applicable. That document is a foundation for this document and its processes all apply here. Section 9.1.1 mandates the use of specific procedures for sending intra-AS I-PMSI A-D Routes.”

GIM2>> Thank you for the text. Updated accordingly with noting "when using I-PMSI P-tunnels"

NEW TEXT:

Because of that, the procedures of
   Section 9.1.1 of [RFC6513] are applicable when using I-PMSI
   P-tunnels.  That document is a foundation for this document, and its
   processes all apply here.  Section 9.1.1 mandates the use of specific
   procedures for sending intra-AS I-PMSI A-D Routes.

 

[af] Fine