Subject: [RAM] New LISP draft available ...

From: Dino Farinacci <[email-masked]>
Date: Tue, 17 Jul 2007 10:56:28 -0700

We have a new LISP-02 draft available. The packet formats are  
consistent with CONS-01 as well as the implementation we are testing.

The draft has been submitted to the ID directory, but you can find a  
draft at:

	http://www.dinof.net/~dino/ietf/draft-farinacci-lisp-02.txt

This version is formatted much better.  ;-)

This draft also reflects comments from Ved Kafle and Olivier  
Bonaventure.

Thanks,
Dino, DaveM, Vince, DaveO

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 22 Jul 2007 23:40:57 +0200

On 2007-07-17 19:56, Dino Farinacci wrote:
> We have a new LISP-02 draft available. The packet formats are consistent 
> with CONS-01 as well as the implementation we are testing.
> 

A few comments on this version...

General points that aren't mentioned and perhaps should be:

MTU size reduction
Fragmentation (in IPv4)
Referrals (host A passes an address for host B to host C)

 > 4.1.  Packet Flow Sequence
...
 >    1.  host1.abc.com wants to open a TCP connection to host2.xyz.com.
 >        It does a DNS lookup on host2.xyz.com.  An A record is returned.
 >        This address is used as the destination EID and the locally-
 >        assigned address of host1.abc.com is used as the source EID.  An
 >        IP packet is built using the EIDs in the IP header and sent to
 >        the default router.

'default router' seems wrong (it would typically be understood to
mean the default router on the host's LAN). Doesn't this mean
'a site egress router' (which is ingress to the LISP domain)?

 > 5.3.  Tunnel Header Field Descriptions
...
 >    o  The OH header Time to Live field MUST be copied from the IH header
 >       Time to Live field.
 >
 >    o  The OH header Type of Service field SHOULD be copied from the IH
 >       header Type of Service field.

Does this apply when encapsulating across versions (4 in 6 or 6 in 4)?
In any case the terminology is slightly different in v6 headers.

In the v6 case, does it apply to the flow label too?

In 6.1.1 and elswhere you give RFC2434 as a reference for
AFIs. There's nothing about AFIs in that RFC; in fact AFI documentation
is a bit of a mystery.

In 6.1.3:

 >    Priority:  each RLOC is assigned a priority.  Lower values are more
 >       preferable.  When multiple RLOCs have the same priority, they are
 >       used in a load-split fashion.  A value of 255 means the RLOC MUST
 >       NOT be used.

Then why waste bits sending that RLOC?

 >    Weight:  when priorities are the same for multiple RLOCs, the weight
 >       indicates how to balance traffic between them.  Weight is encoded
 >       as a percentage of total packets that match the mapping entry.  If
 >       a non-zero weight value is used for any RLOC, then all RLOCs must
 >       use a non-zero weight value and then the sum of all weight values
 >       MUST equal 100.  What did the 3rd grader say after Steve Jobs gave
 >       an iPhone demo to the class?

It doesn't add up?

 >       ...  If a zero value is used for any RLOC
 >       weight, then all weights MUST be zero and the receiver of the Map-
 >       Reply will decide how to load-split traffic.

That MUST condition seems pointless. If there is any zero value, the
other values don't matter.

 > 6.2.  Routing Locator Selection
...
 >    o  Server-side returns a list of RLOC where a subset of the list has
 >       the same best priority.  Client can only use the subset list
 >       according to the weighting assigned by the server-side.  In this
 >       case, the server-side controls both the subset list and load-
 >       splitting across its members.

That rule doesn't seem viable or enforcable. The client side may
simply not desire to take orders on how to load share, and that
could be a business issue (if the client has ISP preferences
for example). I think it needs to be "Client SHOULD only use the subset list
       according to the weighting assigned by the server-side."

Nit: the citations of RFC3056 and RFC2784 are inverted in the text.

        Brian

---

From: Roger Jorgensen <[email-masked]>
Date: Tue, 24 Jul 2007 09:57:22 +0200 (CEST)

On Tue, 17 Jul 2007, Dino Farinacci wrote:
> We have a new LISP-02 draft available. The packet formats are consistent with 
> CONS-01 as well as the implementation we are testing.
>
> The draft has been submitted to the ID directory, but you can find a draft 
> at:
>
> This draft also reflects comments from Ved Kafle and Olivier Bonaventure.

a few more general question/clearification around the draft in general 
just to see if I understood it correct. Also fun to read those small 
comments on Steve Jobs and iPhone :)

In section 3, you mentio about EID:
" The source EID is obtained via existing
       mechanisms used to set a hosts "local" IP address.  LISP uses PI
       blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs.  Note
       that EID blocks may be assigned in a hierarchical manner,"

Why restrict it to PI addresses there? If, because no one know how it is 
moving on, ULA-C/G are approved and getting into use, they would be almost 
perfect for this usage.

Next thing, EID-prefix, that would be the above mention IP block?

Also in Section 4.1 (page 9-10), the example was worded so it could be 
read that it is Ipv4 only. I know thats not true but maybe change the 
wording a bit? A change like this could be enough:

"This section provides an example of a IPv4 unicast packet flow with 
the following parameters:"

-- 

------------------------------
Roger Jorgensen              | - ROJO9-RIPE  - RJ85P-NORID
[email-masked]           | - IPv6 is The Key!
-------------------------------------------------------

---

From: <[email-masked]>
Date: Tue, 24 Jul 2007 22:42:40 +0100

hi
 
 what's the relationship between the variants of lisp? Is it considered that an operator would migrate through the 4 steps lisp 1 -> 1.5 -> 2 -> 3? Could the variants co-exist? Or are they really 4 independent proposals? ('independent' meaning you make a choice of which *one* to deploy)
 
since lisp 1 uses routable EIDs, will it get the benefits hoped for a locator/ID split approach (in terms of the design goals in draft-irtf-rrg-design-goals)?
 
sorry if questions have already been covered 
 
thanks,
phil

________________________________

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 Jul 2007 22:30:54 -0700

>  what's the relationship between the variants of lisp? Is it  
> considered that an operator

They are implementation and deployment alternatives to experiment and  
learn about the design. We have already learned quite a bit so we can  
eliminate some of the variants before ever deploying them.

> would migrate through the 4 steps lisp 1 -> 1.5 -> 2 -> 3? Could  
> the variants co-exist?

At this point we think we can do a scalable mapping infrastructure  
with a LISP 1.5 variant that can go multiple ways. Or, a LISP 3  
variant that proposes one of (or a hybrid of) CONS, NERD, or APT.

> Or are they really 4 independent proposals? ('independent' meaning  
> you make a choice of which *one* to deploy)

The data-plane encapsulation is the same in all of them. The locator  
reachability mechanism is the same in all of them.

What differs is the way you retrieve EID-to-RLOC mappings. In LISP  
1.0 and 1.5, it is via data-triggered evens and in LISP 2 and LISP 3,  
it is purely in the control-plane.

> since lisp 1 uses routable EIDs, will it get the benefits hoped for  
> a locator/ID split approach (in terms of the design goals in draft- 
> irtf-rrg-design-goals)?

LISP 1 and LISP 2 will probably never get deployed.

> sorry if questions have already been covered

They have, but it's okay to repeat for clarity.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 Jul 2007 22:36:28 -0700

>> The draft has been submitted to the ID directory, but you can find  
>> a draft at:
>>
> a few more general question/clearification around the draft in  
> general just to see if I understood it correct. Also fun to read  
> those small comments on Steve Jobs and iPhone :)

Thanks!

> Why restrict it to PI addresses there? If, because no one know how  
> it is moving on, ULA-C/G are approved and getting into use, they  
> would be almost perfect for this usage.

We have discovered that a PI address may be used as a locator. We  
have heard plenty of feedback where a PI prefix may have to stay in  
the core routing tables. But we would like to keep that to the  
absolute minimum.

But you are right, we don't need a hard and fast rule about PI  
addresses.

> Next thing, EID-prefix, that would be the above mention IP block?

Yes.

> Also in Section 4.1 (page 9-10), the example was worded so it could  
> be read that it is Ipv4 only. I know thats not true but maybe  
> change the wording a bit? A change like this could be enough:
>
> "This section provides an example of a IPv4 unicast packet flow  
> with the following parameters:"

I realized we used the phrases "IP packet" and "A record" which imply  
IPv4 but you can see it means either. We can tighten this up in the  
next rev.

Dino

---

From: Scott Brim <[email-masked]>
Date: Wed, 25 Jul 2007 08:24:13 -0400

I didn't see a reply from Dino so ...

> Referrals (host A passes an address for host B to host C)

This kind of thing is a reason for maintaining current "address"
behavior.  What host A passes will be what host B believes its address
is, and what the LISP system considers to be B's EID.

> 'a site egress router' (which is ingress to the LISP domain)?

This is from the point of view of the originating endpoint, so it's
not the site egress router.  Whatever it uses to get its packets
forwarded to the destination -- probably a "default" router, but
technically "next hop router" is probably better.

> AFIs. There's nothing about AFIs in that RFC; in fact AFI documentation

Got a better reference?  All I know is BGP docs.

swb

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Jul 2007 17:42:22 +0200

Scott,

> is, and what the LISP system considers to be B's EID.

Sure, but it should be said.

> technically "next hop router" is probably better.

Yes, but the next line says:
     2.  The default router is configured as an ITR.
Are you saying that all next hop routers are ITRs? I would
have thought that only site egresses would be ITRs.

> Got a better reference?  All I know is BGP docs.

OK, look at the first page of http://www.iana.org/numbers.html
There is now a registry (I think I looked once before and
couldn't find it).

     Brian

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 25 Jul 2007 09:20:21 -0700

> A few comments on this version...

Thanks for the comments Brian. Sorry for the delay, but I want to add  
to what Scott said. I didn't disagree with any of his comments.

> General points that aren't mentioned and perhaps should be:

I will add text to the -03 version. Did you have any suggestions?

> Referrals (host A passes an address for host B to host C)

As Scott said, everything is EID based. Will make that more clear in  
the document.

> 'a site egress router' (which is ingress to the LISP domain)?

The default router is the first-hop router directly connected to the  
source. In this example, the ITR is placed in the first-hop router  
but can be placed anywhere, and maybe more ideally in the CE router  
(the one connected to the CE-PE link).

> Does this apply when encapsulating across versions (4 in 6 or 6 in 4)?

Absolutely.

> In any case the terminology is slightly different in v6 headers.

I will fix that.

> In the v6 case, does it apply to the flow label too?

I am not sure, depending on the semantic of the flow label which has  
been rather unclear. What do you think?

> AFIs. There's nothing about AFIs in that RFC; in fact AFI  

I will include a reference to http://www.iana.org/numbers.html. We  
use the term "AFI" in PIM as well.

> Then why waste bits sending that RLOC?

Because the cost of these bits are minimal and we don't want to  
change the record often. Want to keep the change frequency of mapping  
records low. Plus the loc-reach-bits in the encapsulation header  
refer to the position here and *could* override the 255 value.

> >       an iPhone demo to the class?

You have to read the CONS draft.  ;-)

> other values don't matter.

Not true, you could have 3 locators all with non-255 priority, each  
with 0, 50, and 50 as weights. What is conveyed in this encoding is  
that the first locator is not used. When all weights are 0, the ITR  
can load-split to it's liking.

>       according to the weighting assigned by the server-side."

Well, we do want client spec-compliant implications. I realize there  
are malicious systems out there but you have to document what the  
intended rules are.

> Nit: the citations of RFC3056 and RFC2784 are inverted in the text.

Will fix. Thanks again.

Dino

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Jul 2007 19:38:29 +0200

Dino,

On 2007-07-25 18:20, Dino Farinacci wrote:
> Thanks for the comments Brian. Sorry for the delay, but I want to add to 
> what Scott said. I didn't disagree with any of his comments.
> 

Not really, except that the extra header (unknown to the sender)
will reduce the MTU and we'd like to avoid that causing fragmentation.

> As Scott said, everything is EID based. Will make that more clear in the 
> document.

OK
> source. In this example, the ITR is placed in the first-hop router but 
> can be placed anywhere, and maybe more ideally in the CE router (the one 
> connected to the CE-PE link).

Fine, so this is a phrasing issue.

> been rather unclear. What do you think?

RFC 3697 doesn't give any guidance for unencrypted tunnels.
The only firm requirement is that the (inner) flow label
is delivered unchanged. I can imagine scenarios where you'd want
to keep the same label and others where you'd want to treat the
tunnel as a flow in itself. So I would vote for MAY copy until
we understand more.

> I will include a reference to http://www.iana.org/numbers.html. We use 
> the term "AFI" in PIM as well.
> 
>> In 6.1.3:
>>
> Because the cost of these bits are minimal and we don't want to change 
> the record often. Want to keep the change frequency of mapping records 
> low. Plus the loc-reach-bits in the encapsulation header refer to the 
> position here and *could* override the 255 value.

OK
> Not true, you could have 3 locators all with non-255 priority, each with 
> 0, 50, and 50 as weights. What is conveyed in this encoding is that the 
> first locator is not used. When all weights are 0, the ITR can 
> load-split to it's liking.

OK
> Well, we do want client spec-compliant implications. I realize there are 
> malicious systems out there but you have to document what the intended 
> rules are.

Maybe I'm disagreeing with that rule then. Is there a *technical* argument
for why the server side must determine the weights?
>> Nit: the citations of RFC3056 and RFC2784 are inverted in the text.

You're very welcome.

    Brian

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 25 Jul 2007 11:36:44 -0700

> will reduce the MTU and we'd like to avoid that causing fragmentation.

Understand the issue and there is no reliable solution to it. All  
tunneling protocols have this problem. But I believe in practice it's  
not a real issue. Hosts send no larger, typically than 1500 byte  
packets and routers are now more and more on 9K MTU links.

>> The default router is the first-hop router directly connected to  
>> the source. In this example, the ITR is placed in the first-hop  
>> router but can be placed anywhere, and maybe more ideally in the  
>> CE router (the one connected to the CE-PE link).
>

Correct.

>> I am not sure, depending on the semantic of the flow label which  
>> has been rather unclear. What do you think?
>

Okay, good suggestion.

>> Well, we do want client spec-compliant implications. I realize  
>> there are malicious systems out there but you have to document  
>> what the intended rules are.
>

There is a requirement for site-based ETRs to allow to control the  
data flow to each of the site's locators. This is precisely  
controlling ingress traffic flow.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Jul 2007 11:58:38 -0700

> packets and routers are now more and more on 9K MTU links.

There is also the size of the reassembly buffer to consider,
i.e., the Maximum Receive Unit (MRU). Nodes are advised to
configure an MRU at least as large as the interface MTU, but
in some cases that may only be 1500bytes.

Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Jul 2007 21:15:57 +0200

All OK except:

> There is a requirement for site-based ETRs to allow to control the data 
> flow to each of the site's locators. This is precisely controlling 
> ingress traffic flow.

Sorry to harp on but why is that a *technical* requirement?

(To be clear, if it's a *business* requirement I still think it
should be a SHOULD.)

     Brian

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 25 Jul 2007 13:47:55 -0700

> (To be clear, if it's a *business* requirement I still think it

It's a feature that that is highly desirable.

Dino