Subject: RE: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill)

From: "Susan Hares" <[email-masked]>
Date: Tue, 21 Jun 2005 15:36:23 -0400

Margaret:

The key point is we want to ship product with standardization.
(A good thing for all of us (IMHO).)

The rules used to be clear:

MAC address = IEEE
IP address/Label = IETF.

If we are changing the rules, we need to be clear that we are changing
the rules clearly.  Tony notes where the change in the rules didn't
match.

You worked hard to make sure we had IETF consistency.  It would be
helpful to make sure we have the same for IEEE/IETF consistency.

Many thanks,

Sue Hares

-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
Sent: Tuesday, June 21, 2005 1:16 PM
To: Margaret Wasserman
Cc: Alex Zinin; [email-masked]; [email-masked];
[email-masked]; Susan Hares; [email-masked]
Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of
Links (trill)

Margaret,

Thanks for your response.  IESG cc'ed per your request.

> Please let me know if you have any further questions.  The IESG will
be
> making a decision on this charter at our telechat this Thursday (June
> 23rd), so if you have an opinion about whether or not we should
charter
> this WG in the IETF, please send your comments to the IESG at
> [email-masked].  We are interested in hearing from folks who do want
this
> work charted (especially from folks who are willing to invest time to
> make this happen), as well as from folks who have objections to
> chartering the group.

While I have no objection to chartering this group, I'm left scratching
my head in wonder, trying to find the consistency between accepting this
work and the previous decision to reject the IS-IS work on jumbo frames.
 You may recall that the opinion at the time was that the work would
step on IEEE toes and therefore the work was halted.  The IEEE chooses
not to endorse jumbo frames, so in some sense there is no
'standardization' to be done.  Vendors, however, continue to ship
running code for jumbo frames.  And there is no agreement for IS-IS
operation in such situations.

IMHO, the IETF needs to re-examine its goals and operations in this
regard.  What used to be an organization that was about standardizing
de-facto standards is now engaged in politicking at the expense of
technology.  We claim to eschew kings and voting, but we seem to be
engaged in SDO diplomacy at the expense of code, users, and the
Internet.  Does that seem right to you?

Regards,
Tony Li

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Jun 2005 12:59:16 +0200

I can't speak to past events, but in this case there has been
substantial discusssion with IEEE and I don't think there is any
disturbance to the addressing "rule" that you cite. But the
skill set for this particular work is in the IETF. Nobody
denies that it's in the grey area where the question of scope
can be discussed endlessly, but the intention is now to decide
quickly, since the proponents have been more than patient.

    Brian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Jun 2005 13:22:46 +0100

I think the skill-set to which Brian refers is link state routing. (Care
to confirm, Brian?)

If so, why is this WG targeted at the Internet Area not the Routing area?

Cheers,
Adrian (Still not opposing, just seeking clarification)
----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "Susan Hares" <[email-masked]>
Cc: "Tony Li" <[email-masked]>; "Margaret Wasserman"
<[email-masked]>; "Alex Zinin" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, June 22, 2005 11:59 AM
Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of
Links (trill)

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 22 Jun 2005 08:57:27 -0400

Hi Adrian,

>I think the skill-set to which Brian refers is link state routing. (Care

Yes, expertise in link-state routing is certainly one reason why this 
work could be seen as more in-scope for the IETF than for the IEEE. 
Also, frankly, there is interest in the IETF in doing this work (a 
link-state-based Ethernet routing solution), while the IEEE is 
continuing to pursue (R)STP-based approaches.

>If so, why is this WG targeted at the Internet Area not the Routing area?

This questions has been discussed in the IESG, as well, and we did 
not have 100% agreement regarding the area in which this work belongs.

Personally, I think that TRILL is a better fit for the Internet area, 
and I will explain why...

Traditionally, the division between the Internet area and the Routing 
area has been that the Routing area deals with protocols that 
distribute routing information (routes/labels) and the Internet area 
has been responsible for the forwarding behaviour and encapsulation 
mechanisms that make use of that information.

The TRILL charter maintains that split -- any work on the routing 
protocols themselves would be done in the routing area, while the 
encapsulation/forwarding mechanism would be developed in the Internet 
area.

Perhaps you have a different model of the division between the 
Routing and Internet areas that makes you think otherwise?

The IESG discussed this issue several months ago.  We agreed that 
this work is close to the line between Internet and Routing, but we 
reached an agreement that it would best be placed in the Internet 
area, with the understanding that we would appoint a technical 
advisor and a WG co-chair with routing expertise.  BIll Fenner 
volunteered to be the Technical Advisor, and Bill and Alex took an 
action item to return with a list of potential co-chairs.

Ultimately, I am not sure that it matters all that much which area 
this work is done in, since it will require expertise and involvement 
from both areas in order to succeed.

Margaret

---

From: Alex Zinin <[email-masked]>
Date: Wed, 22 Jun 2005 06:24:51 -0700

Sorry for a dry reply--traveling, in meetings.

As Margaret said, the IESG didn't have an agreement on this.

I personally believe the expertise required for TRILL is in RTG. The
question of whether the WG should be formed has been dominating the
discussion though.

-- 
Alex

---

From: David Ward <[email-masked]>
Date: Wed, 22 Jun 2005 08:56:59 -0500

AFAIK, the only place that "routing L2" in a protocol has been 
drafted is in ISIS. We wrote to draft to show that it was possible and
to think through the protocol implications (how to reduce flooding, spf
churn, layout the packet format) of what was even feasible.  

The WG will not accept it as a WG item until all of this has been resolved.

-DWard

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Jun 2005 16:38:39 +0200

I concur with Margaret completely

    Brian

Margaret Wasserman wrote:
> This questions has been discussed in the IESG, as well, and we did not 
> have 100% agreement regarding the area in which this work belongs.
> 
> area has been that the Routing area deals with protocols that distribute 
> routing information (routes/labels) and the Internet area has been 
> responsible for the forwarding behaviour and encapsulation mechanisms 
> that make use of that information.
> 
> encapsulation/forwarding mechanism would be developed in the Internet area.
> 
> Perhaps you have a different model of the division between the Routing 
> and Internet areas that makes you think otherwise?
> 
> The IESG discussed this issue several months ago.  We agreed that this 
> work is close to the line between Internet and Routing, but we reached 
> an agreement that it would best be placed in the Internet area, with the 
> understanding that we would appoint a technical advisor and a WG 
> co-chair with routing expertise.  BIll Fenner volunteered to be the 
> Technical Advisor, and Bill and Alex took an action item to return with 
> a list of potential co-chairs.
> 
> Ultimately, I am not sure that it matters all that much which area this 
> work is done in, since it will require expertise and involvement from 
> both areas in order to succeed.
> 
> Margaret
> 
> 
> 
>

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 22 Jun 2005 12:18:11 -0400

In message <[email-masked]>
> quickly, since the proponents have been more than patient.

Brian,

[Appology in advance for the length of this.]

One of the conclusions that could potentially come out of a group that
has more expertice in this area is that the whole idea of bridging in
anything but a very small scale and trivial topology in general is a
bad idea and therefore this work and any further spanning tree work is
best not pursued anywhere.  Others have mentioned that IETF tends to
standardize those things that have proven useful rather than push
ideas upon user communities (Tony, others).  [insert mantra on running
code and all that.]

Its clear that there is no interest in providers in bridging
solutions.  There have been enough failures to keep most people from
further attempts, ranging from the bridging done in regional acedemic
networks in the late 1980s to attempts to use IP at the edges and ATM
in the middle, to the complete failure in the market of ATM approaches
such as RFC1577, NHRP, MPOA.

Bridging seems to be a preferred solution in enterprise.  A decade ago
there was a good reason to do so.  If you moved a box from one
ethernet segment to another you had to change its IP address.  This
was a pain for personal workstations (whether Sun, Linux, PC, MAC,
whatever) which are very numerous.  DHCP has changed that.  Only
machines providing a service need a fixed address and a DNS mapping to
that address.  Even though DHCP is universally available and widely
deployed in enterprise, enterprise hasn't caught on that the reliance
on bridging is no longer in their best interest (in fact the opposite
is true since diagnosing routing problems is much easier).

The remaining problem for enterprise is moving the servers.  Most
enterprise IT departments can deal with renumbering a server if they
have to do so to accomodate a physical move and the better ones
configure a whole new server and have it running and then just switch
the DNS entry (giving it a short TTL 24 hours prior to the switch,
etc, etc) in addition to making the switch off hours.

Mobility offers a new problem.  It would be nice to be able to keep
your laptop running and move about within wireless space with any
changes to addressing made transparently.  The best way to do this
involves decoupling the destination address of the box from the
interface address.  Loopback devices and interface aliases are nothing
new to routers and Linux and *ix systems.

A better solution to the problem of mobility of small devices like IP
phones and laptops might be entirely at layer 3 using the above
toolbox (microsoft can add loopbacks and aliases if they don't support
such a capability).  A limited initial solution might be as simple as
having the abiliby for the OS to bind to the loopback on outbound
connections by default rather than the interface (this is solved at
the application layer in some router code and kerberos implementations
and other things that providers have "fixed" for dual homing and
recompiled) and tracking the host route to the loopback within a
limited set of wireless access points (for example all those at a
given IETF meeting).  This can be made general by having DHCP offer a
preferred loopback address for the device to use.

Solving the problem of mobility between adjacent domains isn't much
harder.  The problem with switching the loopback device is that with
current OS all TCP connections stop working.  For short lived
protocols such as SMTP or POP and HTTP this is less of a problem than
for long lived connections such as SSH's slogin service (no one really
uses telnet, I hope).  For the short lived connections allowing the
loopback of a geographicly adjacent domain might provide a sufficient
grace period on the transition to solve the problem.  It would be best
if the OS could support a preferred address on the loopback and an
alias on the loopback to support the TCP connections still using the
old address.

Beyond that there would need to be a way to change the TCP address of
one end of a TCP connection.  This would have to be solved in TCP
itself.  There is currently no header option for "accept alternate
address" and "drop address" in TCP but having that would be
sufficient.  It would also open a new opportunity for abuse in TCP
connections with no cryptographic integrety check so the security
section of such a draft would have to be very non-empty.  It might be
that we'd have to restrict use of this option to TCP connections with
some form of cryptographic check (but I digress).

Ultimately one should be able to drive (or fly, or bicycle, or
whatever) across a continent with a laptop open and keep the same TCP
connection open the whole time.  The solution might be as simple as
some OS enhancements and enhancements to DHCP and a TCP option.
Please note that a spanning tree or link state solution isn't going to
get us there and therefore is a limited temporary solution.

There are sure to be other less used non-TCP protocols that are
affected.  Just like with NAT eventually this would be resolved.  For
example, a SIP enhancement might be needed to accomodate connection to
a phone that is moving about in the address space.

In the past the BSD folks would go to it, we'd play with it at IETF,
some providers would start to support it if that was needed, we'd
write an internet-draft which would become an RFC and 5-10 years later
deployment would be widespread.  It worked for DHCP.  It worked (for
some limited value of worked) for multicast.  The IETF often works
differently these days, but that doesn't mean that running code
wouldn't help matters.

Then again, the conclusions of this discussion might be quite
different but thats my thoughts on the topic.

Curtis

ps - Anyone seriously interested in these ideas please send private
email (anyone at ISC interested?) or at least change the subject.
This is sort of off topic or mostly a digression but I felt that if I
were saying "bad solution" in order to be constructive I needed to
outline a better solution.

pps - In the past work on "bad solutions" were referred to ITU or
other organization though I'm not sure that practice is codified in
any IESG policy.  I suspect a lot of the "send it to IEEE" might be
motivated by the "bad solutions are out of scope for IETF" sentiment.
:-)

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Jun 2005 14:24:30 -0700

> such as RFC1577, NHRP, MPOA.

I'm confused. There seems to be a lot of provider interest in L2VPN 
technology, which is providing what looks like a bridged service across 
a WAN.

    Erik

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 22 Jun 2005 18:19:41 -0400

In message <[email-masked]>
> technology, which is providing what looks like a bridged service across 

For one things that's selling a service to someone else not building
one's own network on top of a bridged service.  btw- VPLS would be a
bridged service.  L2VPN is just the L2 part.

The motivation for L2VPN with carriers that I've spoken to is not that
there is a gold mine in this service.  It is quite the contrary.  The
bridged services and leased lines of any distance are a shrinking
market or very slow growth at best and no longer justify their own
network when the IP network is growing to circuit capacities in
multiples of OC192.  If these services can be efficiently carried over
the same nework that carries IP it would be a cost savings and in some
cases get these services back in the black again.

Provider backbones over anything resembling a bridged network seems to
be close to dead.  Also note that I said that past experience is
enough to keep "most" people from repeating mistakes of the past.
Another mistake of the past is radically overestimating market growth
so if anyone does indicate a gold mine in L2VPN I'd be skeptical.

Curtis