headers
Xu Xiaohu | 1 Sep 2010 03:36
Favicon

Re: Alternative option for IP-only L2VPN?//re: New VersionNotification for draft-xu-virtual-subnet-02

Hi Himanshu,

> -----邮件原件-----
> 发件人: Himanshu Shah [mailto:hshah <at> force10networks.com]
> 发送时间: 2010年8月31日 23:34
> 收件人: Xu Xiaohu; l2vpn <at> ietf.org
> 抄送: int-area <at> ietf.org; l3vpn <at> ietf.org; rtgwg <at> ietf.org
> 主题: RE: Alternative option for IP-only L2VPN?//re: New
VersionNotification
> for draft-xu-virtual-subnet-02
> 
> Comments in line..
> 
> Thanks,
> himanshu
> 
> -----Original Message-----
> From: l2vpn-bounces <at> ietf.org [mailto:l2vpn-bounces <at> ietf.org] On Behalf Of
Xu
> Xiaohu
> Sent: Friday, August 27, 2010 11:40 PM
> To: l2vpn <at> ietf.org
> Cc: int-area <at> ietf.org; l3vpn <at> ietf.org; rtgwg <at> ietf.org
> Subject: re: Alternative option for IP-only L2VPN?//re: New Version
> Notification for draft-xu-virtual-subnet-02
> 
> Hi all,
> 
> Since there is no comment till now, let me make some comments on the IPLS
> first.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Xu Xiaohu | 1 Sep 2010 08:22
Favicon

Re: Alternative option for IP-only L2VPN?//re: New VersionNotification for draft-xu-virtual-subnet-02

Hi all,

An updated version of Virtual Subnet (VS) is now available at
http://tools.ietf.org/html/draft-xu-virtual-subnet-03.

Major technical changes include:
1) A section of VS vs VPLS is added.
2) A section of VS vs IPLS is added.
3) Multicast/broadcast mechanism is simplified.
4) CE host discovery mechanism is completed by adding an option of ARP
request for ALL-Systems multicast group address (i.e., 224.0.0.1).

Best wishes,
Xiaohu

> -----邮件原件-----
> 发件人: Himanshu Shah [mailto:hshah <at> force10networks.com]
> 发送时间: 2010年8月31日 23:34
> 收件人: Xu Xiaohu; l2vpn <at> ietf.org
> 抄送: int-area <at> ietf.org; l3vpn <at> ietf.org; rtgwg <at> ietf.org
> 主题: RE: Alternative option for IP-only L2VPN?//re: New
VersionNotification
> for draft-xu-virtual-subnet-02
> 
> Comments in line..
> 
> Thanks,
> himanshu
> 
> -----Original Message-----
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rémi Després | 2 Sep 2010 09:57
Picon
Favicon

Re: Review of draft-narten-ipv6-3177bis-48boundary-05

+1

Le 20 août 2010 à 22:35, Brian E Carpenter a écrit :

> On 2010-08-21 08:23, Fred Baker wrote:
>> On Aug 20, 2010, at 12:49 PM, Eric Gray wrote:
>> 
>>> 	Having multiple chunk sizes seems to me to be a recipe for in-
>>> efficient use of address space in general.  
>> 
>> speaking for myself, I think a one-size-fits-all model has the same effect. In my home, today, I have two
LANs; I could easily imagine expanding that to half a dozen or even a dozen in various scenarios. Giving me a
/48 is a waste of address space - it's at least 4096 times as much as I need, and would give my upstream the
ability to address 4095 more homes like mine if they were to allocate /60's. To the extent that they are
paying their RIR for address space, er, membership, it wastes their money and increases my monthly
payment. 
>> 
>> I think there is a great reason to suggest that access and transit networks to offer their downstreams
/48, /52, /56, and /60 options at various costs. It makes business sense for them, allows them to
reasonably recover their costs without burdening the downstreams, allows for downstreams to number
their networks in ways they like and reasonably move up to shorter prefixes when they need to, and (since I
didn't mention /64) ensures that the smallest users - residential/SOHO - have options for routing within
the home as appropriate.
> 
> Another +1 to Fred. I was originally a strong advocate of Eric's view,
> in fact I take credit/blame for a lot of RFC3177, but I believe that
> experience, especially the remarkable success of CIDR in controlling
> the growth of PA routes for IPv4, and the acquired wisdom of the RIRs
> in administering CIDR, have shown that there is no efficiency benefit
> in fixed chunks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Hinden | 8 Sep 2010 21:38
Picon

Re: introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]


On Aug 31, 2010, at 11:33 AM, Dan Wing wrote:

> A paper was published in 2004 which analyzed the success of new IP options
> and new TCP options,
> 
>  "Measuring Interactions Between Transport Protocols and Middleboxes"
>  Alberto Medina, Mark Allman, Sally Floyd
>  http://conferences.sigcomm.org/imc/2004/papers/p336-medina.pdf
> 
> In Section 4.3, it showed a new IP Option resulted in a 70% connection
> failure, whereas
> Section 4.4 shows a new TCP option resulted in only a 0.2% connection
> failure.  I do 
> not expect things have improved on the Internet for IP options, and my
> testing with 
> nmap to the top 500 websites also has very high failure when sending an TCP
> SYN
> with an IP option.
> 
> Using an IP Option on today's Internet seems unworkable, unless we do
> something
> creative like sending two packets (one with the IP option, one without) and
> react accordingly.  This will probably break UDP-based application protocols
> 
> that don't expect packets to arrive twice, and of course doubles traffic for
> TCP until the address sharing device learns if the server supports or
> rejects
> IP options - which is more state to maintain.
>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Warren Kumari | 10 Sep 2010 22:09

Asking for int-area review of: draft-ietf-opsec-ip-security-03.txt

Hey all,

This document (draft-ietf-opsec-ip-security) has completed OpSec WG last call, but due to the breadth
and scope of this the OPS ADs have asked that it get additional socializing in the int-area:

http://datatracker.ietf.org/doc/draft-ietf-opsec-ip-security/

(This was also presented by Joel Jaeggli in the int-area meeting at IETF78)

While Joe Touch has already provided very valuable int-area perspective, additional review before
submitting to the IESG would be great....

We realize that it is a large document and that reviewing it will take significant time, but would really
appreciate your views and input within 2 weeks (by 00:00 09/25/2010) if you could.

Thank you
Warren Kumari (OpSec WG co-chair).
Permalink | Reply | 1 comment |
headers
Christian Vogt | 13 Sep 2010 22:58
Picon
Favicon

Reviews of "IP Router Alert Considerations" document

Folks, FYI:

We have asked Fred Baker, Joel Halpern, Suresh Krishnan, and Ron Bonica to review Francois' document "IP
Router Alert Considerations and Usage" [1].  Based on these reviews, and based on the reviews of other
working group members, we will decide on whether the document is ready for working group last call.  Your
participation in this discussion will be appreciated.

- Christian

[1] http://tools.ietf.org/html/draft-ietf-intarea-router-alert-considerations
Permalink | Reply | 4 comments |
headers
Joel M. Halpern | 14 Sep 2010 04:33

Re: Your availability for a pre-WGLC document review

[Christian asked that we bring the review discussion to the list, with 
all context.  Thus, I am sending my reply, based on Francois' comments 
on my review, to the list with all context.]

Unfortunately, with regard to the arguments for their being a difference 
between Router Alert and BGP, I think one could reasonably disagree with 
all three points in the document.  I am not sure it is worth arguing, 
since whether the distinction in this dimension is real or not does not 
change the point of the document.  And the point of the document is 
quite well taken.  The three points you list are, simplified, core 
isolation, information termination, and configured peerings.

Given that there are not clear distinctions in practice between core 
routers and edge routers (there are routers that are primarily for 
internal use, and routers that are primarily for peering use, and 
routers that are primarily for customer facing use, but the distinctions 
all get blurred), I am not sure the first point in this portion of the 
document works.

The second point, while apparently accurate, does not match teh reality 
of issues that have been observed where incorrect information can get 
propagated through the BGP system, causing quite widespread problems. 
(The details vary from case to case, but the point is that many kinds of 
problems have managed to spread.)

The argument for their being less of na issue since peerings are 
configured is probably true.  However, given that the security 
mechanisms currently are deployed in very weak fashions (keys basically 
never change, for example), there are still very similar vulnerabilities 
there.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Fred Baker | 14 Sep 2010 06:03
Picon
Favicon

Re: Your availability for a pre-WGLC document review


On Sep 13, 2010, at 9:33 PM, Joel M. Halpern wrote:

> Given that there are not clear distinctions in practice between core routers and edge routers (there are
routers that are primarily for internal use, and routers that are primarily for peering use, and routers
that are primarily for customer facing use, but the distinctions all get blurred), I am not sure the first
point in this portion of the document works.

I really wish the IETF would talk about core-facing interfaces and edge-facing interfaces than about core
and edge routers. Edge-facing interfaces face customers and therefore have link speeds and policy
appropriate to a customer SLA; core-facing interfaces don't, and are driven by very different
requirements. In any non-trivial network, edge routers have many edge-facing interfaces and a few
core-facing interfaces.

The kind of router we generally call a "core router" is probably one that has only core-facing interfaces -
it directly serves no customers, but may connect to one or more peer or upstream networks. That,
unfortunately, is a distinction easier made in theory than in practice.

Even that is well over-simplified. But it at least makes the attributes one might want to talk about
attributes of the interface rather than of the router, which is at least technically correct at that level.
Permalink | Reply | 0 comments |
headers
Jari Arkko | 14 Sep 2010 12:01

BOFs for IETF-79

We have received four proposals for BOFs in for the upcoming meeting (on 
distributed mobility management, ARP improvements, light-weight IP 
stack, and name-based sockets). And more in the other areas. In about a 
week we will be making decisions about what to do about these things. If 
you are interested in participating the discussions or have opinions to 
share, I know the both the organizers of these efforts as well as the 
ADs would appreciate feedback and additional participation.

More information about these efforts and their mailing lists are shown 
in http://tools.ietf.org/bof/trac/wiki/WikiStart

Jari and Ralph
Permalink | Reply | 0 comments |
headers
Francois Le Faucheur | 14 Sep 2010 14:45
Picon
Favicon

Re: Your availability for a pre-WGLC document review

Hello Joel,

Your considerations about the three BGP points are certainly valid. I don't think they completely
invalidate the points, but certainly qualify them/tone them down.

But all the more, I really see value in relating (as objectively as possible) the security issues of RAO
(which common wisdom would have you rate as utterly unacceptable) to security issues of other protocols
that also open up a hole in routers control plane like BGP (which is obviously widely
accepted/tolerated/put-up-with/...). This question comes up all the time and would benefit from a
thoughtful answer.

Would it work for you if we kept the BGP discussion and enhanced it to reflect your points?
eg (in simplified form): 
	* core routers are isolated from DOS attacks on Edge routers; however, distinction core/edge is becoming blurred
	* BGP policy control would normally filter undesirable stuff; however, there are known occurrences
where incorrect information did get propagated 
	* configured peers facilitate filtering from other sources; however, bad practices can result in this
being compromised.
(and perhaps we can refrain from making a judgment call that the BGP issues are less "serious" and simply
present the above as "considerations on the differences") 

Again, I really feel this sheds (needed) light on the topic of control plane holes (and therefore on RAO
security considerations).

Thanks much

Francois 

On 14 Sep 2010, at 04:33, Joel M. Halpern wrote:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane