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.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
