[bess] Stephen Farrell's No Objection on draft-ietf-bess-mvpn-bidir-ingress-replication-03: (with COMMENT)

2015-10-15 Thread Stephen Farrell
Stephen Farrell has entered the following ballot position for
draft-ietf-bess-mvpn-bidir-ingress-replication-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-bidir-ingress-replication/



--
COMMENT:
--


I have one less and two more serious comments...

- Less seriously, "MP2MP tunnel" seems like a strange use of
language, I wondered if it might be better to call these an
MP2MP warren (as in rabbit warren, and of course bearing in
mind the ops-dir review:-)

- More seriously, this is another draft that simply has too
many acronyms and uses those too densely. For example, I just
find it really hard to believe that "If a PE, say PEx, is
connected to a site of a given VPN, and PEx's next hop
interface to some C-RPA is a VRF interface, then PEx MUST
advertises a (C-*,C-*-BIDIR) S-PMSI A-D route, regardless of
whether it has any local Bidir-PIM join states corresponding
to the C-RPA learned from its CEs" is a useful sentence to
implementers. IMO enough folks have commented on this aspect
that the wg would be wise to seriously consider the
readibility of their output.  I've worked on enough EU-funded
projects that had write-only documents to be worried if the
IETF starts to produce those.  (This is not a discuss since
I've been assured that this is not a problem for implementers,
and while I do accept that, I also continue to worry about
it.)

- I am simply not in a position to evaluate section 4. And nor
was the assigned secdir reviewer. The same point about density
and that making any secdir review hard to impossible was noted
by the secdir reviewer for draft-ietf-bess-mvpn-bidir. I don't
think it'd be valid for me to put on a discuss on the basis
that nothing this complex has "no new security issues" but it
was tempting.

Overall, I think it would be best if this were returned to the
wg asking for significant improvement in clarity for readers.


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


Re: [bess] Poll for adoption: draft-morin-bess-mvpn-fast-failover

2015-10-15 Thread Martin Vigoureux

Authors,

we are 1 day before the deadline and I am missing feedbacks on IPR from:
Kanwar, Ray, Praveen, Jayant, Pradeep, Clayton, Nehal, and Rahul.

So please, do reply.

In the meantime, additional positions wrt the document are welcome from 
the WG participants.


-m

Le 02/10/2015 12:29, Martin Vigoureux a écrit :

Hello working group,

This email starts a two-week poll on adopting
draft-morin-bess-mvpn-fast-failover [1] as a working group item.

Please send comments to the list and state if you support adoption or
not (in the later case, please also state the reasons).

This poll runs until the *16th of October*.

Currently there is no IPR disclosed against this document.

*Coincidentally*, we are also polling for knowledge of any IPR that
applies to this draft, to ensure that IPR has been disclosed in
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for
more details).

*If you are listed as a document author or contributor* please respond
to this email and indicate whether or not you are aware of any relevant
IPR.

The draft will not be adopted until a response has been received from
each author and contributor.

If you are not listed as an author or contributor, then please
explicitly respond only if you are aware of any IPR that has not yet
been disclosed in conformance with IETF rules.

Thank you,

Martin & Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-morin-bess-mvpn-fast-failover

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess




___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


Re: [bess] Poll for adoption: draft-morin-bess-mvpn-fast-failover

2015-10-15 Thread Eric C Rosen

I support the adoption of this draft by the WG.


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


[bess] Feedback on draft-boutros-bess-vxlan-evpn-00.txt

2015-10-15 Thread Sami Boutros (sboutros)
Hi,

The draft has been around for almost 3 years and it is about interconnecting 
VXLAN or NVGRE networks with data plane mac learning via EVPN, the draft is 
informational and describe as well some useful use cases.

Thanks,

Sami
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


[bess] I-D Action: draft-ietf-bess-ir-02.txt

2015-10-15 Thread internet-drafts

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the BGP Enabled Services Working Group of the 
IETF.

Title   : Ingress Replication Tunnels in Multicast VPN
Authors : Eric C. Rosen
  Karthik Subramanian
  Zhaohui Zhang
Filename: draft-ietf-bess-ir-02.txt
Pages   : 22
Date: 2015-10-15

Abstract:
   RFCs 6513, 6514, and other RFCs describe procedures by which a
   Service Provider may offer Multicast VPN service to its customers.
   These procedures create point-to-multipoint (P2MP) or multipoint-to-
   multipoint trees across the Service Provider's backbone.  One type of
   P2MP tree that may be used is known as an "Ingress Replication (IR)
   tunnel".  In an IR tunnel, a parent node need not be "directly
   connected" to its child nodes.  When a parent node has to send a
   multicast data packet to its child nodes, it does not use layer 2
   multicast, IP multicast, or MPLS multicast to do so.  Rather, it
   makes n individual copies, and then unicasts each copy, through an IP
   or MPLS unicast tunnel, to exactly one child node.  While the prior
   MVPN specifications allow the use of IR tunnels, those specifications
   are not always very clear or explicit about how the MVPN protocol
   elements and procedures are applied to IR tunnels.  This document
   updates RFCs 6513 and 6514 by adding additional details that are
   specific to the use of IR tunnels.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-ir/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-bess-ir-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-ir-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess