Re: [Gen-art] Gen-ART Last Call review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

[<[e-mail]>]

Hi Brian,

2015-09-30, Brian E Carpenter:
> "Good consensus among a solid although small set of contributors
> (two vendors on the draft and a third vendor supporting the proposal)."
> I wonder if that really means "Nobody else cares." Going back in the
> bess and l3vpn mail archives, I only found one significant technical
> discussion (on the original individual draft version).

As doc shepherd, let me explain why I wrote this.

The draft addresses a niche of a niche of a niche, at the crossroads of 
IP multicast and BGP VPNs, for a specific way of carrying over an MPLS 
backbone a very particular flavor of IP multicast.

It does not mean nobody cares. The proposal is relevant, but it happens 
that it addresses a niche^3 of a technology that very few contributors 
master.


>>   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]
>
> You can't understand the current document without consulting ietf-bess-ir.
> For example, there are numerous instances of the phrase "IR P-tunnel" which
> is defined by ietf-bess-ir. IMHO, it's therefore a normative reference.

We have discussed, and I believe resolved, this issue with Alvaro.
The right reference for ingress replication is RFC6513, rather than 
I-D.ietf-bess-ir which merely updates the material related to ingress 
replication in RFC6513/RFC6514.


>> The label may be shared
>> with other P-tunnels, subject to the anti-ambiguity rules for
>> extranet [I-D.ietf-bess-mvpn-extranet].
>
> This or similar words appear several times. An implementer cannot implement
> the current document without consulting ietf-bess-mvpn-extranet. IMHO, it's
> therefore a normative reference.

This spec is standalone and can be implemented without knowing about 
I-D.ietf-bess-mvpn-extranet. We'll work on reformulating the text to 
make that clear.


>
> Minor Issues:
> -------------
>
>> These specifications update RFC 6514.
>
> Is that actually true? Or is it just an *extension* of RFC 6514, which
> doesn't merit a formal "Updates: 6514"? [In other words, will anything bad
> happen if an implementation of RFC 6514 doesn't add this?]
>
>> 1.  Introduction
>>
>>    Section 11.2 of RFC 6513, "Partitioned Sets of PEs", describes two
>>    methods of carrying bidirectional C-flow traffic over a provider core
>>    without using the core as RPL or requiring Designated Forwarder
>>    election.
>
> Which RPL is that? Propbably not RFC6550. Whatever it means, it needs
> to be expanded when first used.

Correct.
(It is the Bidir-PIM Rendez-vous Point Link, RFC5015).

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.