Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

Ron, Your draft recommends that the ingress node discards the frame and sends ICMP msg to the source node when the size of GRE encapsulated frame exceeds link MTU. We experienced that Window XP doesn't adjust frame size after receiving ICMP message. Many Linux based applications don't do anyt

Re: [Int-area] New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

essage- > From: Ronald Bonica [mailto:rbon...@juniper.net] > Sent: Wednesday, June 26, 2013 8:00 AM > To: Linda Dunbar; Joe Touch; Carlos Pignataro (cpignata) > Cc: Internet Area > Subject: RE: [Int-area] New Version Notification for draft-bonica- > intarea-gre-mtu-00.txt >

Re: [Int-area] Working group last call for draft-ietf-intarea-flow-label-balancing-01

Support. Linda From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of Qiong Sent: Thursday, July 11, 2013 1:20 PM To: Suresh Krishnan Cc: Internet Area Subject: Re: [Int-area] Working group last call for draft-ietf-intarea-flow-label-balancing-01 Dear all, I think it

[Int-area] FW: New Version Notification for draft-nachum-sarp-05.txt

multicast traffic to some physical link segments. Hope those points are more clear. Linda -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Thursday, July 11, 2013 3:13 PM To: Linda Dunbar; Youval Nachum; Ilan Yerushalmi; Tal Mizrahi Su

Re: [Int-area] FW: New Version Notification for draft-nachum-sarp-05.txt

sday, July 11, 2013 5:38 PM > To: Linda Dunbar > Cc: Internet Area; Suresh Krishnan > Subject: Re: [Int-area] FW: New Version Notification for draft-nachum- > sarp-05.txt > > How does this relate to the work being done in the trill and nvo3 > working groups? ___

Re: [Int-area] FW: New Version Notification for draft-nachum-sarp-05.txt

Ted, You have really good questions. Answers to your questions are inserted below: > -Original Message- > > True. However, they do have various strategies for addressing this > problem, and I was wondering how you think your proposal fits in. For > example, the trill working grou

Re: [Int-area] New Version Notification for draft-nachum-sarp-05.txt

Ted, Thank you very much for the suggested text. I tweaked a little bit. How about the following text added to the Introduction section? "This document describes a proxy gateway technique, which is called SARP throughout this document, to reduce switches' FDB (MAC table) sizes and ARP/ND imp

Re: [Int-area] New Version Notification for draft-nachum-sarp-05.txt

Ted, Thank you very much for the suggested text. We will change the draft before uploading today. We will also spell out all the acronyms and reduce using them as much as possible. FDB: Filtering Data Base, which is a term used for Layer 2 switches (IEEE802.1Q). Layer 2 switches flood data

Re: [Int-area] New Version Notification for draft-nachum-sarp-05.txt

> -Original Message- > > The name "filtering database" clarified it, actually. You don't need > to store the IP addresses at all, right? [Linda] Correct. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/in

[Int-area] FW: New Version Notification for draft-nachum-sarp-06.txt

Many Thanks to Ted Lemon in asking many good questions and providing good suggestion on the text. We have updated the draft based on Ted's input. Linda -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Monday, July 15, 2013 2:06 PM To:

Re: [Int-area] New Version Notification for draft-nachum-sarp-06.txt

Ted, Thank you very much for the advice. We will clean up the acronyms in the next revision. Linda > -Original Message- > From: Ted Lemon [mailto:ted.le...@nominum.com] > Sent: Wednesday, July 17, 2013 10:09 PM > To: Linda Dunbar > Cc: Internet Area; Suresh Krishn

[Int-area] Any feedback or concern of using Proxy Gateway in NVO3 environment?

NVO3 provides an overlay mechanism so that the hosts (or VMs) addresses are hidden from the switches in the core. However, for the "L2 in IP" case of NVO3, all the overlay edge nodes are still exposed to all the hosts MAC addresses on the VLANs that are enabled on the edges, which can cause s

[Int-area] any concerns of SEND mixed with Proxy Gateway described in draft-nachum-sarp-06?

, i.e. the access switch has 4000 VLANs enabled. If each VLAN has 200 hosts, this access switch's MAC table potentially has 200*4000 = 800,000 entries. Thank you very much for your feedback. Linda Dunbar ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] any concerns of SEND mixed with Proxy Gateway described in draft-nachum-sarp-06?

> -Original Message- > > My take is that *if* we want to have the approach where a host's IP > address should map to somebody else's MAC address, then I think the > simplest (and secure) approach would be to have the host (somehow) find > out the MAC address to use, and then have the hos

[Int-area] comments to draft-matsushima-stateless-uplane-vepc-01

I am just repeating my comments made to draft-matsushima-stateless-uplane-vepc-01 during the InterArea WG session. It seems to me that the case presented is the motivation for needing routers/switches in the network to dynamically change forwarding behavior that are triggered by external contro

Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt

Support! This draft is about the proxy gateway to make switch's FDB not explode in DC environment where hosts in one VLAN (or subnet) can be placed anywhere. NVo3 and TRILL can hide hosts' addresses from switches/routers in the core. But If NVO3 edges (NVE) are Top of Rack switches or End of

Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt

David, Answers to your comments are inserted below: From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of David Allan I Sent: Thursday, August 29, 2013 12:53 PM To: int-area@ietf.org Subject: [Int-area] Call for adoption of draft-nachum-sarp-06.txt Hi: I have read th

Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt

David, One correction, I meant to say MACinMAC (same as TRILL or NVO3) only hides hosts addresses from the core nodes, but, all the overlay edge nodes are still exposed to all the hosts addresses on the VLANs that are enabled on the edge. We have seriously considered MACinMAC back then for Et

Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt

> -Original Message- > VM placement affinity rules would NEVER see absolutely every local VM > belonging to a different tenant network and requiring connectivity only > to remote VMs. [Linda] Being in one VLAN (or subnet) doesn't mean that those hosts (or applications) have higher traff

Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt

Ted, Thanks for the comments and reply. Again, the draft is not about building one large Layer 2. The proposed proxy gateway is to enable subnets not to be restricted physically together, i.e. allowing the gateway nodes in one access domain to be the "proxy gateway" for all the hosts attache

Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt

David, > -Original Message- > > What this means is any non-IP E2E protocol (CFM, QCN etc.) is broken > and how one would instrument and fault sectionalize this network is > unclear. [Linda] The proposed "proxy gateway" only represents the IP applications' end hosts address by the "gat

Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt

esses. Those addresses are limited no matter how subnet is spread and how diverse servers are virtualized. Linda > -Original Message- > From: David Allan I [mailto:david.i.al...@ericsson.com] > Sent: Friday, September 27, 2013 4:41 PM > To: Linda Dunbar; Ted Lemon > Cc: int-are

Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt

Wes, > -Original Message- > > > [WEG] One might also argue that MS Outlook is a key component in many > corporate environments, but it's false equivalence to then assume that > this is because it's the best solution, rather than the truth, which is > that it's the "least bad" alternative.

Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt

Ted, > -Original Message- > > What matters is that an observation has been made that a L2 VPN could > have severe negative behavior characteristics in plausible > circumstances. This is a really strong reason not to use an L2 VPN. [Linda] I understand that many people are still not con

Re: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft

I am confused of the math here. If most physical links MTU is 1500 bytes (or 2000 bytes for some), how do we have""4GB"" minus the encapsulation overhead for IPv6, as the "tunnel link Maximum Transmission Unit (MTU)". Is 4GB correct ??? Linda -Original Message- From: Int-area [mailto

Re: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft

To: Linda Dunbar; Black, David; ts...@ietf.org; tsv-a...@ietf.org Cc: Mark Townsley; int-area@ietf.org Subject: RE: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft Hi Linda, The maximum MTU for an IPv4 link is 64KB (per RFC0791) and the maximum MTU for an IPv6 link is

Re: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft

g.com > Linda > > -Original Message- > From: Templin, Fred L [mailto:fred.l.temp...@boeing.com] > Sent: Friday, May 16, 2014 2:10 PM > To: Linda Dunbar; Black, David; ts...@ietf.org; tsv-a...@ietf.org > Cc: Mark Townsley; int-area@ietf.org > Subject: RE: [Int-area]

Re: [Int-area] (REVISED) Call for adoption of draft-bonica-intarea-gre-mtu-06

I support adoption of this draft. I think that this draft is very useful, especially to SFC, NVO3 WGs. Those groups are defining new encapsulation headers. MTU issues & practices should be visible to the participants of those groups. Linda Dunbar -Original Message- From: Int-

[Int-area] Questions to draft-intarea-tunnels-03

Joe and Mark, You said "Because tunnels are links, they are subject to the same issues as any link, e.g. MTU.." The MTU issue exist between any two points in a network. The MTU issue for tunnel is more like the MTU issue between any two points in the network (i.e. traverse many links, and can

Re: [Int-area] Questions to draft-intarea-tunnels-03

"inner")..", is the ")" extra? Section 4.2 first sentence: " It messages might be ...", do you mean "... its messages might be..." Linda From: Joe Touch [mailto:to...@isi.edu] Sent: Thursday, October 06, 2016 4:10 PM To: Linda Dunbar ; towns...@cis

Re: [Int-area] Questions to draft-intarea-tunnels-03

the Tunnel MTU is 1500, not the 2000 at the Tunnel egress node, correct? Linda From: Joe Touch [mailto:to...@isi.edu] Sent: Thursday, October 06, 2016 11:48 PM To: Linda Dunbar ; towns...@cisco.com Cc: int-area@ietf.org Subject: Re: Questions to draft-intarea-tunnels-03 Hi, Linda, On 10/6/20

Re: [Int-area] Questions to draft-intarea-tunnels-03

tunnel.” An overlay “ tunnel” described in your draft appears as one “link” from “transiting IP” (or IP routing) perspective, but it is not from MTU perspective. Linda From: Joe Touch [mailto:to...@isi.edu] Sent: Friday, October 07, 2016 11:08 AM To: Linda Dunbar Cc: towns...@cisco.com; int

Re: [Int-area] Questions to draft-intarea-tunnels-03

:33 AM To: Linda Dunbar Cc: towns...@cisco.com; int-area@ietf.org Subject: Re: Questions to draft-intarea-tunnels-03 On Oct 7, 2016, at 8:15 AM, Linda Dunbar mailto:linda.dun...@huawei.com>> wrote: Joe, You said “The egress MTU determines the largest IP packet (or fragment) that can tr

Re: [Int-area] New Version Notification for draft-yong-intarea-inter-sites-over-tunnels-00.txt

work sites over IP backbone networks. We will present this in > Seoul meeting and look forward to hearing comments and suggestions on this > work. > > Thanks, > Authors > > -Original Message- > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] > S

Re: [Int-area] WG Adoption Call: Extended Ping (Xping)

Support. Linda De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Wassim Haddad Envoyé : jeudi 13 avril 2017 20:15 À : int-area@ietf.org Cc : intarea-cha...@ietf.org Objet : [Int-area] WG Adoption Call: Extended Ping (Xping)

[Int-area] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types

e IP address after the NAT. o Public Port：The Port after the NAT. Thank you very much for feedback. Linda Dunbar -Original Message- From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of tom petch Sent: Friday, November 02, 2018 11:26 PM To: Joel Jaeggli Cc: i...@ietf.org Subject

Re: [Int-area] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types

ker.i...@gmail.com] Sent: Monday, November 05, 2018 1:07 PM To: Linda Dunbar Cc: tom petch ; Joel Jaeggli ; i...@ietf.org; int-area@ietf.org; i...@ietf.org Subject: Re: Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types Linda, I see a couple

Re: [Int-area] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types

Fred, How does my phone (being IPv6 address) communicate with a web server that is IPv4 public address? Linda -Original Message- From: Fred Baker [mailto:fredbaker.i...@gmail.com] Sent: Monday, November 05, 2018 5:42 PM To: Linda Dunbar Cc: tom petch ; Joel Jaeggli ; i...@ietf.org

Re: [Int-area] [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types

, November 05, 2018 6:52 PM To: Fred Baker ; Linda Dunbar Cc: i...@ietf.org; int-area@ietf.org; i...@ietf.org Subject: Re: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types In SD-WAN ctxt, to let a site which has IPv4 on the WAN ta

Re: [Int-area] [Apn] A new draft on APN for your review, thank you!

Shuping, Some comments to the draft-peng-apn-scope-gap-analysis-00: I find Page 4 last sentence really hit the key purpose of APN: at the headend to steer into corresponding path, at the midpoint to collect corresponding performance measurement data, and at the service function to execute part

Re: [Int-area] The official instructions on the next step of APN

abel added between domains, such as using the IPsec IKE method between controllers of the two domains to negotiate the labels used in the data plane My two cents, Linda Dunbar From: Apn On Behalf Of Pengshuping (Peng Shuping) Sent: Wednesday, February 3, 2021 7:40 PM To: a...@ietf.org Cc: int

[Int-area] FW: Comments on "per-app networking considerations" draft

their specific controllers for the types of services they need. Then the Controller exchange with the network. Linda Dunbar From: Int-area mailto:int-area-boun...@ietf.org>> On Behalf Of Sørensen, Frode Sent: Sunday, July 4, 2021 12:54 AM To: int-area@ietf.org<mailto:int-area@ietf.org

Re: [Int-area] New Version Notification for draft-herbert-net2hostsig-00.txt

Tom, I find your draft very interesting. I have a couple of questions: - what kind of applications are capable of sending signals/requests to the network? - Section 2.3 Network Services: do you see UE sending signals to the network? Or should it be the Application Controller notify a

[Int-area] can you elaborate the "loops" which you are concerned with "draft-nachum-sarp-03"?

TRILL, or IS-IS) to prevent loops for Ethernet data frames which don't have TTL. The same mechanism should prevent the loops of ARP/ND frames. Can you draw a scenario on how/why the loop prevention mechanism for Ethernet data frames won't work for ARP/ND frames? Than

[Int-area] IPv6 ND applicability in draft-nachum-sarp-03

Suresh and Julien, When the "draft-nachum-sarp-02" was presented at InterArea WG in 84th IETF, the feedback was that the draft needs to be updated to include the processing for IPv6. So we updated the draft to include the processing of ND for IPv6. When the revised draft (draft-nachum-sarp-03)

Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03

Suresh, Comments are inserted below: > -Original Message- > > > > Even though that IPv6 ND uses multicast instead broadcast, IPv6 ND > does > > have scalability issues in Data Center when hosts within same subnet > are > > spread across different access switches, and when there are lot o

Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03

Suresh, > -Original Message- > > Because it is :-). As an example, if you take an fat tree architecture, > the number of access switch ports on a subnet is not directly related > to > the number of ports on the L3 gateway that are on the same subnet. > For the following network, if o

Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03

s. Linda > -Original Message- > From: Suresh Krishnan [mailto:suresh.krish...@ericsson.com] > Sent: Tuesday, November 20, 2012 10:48 AM > To: Linda Dunbar > Cc: int-area@ietf.org; julien.i...@gmail.com; Tal Mizrahi > Subject: Re: IPv6 ND applicability in draft-nachum-sarp-03

Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03

> From: Suresh Krishnan [mailto:suresh.krish...@ericsson.com] > Sent: Tuesday, November 20, 2012 5:58 PM > To: Linda Dunbar > Cc: int-area@ietf.org; julien.i...@gmail.com; Tal Mizrahi > Subject: Re: IPv6 ND applicability in draft-nachum-sarp-03 > > Hi Linda, > > On 11/20/2012 01:

Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03

"draft-nachum-sarp" gives another approach to scope the ND multicast and alleviates the burden on router when subnets are spread across multiple links/ToRs. Linda > -Original Message- > From: Greg Daley [mailto:gda...@au.logicalis.com] > Sent: Wednesday, November 21,

Re: [Int-area] Call for adoption of draft-carpenter-flow-label-balancing-02

+1 Linda > > On 4 Jan 2013, at 20:59 , Hosnieh Rafiee wrote: > > > +1 > > I also found it useful. > > > > On Dec 18, 2012, at 4:45 AM, Suresh Krishnan wrote: > > > >> Hi all, > >> This draft has been presented at intarea face to face meetings and > >> has received a bit of discussion. It has be

Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03

greatly increasing the FDB. This draft also addresses the FDB entries explosion issue. Is it clear enough? We can update the draft with this explanation. Linda > -Original Message- > From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On > Behalf Of Linda Dun

[Int-area] Updated draft-nachum-sarp to address comments regarding to IPv6 ND applicability

Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Sunday, February 24, 2013 9:01 AM To: ta...@marvell.com Cc: Linda Dunbar; yi...@marvell.com; youval.nac...@gmail.com Subject: New Version Notification for draft-nachum-sarp-04.txt A new version of I-

[Int-area] Relevance of RFC4389 (ND Proxy) to draft-nachum-sarp

carefully considered for the SARP protocols. The section 3.3 has demonstrated how SARP works when VMs are moved from one segment to another." Linda > -Original Message- > From: Suresh Krishnan [mailto:suresh.krish...@ericsson.com] > Sent: Thursday, March 14, 2013 9:58

[Int-area] Comments and suggestiosn to draft-ietf-intarea-flow-label-balancing-00

ed Load Balancing Algorithms using Flow Label (you can describe how Flow Label improve the LB algorithms currently being deployed"). Linda > -Original Message- > From: Sheng Jiang > Sent: Monday, April 01, 2013 9:04 PM > To: Linda Dunbar > Subject: RE: Review

Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

Ron, I do have a few questions and suggestion about the practices documented in the draft: - Section 4.1, second paragraph: why DF bit "MUST" set to 1 when the payload header has "0"? I would think default should be same as the "payload" DF setting. - Section 5.1, last sentence: "The GRE e

Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-00.txt

Ron, Comments are inserted below: > -Original Message- > > Just to be sure that we aren't talking past each other, let's ensure > that we are talking about the same scenario. The GRE egress router > receives > complete, non-fragmented packets, containing fragmented payloads. [Linda] T