[Editorial Errata Reported] RFC6513 (3658)

The following errata report has been submitted for RFC6513,
"Multicast in MPLS/BGP IP VPNs".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6513&eid=3658

--------------------------------------
Type: Editorial
Reported by: Joël Repiquet <joelrepiquet@...>

Section: 5.3.1

Original Text
-------------
   Whenever a C-multicast route is sent, it must also carry the Selected
   Upstream Multicast Hop corresponding to the C-root address
   (determined by the procedures of Section 5.1).  The Selected Upstream
   Multicast Hop must be encoded as part of a Route Target Extended
   Community to facilitate the optional use of filters that can prevent
   the distribution of the update to BGP speakers other than the
   Upstream Multicast Hop.  See Section 10.1.3 of [MVPN-BGP] for the
   details.

Corrected Text
--------------
   Whenever a C-multicast route is sent, it must also carry the Selected
   Upstream Multicast Hop corresponding to the C-root address
   (determined by the procedures of Section 5.1).  The Selected Upstream
   Multicast Hop must be encoded as part of a Route Target Extended

Comments on draft-zzhang-l3vpn-mvpn-bidir-ingress-replication-00.txt

This is an interesting and potentially useful draft.

The major issue I see is that while the draft does not say that it is
applicable only to non-segmented IR P-tunnels, I don't see how it will work
if IR P-tunnels are segmented at ASBRs or ABRs.  The draft seems to use the
term "Upstream Multicast Hop" (UMH) to mean "Upstream PE", which would be
okay only if non-segmented IR P-tunnels are out of scope.

Comments in-line, look for ****.

Abstract

   RFC 6513 described a method to support bidirectional C-flow using
   "Partial Mesh of MP2MP P-Tunnels".  This document describes how
   partial mesh of MP2MP P-Tunnels can be simulated with Ingress
   Replication, instead of a real MP2MP tunnel.

**** I'd add to the abstract that this enables a Service Provider to use
**** Ingress Replication to offer transparent BIDIR-PIM service to its VPN
**** customers.

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.

   With these two methods, all PEs of a particular VPN are separated
   into partitions, with each partition being all the PEs that elect the

[Editorial Errata Reported] RFC4364 (3649)

The following errata report has been submitted for RFC4364,
"BGP/MPLS IP Virtual Private Networks (VPNs)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4364&eid=3649

--------------------------------------
Type: Editorial
Reported by: Bharat Joshi <bharat_joshi@...>

Section: 4.3.2

Original Text
-------------
Then if a route is potentially reachable over more than one attachment circuit, the PE/CE routing can
switch the preferred path for a route from one attachment circuit to another, without there being any need
to distribute new a label for that route

Corrected Text
--------------
Then if a route is potentially reachable over more than one attachment circuit, the PE/CE routing can
switch the preferred path for a route from one attachment circuit to another, without there being any need
to distribute a new label for that route

Notes
-----
'distribute new a label' should be 'distribute a new label'.

Instructions:

[Editorial Errata Reported] RFC4364 (3648)

The following errata report has been submitted for RFC4364,
"BGP/MPLS IP Virtual Private Networks (VPNs)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4364&eid=3648

--------------------------------------
Type: Editorial
Reported by: Bharat Joshi <bharat_joshi@...>

Section: 4

Original Text
-------------
If two routes to the same IP address prefix are actually routes to different systems, it is important to
ensure that BGP not treat them as comparable.

Corrected Text
--------------
If two routes to the same IP address prefix are actually routes to two different systems, it is important to
ensure that BGP not treat them as comparable.

Notes
-----
'routes to different system' should be 'routes to two different system'

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please

[Editorial Errata Reported] RFC4364 (3647)

The following errata report has been submitted for RFC4364,
"BGP/MPLS IP Virtual Private Networks (VPNs)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4364&eid=3647

--------------------------------------
Type: Editorial
Reported by: Bharat Joshi <bharat_joshi@...>

Section: 3.2

Original Text
-------------
If it is desired to have a particular host be in multiple virtual sites, then that host must determine, for
each packet, which virtual site the packet is associated with. 

Corrected Text
--------------
If it is desired to have a particular host to be in multiple virtual sites, then that host must determine, for
each packet, which virtual site the packet is associated with.

Notes
-----
'host be' should be 'host to be'

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please

FW: New Version Notification for draft-zzhang-l3vpn-mvpn-bidir-ingress-replication-00.txt

FYI

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Monday, June 03, 2013 5:49 PM
To: Yakov Rekhter; Andrew Dolganow; Jeffrey (Zhaohui) Zhang
Subject: New Version Notification for draft-zzhang-l3vpn-mvpn-bidir-ingress-replication-00.txt


A new version of I-D, draft-zzhang-l3vpn-mvpn-bidir-ingress-replication-00.txt
has been successfully submitted by Jeffrey Zhang and posted to the
IETF repository.

Filename:	 draft-zzhang-l3vpn-mvpn-bidir-ingress-replication
Revision:	 00
Title:		 Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication
Creation date:	 2013-06-03
Group:		 Individual Submission
Number of pages: 13
URL:             http://www.ietf.org/internet-drafts/draft-zzhang-l3vpn-mvpn-bidir-ingress-replication-00.txt

Status:          http://datatracker.ietf.org/doc/draft-zzhang-l3vpn-mvpn-bidir-ingress-replication

Htmlized:        http://tools.ietf.org/html/draft-zzhang-l3vpn-mvpn-bidir-ingress-replication-00



Abstract:
   RFC 6513 described a method to support bidirectional C-flow using
   "Partial Mesh of MP2MP P-Tunnels".  This document describes how
   partial mesh of MP2MP P-Tunnels can be simulated with Ingress
   Replication, instead of a real MP2MP tunnel.

FW: New Version Notification for draft-yong-l3vpn-nvgre-vxlan-encap-01.txt

FYI. Welcome a comment on this.

Lucy

> -----Original Message-----
> From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
> Sent: Tuesday, May 21, 2013 9:24 AM
> To: Lucy yong; Xuxiaohu; Xuxiaohu
> Subject: New Version Notification for draft-yong-l3vpn-nvgre-vxlan-
> encap-01.txt
> 
> 
> A new version of I-D, draft-yong-l3vpn-nvgre-vxlan-encap-01.txt
> has been successfully submitted by Lucy Yong and posted to the
> IETF repository.
> 
> Filename:	 draft-yong-l3vpn-nvgre-vxlan-encap
> Revision:	 01
> Title:		 NVGRE and VXLAN Encapsulation for L3VPN Extension
> Creation date:	 2013-05-21
> Group:		 Individual Submission
> Number of pages: 7
> URL:             http://www.ietf.org/internet-drafts/draft-yong-l3vpn-

> nvgre-vxlan-encap-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-yong-l3vpn-

> nvgre-vxlan-encap
> Htmlized:        http://tools.ietf.org/html/draft-yong-l3vpn-nvgre-

> vxlan-encap-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-yong-l3vpn-

> nvgre-vxlan-encap-01

Comments on draft-jain-mvpn-bgp-sitetype-attribute-00.txt

I have a few comments on draft-jain-mvpn-bgp-sitetype-attribute-00.txt.

This draft seems to assume the following combination of circumstances:

1. Each VRF of a given MVPN originates an Intra-AS I-PMSI A-D route.

2. Each such route contains a PMSI Tunnel attribute specifying a tunnel of
   type "RSVP-TE P2MP LSP" or of type "Ingress Replication".

3. Some of the VRFs are connected only to sites that have multicast senders
   but no multicast receivers.  (It is not clear from the draft whether this
   is supposed to be known by provisioning, or learned dynamically.)

According to the procedures of RFC6514, each such VRF will become the root
of an inclusive P-tunnel (e.g.,an RSVP-TE P2MP LSP), and will add the other
VRFs as leaf nodes.  This draft proposes that if a VRF, say VRF1, has no
receivers, it should add a "sender-only attribute" to its Intra-AS I-PMSI
A-D route.  Then if another VRF, say VRF2, imports VRF1's Intra-AS I-PMSI
A-D route, VRF2 will know not to add VRF1 to the inclusive P-tunnel of which
VRF2 is the root.

The draft does not actually point out that its applicability is limited to
the case where the tunnel type is RSVP-TE or Ingress Replication, but its
procedures do not make any sense otherwise.  The draft also fails to point
out that its applicability is restricted to the case where the inclusive
P-tunnels are not segmented, though this may be inferred from the fact that
there are no procedures given for Inter-AS I-PMSI A-D routes.  The draft
also needs to point out that its procedures will not work properly if PIM is
the C-multicast protocol.

I-D Action: draft-ietf-l3vpn-mvpn-mldp-nlri-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF.

	Title           : Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes
	Author(s)       : IJsbrand Wijnands
                          Eric C. Rosen
                          Uwe Joorde
	Filename        : draft-ietf-l3vpn-mvpn-mldp-nlri-01.txt
	Pages           : 11
	Date            : 2013-05-15

Abstract:
   Many service providers offer "BGP/MPLS IP VPN" service to their
   customers.  Existing IETF standards specify the procedures and
   protocols that a service provider uses in order to offer this service
   to customers who have IP unicast and IP multicast traffic in their
   VPNs.  It is also desirable to be able to support customers who have
   MPLS multicast traffic in their VPNs.  This document specifies the
   procedures and protocol extensions that are needed to support
   customers who use the Multicast Extensions to Label Distribution
   Protocol (mLDP) as the control protocol for their MPLS multicast
   traffic.  Existing standards do provide some support for customers
   who use mLDP, but only under a restrictive set of circumstances.
   This document generalizes the existing support to include all cases
   where the customer uses mLDP, without any restrictions.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-mldp-nlri

Biggest Fake Conference in Computer Science

Biggest Fake Conference in Computer Science

We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.

We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware

Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 

We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 

Query regarding rfc4684 Constrained Route Distribution