Subject: [lisp] Comments about the LISP header

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 27 May 2009 14:57:27 +0200

Hello,

The LISP header is defined in draft-ietf-lisp-00.txt as follows

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L / |S|                     Locator Reach Bits                      |
   I   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S \ |                             Nonce                             |
   P  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This LISP header is used for both encapsulated data packets and also or
Map-Request and Map-Reply messages. An ETR can used the UDP destination
port to determine whether the received packet is a data encapsulated
packet (UDP destination port set to 4341) or a control packet (UDP
destination port set to 4342).

However, not all fields of the LISP header are useful for both data and
control packets. For example, the S bit and the loc-reach bits are not
used for Map-Request packets, while there is no utilisation of the Nonce
for data encapsulated packets in draft-ietf-lisp-00, except for data
probes.

We thus have an 8 bytes overhead in all data encapsulated packets while
currently 32 bits of this header is not used by most data encapsulated
packets.

It might be useful to consider a different structure for the LISP header
used in data encapsulated packets and the LISP header used in control
packets or define some utilisation of the Nonce field in all data
encapsulated LISP packets.

Olivier

-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 May 2009 06:23:04 -0700

Oliver,

> -----Original Message-----
> From: Olivier Bonaventure [mailto:[email-masked]]
> Sent: Wednesday, May 27, 2009 5:57 AM
> To: [email-masked]
> Subject: [lisp] Comments about the LISP header
> 
> Hello,
> 
>    I
>    S \ |                             Nonce
|
>    P
> encapsulated LISP packets.

Good idea. For example, LISP could instead use the SEAL
header for data packets. That would eliminate the UDP
header as well. As you observe, the control packets
could remain as UDP/LISP if desired, and need not be
formatted the same as for data packets.

Fred
[email-masked]
 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 27 May 2009 17:59:41 +0200

Fred,
> header for data packets. 

I'm not convinced that all the mechanisms placed in SEAL are necessary
for LISP.

> That would eliminate the UDP header as well. 

The main benefit of the UDP header is that LISP encapsulated packets
appear as "normal" packets on today's Internet, including middleboxes.
There are too many devices today that drop packets because they do not
carry tcp, udp or other well known protocols. This is annoying, but we
have to live with this :-(

> As you observe, the control packets

Control packets could have a different format than data encapsulated
packets indeed.

Olivier

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 May 2009 09:27:27 -0700

Oliver,

> Sent: Wednesday, May 27, 2009 9:00 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [lisp] Comments about the LISP header
> 
> Fred,
> >>

SEAL has 8 "control" bits, of which at least the
"Acknowledgment Requested" and "Report Fragmentation"
bits are required. Four other control bits (the M bit
and the 3-bit SEG field) are used for segmentation and
reassembly, but it may well be that LISP will not want
to use these under many circumstances which is absolutely
fine and consistent with the SEAL architecture. Finally,
the 'Y' bit is used by the ETR to tell the ITR whether/not
it is willing to reassemble. That leaves only one bit
as unused among the 8 control bits.    

> have to live with this :-(

I have some doubts that this is actually a problem. For
example, ip-proto-41 seems to work fine for 6to4 and others.
ip-proto-4 also for RFC2003 and its kin. GRE also seems to
get through. There will also be no NAT traversal in the
interdomain core. So, I don't see it as unrealistic that
a new IP protocol would get through most paths and could
be easily enabled to get through the other paths.

> Control packets could have a different format than data encapsulated

Correct.

Fred

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Wed, 27 May 2009 10:16:40 -0700

> --> > The main benefit of the UDP header is that LISP 
> encapsulated packets 
> interdomain core. So, I don't see it as unrealistic that a 
> new IP protocol would get through most paths and could be 
> easily enabled to get through the other paths.
> 

Fred,

Just three short short points about why LISP utilizes a UDP header.

First I'll note that my netgear router at home refuses to NAT on
anything besides TCP and UDP.  Early implementations of LISP that
required the ALT to extend to the xTR would not work through this
device.

Second, many enterprise firewalls are configured to deny IP protocols
that aren't explicitly allowed, so piggy backing on a known protocol has
some benefits.

Finally, Link Aggregation schemes for core routers use 5 tuple hashes
which include s-port and d-port fields of udp/tcp protocols.  ISP
operators early in the specification processes provided explicit and
animated feedback saying that UDP encapsulation was a critical feature.

-Darrel

--------------------------------------------
All IETF attendees have conflicts of interest.  The only difference
between them is that some admit it.  I myself deny it.  --Darrel Lewis
(with apologies to H.L. Mencken)
--------------------------------------------

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 May 2009 10:25:49 -0700

Hi Darrel,

I appreciate your comments; see below for follow-up:

> From: Darrel Lewis (darlewis) [mailto:[email-masked]]
> Sent: Wednesday, May 27, 2009 10:17 AM
> To: Templin, Fred L; [email-masked]
> Cc: [email-masked]
> Subject: RE: [lisp] Comments about the LISP header
> 
> 
> 

There are no NATs in the DFZ.

> that aren't explicitly allowed, so piggy backing on a known protocol
has

There are no enterprise firewalls in the DFZ.

> animated feedback saying that UDP encapsulation was a critical
feature.

These schemes would therefore have to do deep packet
inspection to pick up the 5-tuples from ip-proto-4,
ip-proto-41, GRE and the like. How unrealistic would
it be for them to also accommodate a new IP protocol?

I see the point that perhaps this is pushing things too
far down the road beyond the experimentation phase at
the current time. But once the experimenting gives way
to full-scale operation, I don't see it as so much of
a problem for network administrators to sync up with
a new IP protocol.

Fred

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Wed, 27 May 2009 10:50:53 -0700

> There are no NATs in the DFZ.

Yes, but LISP xTRs can (and have in the existing prototype network) been
deployed within broadband sites.

> There are no enterprise firewalls in the DFZ.  

As an aside: you might be surprised, considering the number of firewalls
that wireless operators are deploying.

But my serious response is that LISP xTRs can (and have in the existing
network) been deployed deep within enterprise networks.  While I d
believe that the 'sweet' spot for most deployments will be the CPE
router,  even this co-location raises questions about the ordering of
features implemented in conjunction with the XTR.

> 
> > Finally, Link Aggregation schemes for core routers use 5 
> topple hashes 
> ip-proto-41, GRE and the like. How unrealistic would it be 
> for them to also accommodate a new IP protocol?

The vast majority of these LAg implementations are hard coded into
asics.  Since something like 99%+ of the traffic in the core is ip
protocol 6 and 17, SPs have asked their vendors to provide detailed
features around those I protocols.  If you did manage to convince
someone that adding support for a different protocol would be a useful
feature, it would still take a minimum of 2-5 years to see wide scale
deployment.  And all this assumes the protocol in question is amenable
to 'flow' identification (GRE for instance, is not).

-Darrel

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 May 2009 13:54:31 -0400

>>>>> "Fred" == Templin, Fred L <[email-masked]> writes:
    >> I'm not convinced that all the mechanisms placed in SEAL are
    >> necessary for LISP.

    Fred> SEAL has 8 "control" bits, of which at least the
    Fred> "Acknowledgment Requested" and "Report Fragmentation" bits
    Fred> are required. Four other control bits (the M bit and the
    Fred> 3-bit SEG field) are used for segmentation and reassembly,
    Fred> but it may well be that LISP will not want to use these
    Fred> under many circumstances which is absolutely fine and
    Fred> consistent with the SEAL architecture. Finally, the 'Y' bit
    Fred> is used by the ETR to tell the ITR whether/not it is willing
    Fred> to reassemble. That leaves only one bit as unused among the
    Fred> 8 control bits.

Fred, it's my understanding that the PMTU handling issue you have
raised is still open.  It sounds like most of these facilities are
only needed if the working group concludes you are correct and that a
more advanced PMTU handling strategy is required.

Or put another way, would you agree with me that the WG as a whole has
not yet come to agree that these facilities are needed in LISP?

It's my understanding that the PMTU issue has not been discussed in
this context--the working group--although it has been discussed in
other contexts in the past.  As such, it's very much open until we
have that discussion and come to consensus.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 May 2009 11:19:32 -0700

Darrel,

A number of your comments regarding deployment scenarios
are somewhat surprising to me, since my understanding was
that LISP would deploy on DFZ routers. RANGER already has
the deployment scenarios for enterprise networks covered.

Respecting enterprise boundaries has clean architectural
benefits. Tunneling through NATs and firewalls has drawbacks.

Fred

> Sent: Wednesday, May 27, 2009 10:51 AM
> > > that aren't explicitly allowed, so piggy backing on a known
protocol

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 May 2009 11:31:34 -0700

Sam,

> From: Sam Hartman [mailto:[email-masked]]
> Sent: Wednesday, May 27, 2009 10:55 AM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]

It seemed to me that we were gravitating toward a position
that the MTU reporting mechanism of SEAL is desirable but
not all xTRs will want to implement the SEAL segmentation
capability. That is perfectly OK, and consistent with the
SEAL architecture.

So, if one of the ITR/ETR does not want to implement SEAL
segmentation then that capability will not be used. If
both ends implement it, then the capability can be used
if needed.

> have that discussion and come to consensus.

It should be pointed out that SEAL is about much more
than just MTU handling. The SEAL ID extension also
provides a packet identifying tag that is beneficial
for many reasons, and can be used instead of the LISP
nonce.

SEAL also already has built-in liveness testing
piggybacked on the data messages, which is exactly
what Noel was asking for.

Fred

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 May 2009 14:46:35 -0400

>>>>> "Templin," == Templin, Fred L <[email-masked]> writes:

    Templin,> It seemed to me that we were gravitating toward a
    Templin,> position that the MTU reporting mechanism of SEAL is
    Templin,> desirable but not all xTRs will want to implement the
    Templin,> SEAL segmentation capability. That is perfectly OK, and
    Templin,> consistent with the SEAL architecture.

Interesting.  I had not seen that, which probably simply means I
missed the discussion.  Comments from others welcome.

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Wed, 27 May 2009 12:19:57 -0700

Hi Fred,

> 
> A number of your comments regarding deployment scenarios are 
> somewhat surprising to me, since my understanding was that 
> LISP would deploy on DFZ routers. RANGER already has the 
> deployment scenarios for enterprise networks covered.

I don't recall the LISP drafts (specifically draft-ietf-lisp-00.txt)
restricting the placement of xTRs to any particular place in a network's
topology.  Some placement choices seem to have inherent drawbacks, while
others have interesting benefits. 

I'm not sure how LISP relates to RANGER, in that none of the LISP drafts
seem to reference or discuss coexisting or interacting with RANGER.  I'm
also not aware of any implementations of RANGER that LISP
implementations could or have experimented/interoperated with.

> benefits. Tunneling through NATs and firewalls has drawbacks.

Yet but these devices exist, and as Olivier mentioned, we should perhaps
consider how LISP is going to interact with them.  I personally would
not be in favor of constraining the topological placement of xTRs due to
arbitrary architectural concerns.

-Darrel

---

From: David Meyer <[email-masked]>
Date: Wed, 27 May 2009 12:57:52 -0700

Fred,

> that LISP would deploy on DFZ routers. 

	This is a misunderstanding on your part. We can thought
	from day one that one of the sweet spots for LISP is the
	CPE. 

> RANGER already has the deployment scenarios for enterprise
> networks covered. 

	I'm not sure about the relevance of that statement. Could
	you clarify?
	
> benefits. Tunneling through NATs and firewalls has drawbacks.

	Perhaps, but again, what is your point?

	Dave

---

From: David Meyer <[email-masked]>
Date: Wed, 27 May 2009 13:02:44 -0700

> capability. That is perfectly OK, and consistent with the

	First, what is "gravitating"? Please provide a
	definition. Second, if you mean some kind of
	quasi-consensus (as implied about), I observe no evidence
	of such "consensus". As such, can you please support this
	assertion?

	Thanks,

	Dave

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 May 2009 13:06:54 -0700

Darrel,

> Sent: Wednesday, May 27, 2009 12:20 PM
> seem to reference or discuss coexisting or interacting with RANGER.

It's certainly not for lack of my waving the RANGER
documents in front of peoples' faces. Please see
also the latest in the series on RANGER Scenarios:

http://tools.ietf.org/html/draft-russert-rangers

> I'm

RANGER is an architecture; VET, SEAL and ISATAP are
its constituent mechanisms. VET, SEAL and ISATAP are
implemented:

http://osprey67.com/seal
http://osprey67.com/vet
http://isatap.com

> arbitrary architectural concerns.

Very simple - put the xTRs on enterprise border routers,
and you have clean delineation of enterprise boundaries.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 May 2009 13:20:05 -0700

> From: David Meyer [mailto:[email-masked]]
> Sent: Wednesday, May 27, 2009 12:58 PM
> To: Templin, Fred L
> Cc: Darrel Lewis (darlewis); [email-masked];
[email-masked]
> 	from day one that one of the sweet spots for LISP is the

Hey - that's RANGER's space! VET already has the
mechanisms needed for operation on a CPE router,
including the ability for CPEs to discover ISP
border routers that can get out of the ISP network.
SEAL has the mechanisms for ensuring that home
network devices will see a robust MTU even if
the tunnel overhead eats into the physical link
MTU. And, ISATAP already has the all-important
Potential Router List (PRL) discovery mechanism.

These tools, plus consistent site administration
practices, is all that is necessary. 

> 	I'm not sure about the relevance of that statement. Could

Noel has asked that we consider in later phases moving the
xTR all the way out to the end systems. Such end systems
can be considered as enterprises unto themselves. (Think
about a laptop computer with its attached devices as an
example.) RANGER's enterprise-within-enterprise framework
therefore recurses from the smallest end system out to
the global Internet.

None of this stuff is new; it all harkens back to the
ROAD group work, NIMROD, and even as far back as the
Cerf and Pouzin work on CATENET.

> 	Perhaps, but again, what is your point?

The point is that with RANGER (and maybe also LISP)
we now have a restoration of architectural principles
for the Internet at-hand. No more hacking around with
chewing-gum and baling-wire point solutions; this is
stuff is mainstream and offers the whole package.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 May 2009 13:24:32 -0700

Dave,

> Sent: Wednesday, May 27, 2009 1:03 PM
> To: Templin, Fred L
> Cc: Sam Hartman; [email-masked]; [email-masked]

There was discussion, yes - and even some innuendos
tossed around about april-fools-day drafts and the
like. You can go back and look through the archives
for the earlier discussions if you'd like - as far
as I can tell, its all good.

Fred

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 May 2009 16:42:36 -0400

>>>>> "Darrel" == Darrel Lewis (darlewis) <[email-masked]> writes:

    Darrel> Hi Fred,
    >> somewhat surprising to me, since my understanding was that LISP
    >> would deploy on DFZ routers. RANGER already has the deployment
    >> scenarios for enterprise networks covered.

    Darrel> I don't recall the LISP drafts (specifically
    Darrel> draft-ietf-lisp-00.txt) restricting the placement of xTRs
    Darrel> to any particular place in a network's topology.  Some
    Darrel> placement choices seem to have inherent drawbacks, while
    Darrel> others have interesting benefits.

    Darrel> I'm not sure how LISP relates to RANGER, in that none of
    Darrel> the LISP drafts seem to reference or discuss coexisting or
    Darrel> interacting with RANGER.  I'm also not aware of any
    Darrel> implementations of RANGER that LISP implementations could
    Darrel> or have experimented/interoperated with.

No, but our charter limits us to LISP as a solution to the global
route scaling problem.  In our meeting before the LISP WG at San
Francisco, I stated my interpretation that the broad band use case
falls outside of our charter and those around the table agreed.  You
were one of the people there.

So, I do not believe that we're designing LISP to work on broad band
routers.  That doesn't mean we should go wrip out parts of LISP that
makes that possible or even that such things are undesirable.  It
simply means that "we need that for broad band," is not a
justification within the context of this WG.  "That's there for broad
band," may be a statement of historical fact.

I think the issues surrounding LISP and enterprises are more
complicated.  It's not clear to me whether designing LISP to run
behind enterprise firewalls is within our charter or not.  I'd ask
people making arguments based on enterprise firewalls to carefully
consider how their argument affects LISP as a solution to the global
route scaling problem.

Concerns about load balancing in the DFZ clearly are within scope.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 May 2009 13:50:32 -0700

Sam,

> Sent: Wednesday, May 27, 2009 1:43 PM
> To: Darrel Lewis (darlewis)
> Cc: Templin, Fred L; [email-masked]; [email-masked]

No fear - we have been prosecuting our case for RANGER
in the CPE routers on the v6ops list (and maybe also
behave to a more limited extent). Making good headway,
and we seem to be popping up on various radar screens.

Fred

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Wed, 27 May 2009 15:06:17 -0700

Sam,

> So, I do not believe that we're designing LISP to work on 
> broad band routers.  That doesn't mean we should go wrip out 
> parts of LISP that makes that possible or even that such 
> things are undesirable.  It simply means that "we need that 
> for broad band," is not a justification within the context of 
> this WG.  "That's there for broad band," may be a statement 
> of historical fact.
> 

I was merely stating for the record the reasons LISP designers chose UDP
as an encapsulation format.  Firewall traversal (due to default/typical
policies or inherent capabilities of the FW) and core link aggregation
are the two major reasons.

> complicated.  It's not clear to me whether designing LISP to 
> run behind enterprise firewalls is within our charter or not. 
>  I'd ask people making arguments based on enterprise 
> firewalls to carefully consider how their argument affects 
> LISP as a solution to the global route scaling problem.

To me, LISP Network Elements' (ITRs and ETRs) location behind or in
front of site firewalls is local site decision.  There are pro's and
cons to both choices.  Since in either use case LISP would be removing
the need for advertising site PI space into the DFZ (the route scaling
problem).  So I don't feel its relevant to the charter one way or the
other.

-Darrel

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 27 May 2009 23:58:01 -0700

> for data encapsulated packets in draft-ietf-lisp-00, except for data

This format was chosen to make for ease of parsing by using common  
code for all cases. And we are leaving it open for some future use of  
the fields you say aren't used.

> currently 32 bits of this header is not used by most data encapsulated

If we have learned from L2TP deployment, ISPs requested that a cookie  
appear in every data packet for some form of security (weak I might  
add but it's something). So the nonce in data packets could be used  
for the same purpose.

> encapsulated LISP packets.

You have to provide a more compelling reason to change it.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 28 May 2009 00:08:16 -0700

> be easily enabled to get through the other paths.

There is one large ISP that says it is a problem. So we should believe  
them.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 May 2009 04:55:04 -0700

> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Thursday, May 28, 2009 12:08 AM
> To: Templin, Fred L

Maybe so, but we're talking about a fundamental evolution
of the Internet architecture here - one that might actually
bring about IPv6 transition as a side effect. I would think
advocating that ISPs like this begin to transition wouldn't
be such an insurmountable order - else, how do new protocols
like ip-proto-4, ip-proto-41, GRE, etc. ever get adopted?

Fred

---

From: Sam Hartman <[email-masked]>
Date: Thu, 28 May 2009 10:13:11 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:

    >> ip-proto-4 also for RFC2003 and its kin. GRE also seems to get
    >> through. There will also be no NAT traversal in the interdomain
    >> core. So, I don't see it as unrealistic that a new IP protocol
    >> would get through most paths and could be easily enabled to get
    >> through the other paths.

    Dino> There is one large ISP that says it is a problem. So we
    Dino> should believe them.

Speaking as an individual, I have found that more harm than good comes
from believing singular unnamed parties who claim that "something is a
problem  and  will choose  to  discount  statements  like this  in  my
personal analysis.
It's indistinguishable from FUD.

I'm not stating a general opinion on UDP encapsulation, simply stating
that I personally find this style of argument highly objectionable.

My objections do not extend to:

*  Reasonably complete explanations that hide the identity of a party or network for business reasons
* Claims made with sufficient detail they can be independently verified
* Surveys of communities where I can evaluate the methodology even if I cannot see the input data