Hello Greg, Thanks for this. I’m cutting down to places where we still need to interact. Look for [af] and blue text. Nothing alarming. Best, Adrian
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 NEW TEXT: Section 4 describes optional protocol extensions that can speed up 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>.
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.
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”.
GIM>> In this section the state of a P-tunnel is equated with the state of the last link of that tunnel. The document notes that if the link is Up, then the P-tunnel is considered down. It is implied, that if it is determined that the link is Down, then the state of the P-tunnel is considered Down. Would you recommend adding an explanation to the document?
GIM>> Indeed. It is analogous to "it was Up the last time I've checked on it". It meant to be used when the interval between checking is significant.
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?>….”
GIM>> Will the following text reflect that: NEW TEXT: An implementation may support any combination of the methods to choose which one to use in the particular deployment. [af] Good.
GIM>> I think that the same handling applies as for the malformed attribute: If malformed, the UPDATE [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 [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:
GIM>> I think that is not an actionable 'must'. It could be expressed as
Would you recommend using the re-worded passage? [af] The alternative text is good.
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.”
GIM>> It suppose to be As long as C-S is reachable via the Primary Upstream PE, the Upstream PE is the Is it better? [af] That makes sense |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
