Hi Alvaro,
2015-09-30, Alvaro Retana (aretana):
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.
I would tend to think that the reformulation I proposed preserves the
original intent.
I would propose improving the rephrasing by taking into account the
sentence that follows:
Current:
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>]. For example, the (C-*,C-*-
BIDIR) and (C-*,C-G-BIDIR) S-PMSI A-D routes originated by a given PE
can optionally share a label.
Proposed:
These specifications do not prevent sharing of labels between P-tunnels,
such as a label being shared by a (C-*,C-*- BIDIR) and a (C-*,C-G-BIDIR)
S-PMSI A-D route originated by a given PE(note that other specs put
constraints on how that can be done, e.g. [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>]).
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.
I think that if this is clearly provided as an example then it can help
the reader have the right context information to better understand the spec.
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?
I'm the one who suggested referencing [I-D.ietf-bess-ir], but I have to
admit this creates confusion.
The best reference to provide for ingress replication is in fact RFC6513
section 2.1.2 (could be RFC6514 as well, but 6513 is the one having the
text explaining the concept). Both are updated by [I-D.ietf-bess-ir].
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.
Well, to my knowledge draft-ietf-bess-mvpn-bidir-ingress-replication
does not particularly depends on [I-D.ietf-bess-ir], but the
clarifications and minor fixes in [I-D.ietf-bess-ir] benefit to any mVPN
spec (including draft-ietf-bess-mvpn-bidir-ingress-replication).
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.
In fact, the functionality that this document depends on is described in
RFC6513 section 2.1.2.
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.
I think that a fine balance can sometimes be found and allow providing
more context.
I agree with you that this it not the case here.
Let's use RFC6513 section 2.1.2 as the reference for ingress
replication, and eventually let the reader find out by himself when/if
the IR-replication related materiel in this RFC is updated...
Best,
-Thomas
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
