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

[<[e-mail]>]

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.