headers
Ronald Bonica | 29 May 2013 15:36
Favicon

FW: New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

Folks,

If you get a chance, please provide a sanity check on this document. It is very short, so it won't take much
time to review.

                                         Ron

> -----Original Message-----
> From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
> Sent: Wednesday, May 29, 2013 9:34 AM
> To: Ronald Bonica
> Subject: New Version Notification for draft-bonica-intarea-gre-mtu-
> 00.txt
> 
> 
> A new version of I-D, draft-bonica-intarea-gre-mtu-00.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
> 
> Filename:	 draft-bonica-intarea-gre-mtu
> Revision:	 00
> Title:		 Generic Routing Encapsulation (GRE) Fragmentation
> Strategy
> Creation date:	 2013-05-29
> Group:		 Individual Submission
> Number of pages: 8
> URL:             http://www.ietf.org/internet-drafts/draft-bonica-
> intarea-gre-mtu-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-bonica-intarea-
> gre-mtu
(Continue reading)

Permalink | Reply | 14 comments |
headers
mohamed.boucadair | 7 May 2013 16:50

Re: draft-boucadair-intarea-host-identifier-scenarios

Dear Joshua,

Apologies for the delay to answer this message.

I see your point. I will add it to the list of items to be considered for the next iteration of the document. 

BTW, -03 already included some of requirements which cover security aspects (see for instance REQ#1,
REQ#2, REQ#3, REQ#9). Once we have a stable requirements list, we will identify the requirements which
are valid for each use case:
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-03#section-4.1 

Cheers,
Med

>-----Message d'origine-----
>De : Joshua Shire [mailto:jshire <at> hyduke.com] 
>Envoyé : vendredi 25 janvier 2013 08:17
>À : BOUCADAIR Mohamed OLNC/OLN; fmc <at> ietf.org; int-area <at> ietf.org
>Cc : draft-boucadair-intarea-host-identifier-scenarios <at> tools.ietf.org
>Objet : RE: draft-boucadair-intarea-host-identifier-scenarios
>
>Hello,
>
>I do not believe a pointer to 
>http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analys
>is-04#section-3  will be satisfactory for the security 
>considerations section. 
>
>http://www.ietf.org/rfc/rfc3552.txt  states that when writing 
>a security considerations section, the process "...should be
(Continue reading)

Permalink | Reply | 2 comments |
headers
johnsonhammond2 | 27 Apr 2013 18:50
Favicon

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Olivier Bonaventure | 17 Apr 2013 13:28
Picon
Favicon

Re: Comments and suggestiosn to draft-ietf-intarea-flow-label-balancing-00

Hello,

Here are some additional comments on the above draft. Section 4 suggests 
the utilisation of a hash to perform the load balancing based on the 
source-address/flow label pair. Hash functions are often used in load 
balancing applications. I think that it could be useful to point the 
advantages and the drawbacks of using hash functions for load balancing 
purposes.

The main advantage of hash functions is that they usually exhibit the 
avalanche effect, i.e. a small change in the input causes a large change 
in the output of the function. Simulations show that this effect is 
important to correctly balance real traffic.

However, with hash functions, this advantage comes with a drawback. It 
is difficult to predict the set of inputs that would provide a specific 
output. Being able to predict which decision will be taken by a load 
balancer is important for monitoring applications for example. If a 
network operator wants to verify the round-trip-time between two hosts 
when there is a load balancer in between, he/she should take into 
account this load balancing when defining his/her probes. A similar 
situation happens when a network operator wants to use traceroute to 
detect block holes on a load-balanced path.

It should be noted that there exist functions that exhibit the avalanche 
effect without being one-way functions like the classical hash 
functions. If used in load-balancers, these functions would provide both 
  good load balancing and predictibility which is desired for many 
monitoring applications. A recent paper shows how such load-balancing 
can be performed efficiently by using block ciphers instead of hash
(Continue reading)

Permalink | Reply | 2 comments |
headers
Donald Eastlake | 17 Apr 2013 08:08
Picon

Re: Reviewing of flow label balancing

Hi,

I think the draft is a good documentation of the issues and the
benefits of using the IPv6 flow ID with load balancing.

It would be more consistent with the completeness of the rest of the
document to have a more complete list of typical load balancer server
selection algorithms in the last paragraph of Section 5.

There are people who believe that Informational documents can't have
normative references. I am generally inclined that way myself.

Various descriptions in the draft, like "statistically rare" could be
made a bit more quantitative. I'm not saying a detailed numeric
analysis is needed but a rough number based on reasonable simplifying
assumptions might help to make things a little less fuzzy.

Those are all my comments.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3 <at> gmail.com

On Tue, Apr 16, 2013 at 2:57 AM, Sheng Jiang <jiangsheng <at> huawei.com> wrote:
> Hi, dear Donald,
>
> You agreed to review our flow label balancing document during the IntArea meeting in Orlando. The blow is
(Continue reading)

Permalink | Reply | 1 comment |
headers
internet-drafts | 16 Apr 2013 07:42
Picon
Favicon

I-D Action: draft-ietf-intarea-nat-reveal-analysis-09.txt


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

	Title           : Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments
	Author(s)       : Mohamed Boucadair
                          Joe Touch
                          Pierre Levis
                          Reinaldo Penno
	Filename        : draft-ietf-intarea-nat-reveal-analysis-09.txt
	Pages           : 23
	Date            : 2013-04-15

Abstract:
   This document is a collection of solutions to reveal a host
   identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or
   application proxies are involved in the path.  This host identifier
   could be used by a remote server to sort out the packets by sending
   host.  The host identifier must be unique to each host under the same
   shared IP address.

   This document analyzes a set of solution candidates to reveal a host
   identifier; no recommendation is sketched in the document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-09
(Continue reading)

Permalink | Reply | 0 comments |
headers
internet-drafts | 11 Apr 2013 16:11
Picon
Favicon

I-D Action: draft-ietf-intarea-nat-reveal-analysis-08.txt


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

	Title           : Analysis of Solution Candidates to Reveal a Host Identifier (HOST_IDENT) in Shared Address Deployments
	Author(s)       : Mohamed Boucadair
                          Joe Touch
                          Pierre Levis
                          Reinaldo Penno
	Filename        : draft-ietf-intarea-nat-reveal-analysis-08.txt
	Pages           : 23
	Date            : 2013-04-11

Abstract:
   This document is a collection of solutions to reveal a host
   identifier (denoted as HOST_IDENT) when a Carrier Grade NAT (CGN) or
   application proxies are involved in the path.  This host identifier
   could be used by a remote server to sort out the packets by sending
   host.  The host identifier must be unique to each host under the same
   shared IP address.

   This document analyzes a set of solution candidates to reveal a host
   identifier; no recommendation is sketched in the document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-08
(Continue reading)

Permalink | Reply | 1 comment |
headers
mohamed.boucadair | 11 Apr 2013 10:05

Re: IP Connectivity Provisioning Profile (draft-boucadair-connectivity-provisioning-profile)

Dear all,

We edited an I-D which proposes a global framework making use of the Connectivity Provisioning Profile.
The document is available here:
http://tools.ietf.org/html/draft-sin-sdnrg-sdn-approach-02 

I'm sharing this information as it may be of interest of this working group.

Comments are more than welcome on both I-Ds.

Cheers,
Med

>
>On 10/12/2012 05:20 AM, mohamed.boucadair <at> orange.com wrote:
>> Dear all,
>> 
>> We submitted this new I-D which may be of interest of this WG. 
>> 
>> This is an effort trying to capture and expose the IP 
>connectivity service provided by the network layer to upper 
>services, to adjacent networks, offered/delivered to 
>customers, etc. The document focuses on the definition of the 
>CPP itself and does not discuss for instance how this is 
>translated into configuration data/policies to be enforced in 
>underlying nodes.
>> 
>> Abstract:
>>    This document describes the Connectivity Provisioning 
>Profile (CPP)
(Continue reading)

Permalink | Reply | 0 comments |
headers
internet-drafts | 10 Apr 2013 10:58
Picon
Favicon

I-D Action: draft-ietf-intarea-nat-reveal-analysis-07.txt


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

	Title           : Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments
	Author(s)       : Mohamed Boucadair
                          Joe Touch
                          Pierre Levis
                          Reinaldo Penno
	Filename        : draft-ietf-intarea-nat-reveal-analysis-07.txt
	Pages           : 22
	Date            : 2013-04-10

Abstract:
   This document is a collection of solutions to reveal a host
   identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or
   application proxies are involved in the path.  This host identifier
   could be used by a remote server to sort out the packets by sending
   host.  The host identifier must be unique to each host under the same
   shared IP address.

   This document analyzes a set of solution candidates to reveal a host
   identifier; no recommendation is sketched in the document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-07
(Continue reading)

Permalink | Reply | 1 comment |
headers
Linda Dunbar | 5 Apr 2013 22:53
Favicon

Comments and suggestiosn to draft-ietf-intarea-flow-label-balancing-00

Sheng, Brian, el at: 

I reviewed draft-ietf-intarea-flow-label-balancing-00

Here are my comments:
-------------------------------------

The draft is to suggest using IPv6 header's flow label field to identify different flows from IPv6 hosts.
The draft tries to emphasize that the flow label can help devices along the way between Source &
destination to achieve better flow separation or finer tuned traffic balancing if there are multiple
paths. 

However, the Section 3 devotes so much to various LB schemes. But many are irrelevant. There are many
different types of Load Balance, the DNS based load balancing, which is often called global LB,  has
nothing to do with LB in front of a cluster of servers. 

Some description about LB in Section 3 is not quite to the point. For example, the second bullet you stated:
"Another method, for HTTP servers, is to operate a layer 7 reverse proxy in front of the server farm." The LB
in front of a cluster of servers is orthogonal to DNS based global LB. 

Your draft didn't even mention "Direct Server Return (DSR)" LB scheme which is used heavily in DC to balance
load among a cluster of servers. In this scheme, all the servers in a cluster share a common IP address which
is same as the LB, or use floating IP address for hosts. 

The figure in Page 7 is has some errors too. The DNS based Load Balancing is usually in the Access network. (I
really think this figure is not necessary because it doesn't help the draft at all). 

The LB for Server Cluster is more likely located in a Data Center. 

Therefore, I suggest that you replace Section 3 with following:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Suresh Krishnan | 26 Mar 2013 05:39
Picon
Favicon

IETF86 minutes available

Hi all,
  The draft minutes from the Orlando intarea meeting are now
available at

http://www.ietf.org/proceedings/86/minutes/minutes-86-intarea

Please review these minutes and send us changes/additions by April 27,
2013. We would like to thank Stuart Cheshire for taking the minutes.

Regards
Suresh & Julien
Permalink | Reply | 0 comments |

Gmane