Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

["Alvaro Retana (aretana)" <[e-mail]>]

On 9/28/15, 10:39 AM, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> wrote:

Jeffrey/Thomas:

Hi!

First of all, please note that the Gen-ART review that came in today had the same comment about the Normative references…which really indicates that if you want to change them, then (at least) the text needs to be clarified.

2015-09-28, Jeffrey (Zhaohui) Zhang:
Alvaro,
> I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative References.
I thought about this further, and would like to keep them both as informational for the following reasons.
The extranet draft is referred to in the draft as following:
   … The label may be shared
   with other P-tunnels, subject to the anti-ambiguity rules for
   extranet [I-D.ietf-bess-mvpn-extranet<https://tools.ietf.org/html/draft-ietf-bess-mvpn-bidir-ingress-replication-02#ref-I-D.ietf-bess-mvpn-extranet>].
Both extranet and label sharing are optional, not required for implementing the procedures in this draft.

I agree with that.
To make it more obvious that this is an informative comment, I think you could rewrite as: "These specifications do not prevent sharing of labels between P-tunnels (note that other specs put constraints on how that can be done, such as [I-D.ietf-bess-mvpn-extranet<https://tools.ietf.org/html/draft-ietf-bess-mvpn-bidir-ingress-replication-02#ref-I-D.ietf-bess-mvpn-extranet>])".

This proposed text changes what seems to be the original intent..if that was the goal, then I’m ok with something like it.  In fact, if the rules in ietf-bess-mvpn-extranet are not needed then don’t even mention them — referring to them just causes confusion as to whether they were needed.




As for draft-ietf-bess-ir: RFC 6514 specifies the use of IR P-tunnels, though there are some problems with RFC 6514's specification of IR P-tunnels, which are addressed in detail in draft-ietf-bess-ir.



Draft-ietf-bess-mvpn-bidir-ingress-replication explains how to support a VPN customer's use of BIDIR-PIM when the service provider uses IR P-tunnels, but it doesn't really depend on those details specified in draft-ietf-bess-ir. Thus draft-ietf-bess-ir should not be a normative reference for it.

The text says this:  "This document describes how the MP2MP tunnel can be simulated with a mesh of P2MP tunnels, each of which is instantiated by Ingress Replication [I-D.ietf-bess-ir].”  What you say above is that the reference here should be RFC6514, is that right?


Given that draft-ietf-bess-ir updates RFC6514/RFC6513 which our draft depends on Normatively, we might as well avoid mentioning it; making it a Normative ref would not buy much (but would delay publication until draft-ietf-bess-ir is published).

It has to be Normative it the functionality depends on it (see me question above).  There’s no way around that.

Note that the fact that I-D.ietf-bess-ir may update RFC6513/RFC6514 (if approved!) doesn’t mean anything at this point because the functionality that this document relies on (??) is not in those RFCs, or in any other RFC that updates them.

If the functionality in I-D.ietf-bess-ir is not needed, then just change the reference above.

Since its helpful to remind the reader of its existence, I would think it's good to keep it, and Informative is fine.

Why?  If the functionality in I-D.ietf-bess-ir is not needed, then just don’t mention it at all.

Thanks!

Alvaro.