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: 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. 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: 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): 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”.
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: 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 I propose to extend the applicability of the rule with the following update to the sentence: 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: 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" 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 |
