Subject: Re: [lisp] Last call for draft-ietf-lisp-12

From: Dino Farinacci <[email-masked]>
Date: Mon, 20 Jun 2011 15:19:32 -0700

> I have reviewed this this draft and think it needs more work before it
> is ready to proceed.
> I have a few general questions and comments - as well as text- 
> specific ones.

Thanks for the thorough review Alia, it is appreciated. See responses  
in line. Sorry it took over a month to get back to you on this.

> I hope this leads to fruitful discussion on the list.  I am also happy
> to add all of these to
> the Issue Tracker if necessary.
>
> 1) Can an EID and an RLOC have the same value?  They are different  
> namespaces,
>  but assumptions in the various drafts imply not.  Could this please
> be explicitly stated?

See my explanation below.

> 2) Where is the explicit text saying what EID-prefixes an ETR can
> register or reply authoritatively?  E.g. Can an ETR advertise a prefix
> (10.1/16) with holes (10.1.1/24)?  Answer should be no, of course, but
> extremely clear
> rules on this are needed.

If the site has an EID-prefix of the /16 that is the one it Map- 
Replies for. We have rules in section 6.1.5 "EID-to-RLOC UDP Map-Reply  
Message" on how to send Map-Replies when there are overlapping EID- 
prefixes and there has been much discussion on this mailing list about  
it.

> 3) Generally, a section specifying ETR behavior in regard to packets
> is missing.   What is specified is scattered widely.

"in regard to packets" is not clear what you are asking for. Do you  
mean for decapsulation purposes? If so,
in section 5.3 starting with text "When doing ETR/PETR decapsulation:"  
will explain it.

>   i) For instance, if an ETR receives a LISP encapsulated packet and
> decapsulates it,
>      but does not have EID locally, what should the ETR do?

Drop the packet. When decapsulation occurs, the inner header is  
inspected and what an IP router does today is what it does post  
decapsulation.

>   ii) Does an ETR have to do packet fragment reassembly?  If an ETR
> does not support
>      fragment reassembly, should it send an ICMP Too Big message and
> drop the fragment?
>      What should an ETR do with a fragment directed to its RLOC?

The ETR follows the IP and IPv6 specification in regards to reassemly  
of fragments. However, we try to avoid fragmentation. See section 5.4  
"Dealing with Large Encapsulated Packets" for solutions.

> 4) Generally, a section specifying ITR behavior in regard to packets
> is missing.
>  i) For instance, if an ITR receives a Negative Map Reply indicated
>  "drop", should the ITR send an ICMP Destination Unreachable with
>  Host Unreachable?

We did not want to specify this because in practice when this is done  
either the ICMP messages are either rate-limited or filtered so ICMP  
is not a reliable mechanism.

Experimentation will tell us more on what to do.

>  ii) If an ITR receives an ICMP packet (other than TTL exceeded) to
>  its RLOC, how does it properly handle or forward it?

Just like an IP router does today.

> 5) Are interfaces inside the LISP site explicitly configured on the
> xTR or is there a way for the ITR to identify them?

That is up to the implementation, but the 3 cisco implementations do  
not have this explicit configuration.

> Here are my questions tied specifically to the points in the text (and
> some typos):

Consider these done. I will comment for which comments we will make a  
change and when you don't see that, we did not make a change for your  
comment.

> a) On p 8 in EID-prefix:
>  "A globally routed address block may be used by its assignee as an
>  EID block."
>
> There are comments in other drafts also being last-called that imply
> it is possible to tell is a value is an EID or an RLOC - but other
> places, such as this, where it is clear that a value may be both an
> EID and an RLOC.

An address is an EID for sake of encapsulation when it is found in the  
mapping database. Since EID namespace and RLOC namespace  
*architecturally* are different spaces, an EID and an RLOC can have  
the same value. In practice, we believe when a prefix is not in the  
BGP DFZ core routing tables and registered to the mapping database is  
when the personality of an IP address changes from an locator prefix  
to an EID-prefix.

In practice, we have to deal with interworking, so we will find that  
EID-prefixes will be in the DFZ for transition purposes. And an EID- 
prefix and a regular route-prefix do not have to match, one can be a  
more-specific of the other which does complicate things. In any event,  
using more specific lookup matches, as we have been doing for decades  
in the routing system, will continue to happen. So if a destination  
address in a packet matches a more specific prefix in the mapping  
database, then the destination is considered an EID. If the more  
specific route is in the DFZ, then the destination is not considered  
an EID and is routed natively.

I like to call the addresses we use today as locators or RLOCs. Not  
everyone agrees with this thinking because things are more complicated  
than that. But I would like to think the addresses that are in the DFZ  
routing table today are "topological locations" and when a locator or  
RLOC is used in LISP, it is exactly this same routable address that is  
used.

> Clarification of this is important
>
> b) p. 10 Reencapsulating Tunnels: I do not see any references or
> suggestions on how these would be used.  I am also concerned about how
> routing/forwarding loops are prevented.

The rules for TTL decrement occur across these re-encapsulating  
boundaries.

> Could this be explicitly set as for future study & experimentation?

The use-cases are cropping up and yes we are experimenting with  
solutions for them.

> I can see ways to make it work and ways that might fail - but nothing
> providing details or mechanisms to avoid, detect, handle, or manage
> problems.
>
> c) p. 13: 3rd paragraph from bottom: The discussion about prepending
> additional LISP headers for TE doesn't give any indications or ideas
> of how an ISP transit might identify that it needs to prepend a TE-ETR
> RLOC or how it would find such an RLOC.  Given the complete lack of
> detail about this in this draft and the others being last-called,
> please explicitly specify this as experimental and for future study.

Please when you make comments, provide the text from the spec, so  
others reading this can understand the context. So for others, here is  
the paragraph that Alia is referring to:

    An additional LISP header may be prepended to packets by a TE-ITR
    when re-routing of the path for a packet is desired.  An obvious
    instance of this would be an ISP router that needs to perform  
traffic
    engineering for packets flowing through its network.  In such a
    situation, termed Recursive Tunneling, an ISP transit acts as an
    additional ingress tunnel router and the RLOC it uses for the new
    prepended header would be either a TE-ETR within the ISP (along
    intra-ISP traffic engineered path) or a TE-ETR within another ISP  
(an
    inter-ISP traffic engineered path, where an agreement to build  
such a
    path exists).

It was mentioned at a working group meeting that a Traffic Engineering  
draft needs to be written, but since that is out of charter, it has  
not been assigned. Perhaps, when the working group changes charter  
after posting of the experimental RFCs, we can do this work.

> Also, please change "An obvious instance of this would be..." to "A
> potential use-case would be..."

Consider this changed.

> d) p. 13: 2nd paragraph from bottom: What is the appropriate behavior
> for an ITR to do when it receives a packet that it would normally
> prepend a LISP header to but cannot?  Could you please add a "SHOULD
> drop and SHOULD send back an ICMP message"?  I don't see an  
> appropriate
> code point defined yet...

Here is the 2nd paragraph from the bottom of page 13:

    In order to avoid excessive packet overhead as well as possible
    encapsulation loops, this document mandates that a maximum of two
    LISP headers can be prepended to a packet.  It is believed two
    headers is sufficient, where the first prepended header is used at a
    site for Location/Identity separation and second prepended header is
    used inside a service provider for Traffic Engineering purposes.

> To contradict the idea that 2 headers is sufficient, just look at the
> deployment draft where a LISP site is dangling off another LISP site -
> causing 2 LISP headers and then the possibility of a Service Provider
> wanting to prepend one for TE purposes.

Right, when we go off and do the TE spec, we will decide if this  
should be lifted. We want this to be strict now because hardware  
engineers want a hard limit. My feedback from doing MPLS in hardware  
was that having it variable length and limitless was a huge problem.  
So most hardware implementations of MPLS ship with just 2 label stacks.

> Third, please rephrase the "It is believed..." to something like "The
> LISP experiment will presume..." or "LISP experimentation will start
> with the assumption that..."

I changed the text to "For initial LISP deployments, is is assumed two  
headers is sufficient".

> e) Sec 5, first paragraph: How does an ITR that wants to encapsulate a
> LISP-encapsulated packet for TE send back an ICMP Too Big message?

You didn't get to section 5.4 yet. When you get there, you should have  
your answers.  ;-)

> f) Sec 5: There is no indication in the packet formats that IPv4 in
> IPv6 or IPv6 in IPv4 SHOULD be supported.  I don't care about long
> format sections - but at a minimum, there should be a paragraph that
> specifies the encapsulation possibilities:
>
>   "A LISP packet consists of an outer header, a UDP header, and an
>   inner header.  The following combinations MUST be supported:
>     i) IPv4 outer header and IPv4 inner header (in Sec. 5.1)
>     ii) IPv6 outer header and IPv4 inner header
>     iii) IPv6 outer header and IPv6 inner header (in Sec 5.2)
>     iv) IPv4 outer header and IPv6 inner header "

I don't understand this comment. The summary is in the table of  
contents section names:

    5.  LISP Encapsulation Details . . . . . . . . . . . . . . . . . .  
16
      5.1.  LISP IPv4-in-IPv4 Header Format  . . . . . . . . . . . . .  
17
      5.2.  LISP IPv6-in-IPv6 Header Format  . . . . . . . . . . . . .  
17
      5.3.  Tunnel Header Field Descriptions . . . . . . . . . . . . .  
19

> g) An explicit statement that a LISP data packet appears as a UDP
> packet destined to port 4341 and a LISP control packet appears as a
> UDP packet destined to port 4342 would help for those who skim packet
> formats.

You can find that here in section 5.3:

    UDP Header:  The UDP header contains a ITR selected source port when
       encapsulating a packet.  See Section 6.5 for details on the hash
       algorithm used to select a source port based on the 5-tuple of  
the
       inner header.  The destination port MUST be set to the well-known
       IANA assigned port value 4341.

and here for control packets:

    The LISP UDP-based messages are the Map-Request and Map-Reply
    messages.  When a UDP Map-Request is sent, the UDP source port is
    chosen by the sender and the destination UDP port number is set to
    4342.  When a UDP Map-Reply is sent, the source UDP port number is
    set to 4342 and the destination UDP port number is copied from the
    source port of either the Map-Request or the invoking data packet.
    Implementations MUST be prepared to accept packets when either the
    source port or destination UDP port is set to 4342 due to NATs
    changing port number values.

> h) p.19: When is it desirable to not have a Nonce value in a packet?
> The Map-Version seems rather useful; which is required for support for
> the initial LISP experimentation?

When doing the echo-nonce Locator Reachability Algorithm.

> Also, the Nonce field could use similar description to that on p.29
> for the Nonce value - at least as far as how to produce one and
> what it is protecting against.

It says it here:

    Nonce:  An 8-byte random value created by the sender of the Map-
       Request.  This nonce will be returned in the Map-Reply.  The
       security of the LISP mapping protocol depends critically on the
       strength of the nonce in the Map-Request message.  The nonce
       SHOULD be generated by a properly seeded pseudo-random (or strong

Farinacci, et al.       Expires December 8, 2011               [Page 29]
Internet-Draft    Locator/ID Separation Protocol (LISP)        June 2011

       random) source.  See [RFC4086] for advice on generating security-
       sensitive random data.

> i) p. 20 L: The diagram indicates that the 2nd 32 bits are only
> Locator Status Bits, but the description under the I bit indicates
> that the I and L bit could be set at the same time - in which case the
> 2nd 32 bits aren't just Locator Status Bits.  Please align the diagram
> and description to better match the existence of the I bit.

I think you misread this. The text and the diagrams are consistent.  
And you must note the binary settings (with the notation of "x" as  
don't care bits).  See here:

    L: The L bit is the Locator-Status-Bits field enabled bit.  When  
this
       bit is set to 1, the Locator-Status-Bits in the second 32-bits of
       the LISP header are in use.

      x 1 x x 0 x x x
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |N|L|E|V|I|flags|            Nonce/Map-Version                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Locator Status Bits                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> j) typo: p. 20 V
>   "This bit indicates that the first 4 bytes of the LISP header is
>    encoded as:"
> but it show the 8 bytes of the LISP header and the second 4 are shown
> as being "Instance ID/Locator Status Bits"

Right, the description wants to show the entire LISP header but wants  
you, the reader, to focus on the ulong that the V-bit is pertaining to.

> Also, for the I bit, the last 4 bytes are referred to, but all 8 are
> shown.

Same as above comment.

> k) p. 21 flags: I think this should be a "It MUST be set to 0 on
> transmit and MUST be ignored on receipt" - if we want it to be really
> available for the future...
>
> Same for the Reserved field on p.29, p.33

Consider text updated for all 3 places.

> l) typo p. 21, end of LISTP Locator Status Bits:
>   "with that address taht the ETR is considered 'up'" -> ITR
> I think the ITR is the one who decides and sets the LSBs...

Fixed typo. No it is ETR.

> m) p. 21/22: The TTL copying from inner to outer should be a MUST not
> a SHOULD on encapsulation.  The TTL copying from outer to inner should
> be a MUST not a SHOULD on decapsulation.

It was agreed on by the working group to be SHOULD.

> Why does the draft say "when the Time to Live field of the outer
> header is less than the Time to Live of the inner header"? How could
> that not be the case if copying the TTL from inner to outer is
> required?  Please remove the text:

Because there can be a bug on the ITR/PITR where it is violating the  
spec.

>  ", when the Time to Live field of the outer header is less than the
>  Time to Live of the inner header.  Failing to perform this check can
>  cause the Time to Live of the inner header to increment across
>  encapsulation/decapsulation cycle.  This check is also performed
>  when doing initial encapsulation when a packet comes to an ITR or
>  PITR destined for a LISP site."
>
> n) Sec 5.4: This says that both, either or neither of the mechanisms
> can be implemented.  However, in Sec 5.4.1, it says:
>  "An implementation MAY set the DF bit in such headers to 0 if it has
>  good reason to believe there are unresolvable path MTU issues
>  between the sending ITR and the receiving ETR."
>
> This transforms the requirement from being imposed just on the ITR to
> something that the ETR has to deal with.  If a LISP-encapsulated
> packet is fragmented, then the ETR needs to do the reassembly.

Right, and the ITR has violated the spec. The spec is saying that  
fragmentation is done first and encapsulation second so the end-system  
reassembles and not the ETR.

> o) Sec 5.5: While an Instance ID allows disambiguation of addresses, I
> do not see any means of requesting or obtaining a EID-to-RLOC mapping.
> There is no such field in the Map-Request or Map-Reply messages.  It
> doesn't work with [ALT].  Please add a paragraph such as:
>
>  "While a LISP header can contain an Instance ID, there are currently
>  no provisions for requesting or receiving an EID-to-RLOC mapping
>  that considers Instance-IDs.  A LISP-NAT (described in [INTWRK]) may
>  provide a better solution for private addresses.  The use of
>  Instance-ID as described here is provided for future study."

The AFI encoded addresses can carry different address formats. Once  
AFI is called LCAF. See draft-farinacci-lisp-lcaf-05.txt for details.

> p) Sec 6.1: "The following new UDP packet types are used to retrieve
> EID-to-RLOC mappings"
>
> Please change to the more accurate:
>
>  "The following new UDP packet formats are used for LISP control
>  packets. The different packet types are listed in Sec. 6.1.1."

I changed to the first sentence. Thanks.

> Please move Sec 6.1.1 to before Sec 6.1 - so that readers know the
> allocated packet types before reading the descriptive text.

This part introduces UDP. We go the the LISP header in the next sub- 
section. That is why it was sequenced that way. Note in section 6  
there is no details of the format of the "LISP Message".

> After the packet formats, please change:
>  "The LISP UDP-based messages are the Map-Request and Map-Reply
>   messages.  When a UDP Map-Request is sent, the UDP source port is
>   chosen by the sender and the destination UDP port number is set to
>   4342.  When a UDP Map-Reply is sent, the source UDP port number is
>   set to 4342 and the destination UDP port number is copied from the
>   source port of either the Map-Request or the invoking data packet."
>
> to
>
>  "When a Map-Request or a Map-Register, encapsulated or not, is sent,
>  the UDP source port is chosen by the sender and the destination UDP
>  port number is set to 4342.  When a Map-Reply or Map-Notify is sent,
>  the source UDP port number is set to 4342 and the destination UDP
>  port number is copied from the source port of either the Map-Request
>  or the invoking data packet."

I prefer to not change it to what you suggest. Because you could imply  
from your text that a Map-Register message is encapsulated.

And each section indicates how each packet is sent.

> q) Sec 6.1.2:  Is the A bit ever non-zero for a Map-Request?

We did not want to specify it but we were thinking of an option where  
the Map-Request sender could request an authoritative request so if  
there were cachers of a matching mapping, that the cachers would send  
to the ETRs.

> r) Sec 6.1.2: Why is the p bit needed?  What does a ETR do based upon
> the Map-Request coming from a PITR (or not)?

It is useful for debugging. The ETR could cache the number of PITRs  
that have sent Map-Requests to it.

> s) Sec 6.1.3 first paragraph: Without LISP encapsulation and a
> Map Server, there isn't a way for an ITR to send a Map-Request to a
> destination-EID.

If the ITR is connected to the ALT, it can send the Map-Request to a  
destination EID. It assumes that the ALT carries EID-prefixes in its  
routing system.

> The Mapping Service is required for operation - so it should be ok for

Not true.

> the draft to mention the interfaces to it!  How about replacing this
> first paragraph with the below:
>
>  "An ITR can need to send a Map-Request for numerous reasons (e.g. to
>  get a mapping for an EID, testing an RLOC for reachability, or
>  refreshing a mapping before TTL expiry).  When the ITR knows an RLOC
>  for the relevant ETR (e.g. from the map-cache entry), the ITR can
>  create a Map-Request destined directly to that RLOC.  If the ITR
>  does not know the relevant ETR to query, then the Mapping Service
>  [LISP-MS] must be used.  To do this, the ITR creates a Map-Request
>  destined to the destination-EID and LISP encapsulates it as an
>  "Encapsulated Control Message" that is destined to the Mapping
>  Service [LISP-MS].  When an ITR receives a successful Map-Reply, the
>  ITR updates the cached set of RLOCs associated with the EID prefix
>  range."

We don't want to say this right here because there are too many  
options and if we reduce the set, we don't want to rewrite this text.

The API to the mapping system that xTRs use are the Map-Request, Map- 
Reply, and Map-Register messages. That we don't want to change if we  
change the mapping system. Right now, the mapping system is pretty  
modular and it is easy to change in and out without modifications to  
ITRs and ETRs.

> t) p.33 Record TTL:
>  "Record TTL: The time in minutes the recipient of the Map-Reply will
>  store the mapping.  If the TTL is 0, the entry SHOULD be removed
>  from the cache immediately.  If the value is 0xffffffff, the
>  recipient can decide locally how long to store the mapping."
>
> Since the ITR controls its own cache and cache entries, what I think
> you meant and would be more clear is:
>
>  "Record TTL: The maximum time in minutes that the recipient of the
>  Map-Reply may store the mapping.  If the TTL is 0, the entry MUST
>  be removed from the cache immediately.  IF the value is 0xFFFFFFFF,
>  the mapping does not expire and may be stored indefinitely."

You changed "will" to "may". We wanted stronger language than what you  
provided. We don't want ITRs to ignore TTL values.

> u) p. 33 No-Action: What packet encapsulation can happen!??!!  There's
> no RLOC to send the packet to!  Please clarify.

I will fix and say, the packet is dropped. Thanks.

> v) p. 33 Drop: On dropping the packet, is the sender ever notified?
> What about some ICMP for troubleshooting?

Up to the implementation.

> w) p. 34 Weight: Why is the ETR specifying that all locators get equal
> weight used for the ITR getting to decide?  This seems like a valid
> decision by the ETR!  Why not use weight=0 means ITR gets to decide as
> clearly specified on p.44 first full bullet?

The ETR allows the ITR to decide *within the highest priority* set of  
locators.

> x) p. 36 Mapping Protocol Data: [ALT] does not use this field.  Please
> remove the reference.

Agree, will remove.

> y) p.46: What happens when two ITRs send different LSB information
> (e.g. in the case of a partitioned LISP site)?

The ETR can note the fact and decide to probe each one to find out  
what is going on. If the LSBs are in conflict, the ETR can conclude  
that the site is partitioned.

> z) p.53 2nd paragraph from end: Unsolicited SMR-based Map-Requests
> MUST be sent to the mapping database system seems like an easy way to
> do a DDoS on the mapping database system - and have them all look
> valid and authenticated.

That is not what the 2nd paragraph on page 53 says. Again, this is  
confusing to parse since you don't sight the exact text.

Map-Requests of all kind need to be rate-limited if the implementation  
is spec compliant. If not, then the MR should rate-limit accepting  
them. We did not specify this since there are all sorts of ways to  
mitigate this and more experimentation will be necessary to understand  
solutions better.

> aa) Sec 7: How is a tunnel encapsulated packet received by an ETR with
> an EID in the destination?  Do you mean a non-LISP-tunnel encapsulated
> packet??

Years ago we used a concept of data-probes. That was a map-request in  
the form of an encapsulated data packet where the inner destination  
and outer destination were the same value. This assumed the core  
carried EID-prefixes. This is still in the spec because there are  
people who believe packets should not be dropped while waiting for a  
Map-Reply to be returned to an ITR.

> ab) Sec 8 last bullet:
>  "The technique of re-encapsulation ensures that packets only require
>  one tunnel header.  So if a packet needs to be rerouted, it is first
>  decapsulated by the ETR and then re-encapsulated with a new tunnel
>  header using a new RLOC."
>
> When would this legitimately happen?  It seems like risking looping...

When you want to redirect your encapsulation to an intermediate point  
for TE purposes, packet scrubbing purposes, to go through a stateful  
firewall, etc. And the TTL copying rules make it not loop forever.

> ac) Sec 14: The list of LISP Control Packet types (Sec 6.1.1) should
> also be an IANA registry...

That has not been decided by the working group.

> Looking forward to your responses,
> Alia

Thanks again,
Dino/Vince/Darrel/Dave

---

From: Alia Atlas <[email-masked]>
Date: Wed, 22 Jun 2011 18:32:44 -0400

Dino,

Thanks for your responses - mine are in-line below.

Alia

On Mon, Jun 20, 2011 at 6:19 PM, Dino Farinacci <[email-masked]> wrote:
>> I have a few general questions and comments - as well as text-specific
>> ones.
>
> Thanks for the thorough review Alia, it is appreciated. See responses in
> line. Sorry it took over a month to get back to you on this.
>
> If the site has an EID-prefix of the /16 that is the one it Map-Replies for.
> We have rules in section 6.1.5 "EID-to-RLOC UDP Map-Reply Message" on how to
> send Map-Replies when there are overlapping EID-prefixes and there has been
> much discussion on this mailing list about it.

I agree that there's been lots of discussion on the list.  Capturing
the decisions made
into the draft would be good practice, IMHO, and ensure it has been resolved.

Can an ETR have an prefix which has a hole in it?  What happens if the
ETR does not
know the correct RLOCs to use for that hole (since it isn't owned)?

I'm thinking of a case where initially there is a LISP site with a
/16.  Then, part of that
company is sold along with the /24 that is used in that division.
Now, can the original
site advertise the /16 with a hole?  How would it do that?

The problem here is that the ETR does NOT KNOW the correct locator-set
for the /24 hole
that has been sold off.

> "in regard to packets" is not clear what you are asking for. Do you mean for
> decapsulation purposes? If so,
> in section 5.3 starting with text "When doing ETR/PETR decapsulation:" will
> explain it.

I was looking for details beyond the basic packet manipulation.  I gave a couple
examples of the type of info I'm looking for in i) and ii) below.
Having clearly
specified behavior in one location that relates to packet-handling
and errors/ICMP is useful.   Another example is the R-bits manipulation...

This is, I think, another place where there aren't experimental questions - and
a very clear straightforward section describing what MUST be done would help
with interoperability.

> Drop the packet. When decapsulation occurs, the inner header is inspected
> and what an IP router does today is what it does post decapsulation.

Another option is for the ETR to look up the EID in the mapping database and
forward it.  Or the ETR could try and route it assuming the
destination IP address
is globally routable.

That the correct decision is to drop the packet is NOT specified.
There are indications
in the draft of decapsulation and reencapsulation & when those should be done is
not specified.

> The ETR follows the IP and IPv6 specification in regards to reassemly of
> fragments. However, we try to avoid fragmentation. See section 5.4 "Dealing
> with Large Encapsulated Packets" for solutions.

Of course, I read through that section.  My concern is the case where an ITR
may set the DF bit to 0.
  "When the outer header encapsulation uses an IPv4 header, an
   implementation SHOULD set the DF bit to 1 so ETR fragment reassembly
   can be avoided.  An implementation MAY set the DF bit in such headers
   to 0 if it has good reason to believe there are unresolvable path MTU
   issues between the sending ITR and the receiving ETR."

IF everything needs to be implemented, then an ETR has to be prepared for
an ITR to do that (adversarially if nothing else) and handle reassembly at
line-rate.

> We did not want to specify this because in practice when this is done either
> the ICMP messages are either rate-limited or filtered so ICMP is not a
> reliable mechanism.
>

Do you think those are strong concerns inside a single LISP site?  Rate-limited
is not the same as completely removed.  As specified, there is no mechanism
for the end-host to tell what's happening to its packets.

If you are going for parallelism to what an IP router does, then I think an ICMP
Destination Unreachable is appropriate.  IF not, then similarly
specifying that it
should not be sent & why would be useful.

> Just like an IP router does today.

An IP router doesn't have to figure out which end-host the message should have
gone to instead;  the ICMP packet would have gone there.  This is a PURELY LISP
problem.

The ICMP packet is in response to an encapsulated packet.  There are explicit
mechanisms described to make sure that TTL exceeded works.

What about Port Unknown or all the other ICMP messages that are
intended to reach
the end-host associated with the EID?   How does an ITR know which EID
was the source
of the packet that the ICMP packet is responding to?

> That is up to the implementation, but the 3 cisco implementations do not
> have this explicit configuration.

Is there a mechanism that is expected to inter-operate by which the
cisco implementations
do not need this?

> Consider these done. I will comment for which comments we will make a change
> and when you don't see that, we did not make a change for your comment.
>
>> a) On p 8 in EID-prefix:
> mapping database. Since EID namespace and RLOC namespace *architecturally*
> are different spaces, an EID and an RLOC can have the same value. In
> practice, we believe when a prefix is not in the BGP DFZ core routing tables
> and registered to the mapping database is when the personality of an IP
> address changes from an locator prefix to an EID-prefix.
>
> EID-prefixes will be in the DFZ for transition purposes. And an EID-prefix
> and a regular route-prefix do not have to match, one can be a more-specific
> of the other which does complicate things. In any event, using more specific
> lookup matches, as we have been doing for decades in the routing system,
> will continue to happen. So if a destination address in a packet matches a
> more specific prefix in the mapping database, then the destination is
> considered an EID. If the more specific route is in the DFZ, then the
> destination is not considered an EID and is routed natively.
>
> I like to call the addresses we use today as locators or RLOCs. Not everyone
> agrees with this thinking because things are more complicated than that. But
> I would like to think the addresses that are in the DFZ routing table today
> are "topological locations" and when a locator or RLOC is used in LISP, it
> is exactly this same routable address that is used.

OK - so the EID and RLOC space are *architecturally* different namespaces, but
in reality any overlap is assumed to be used by the same entity and go
to the same
end-host??

> The rules for TTL decrement occur across these re-encapsulating boundaries.

Yes - but while that eventually kills the packets, other traffic on
the links is impacted
and continues to be.  If xTR A forwards a packet to ETR B who forwards
it to ETR C
and ETR C forwards it back to xTR A, there's a forwarding loop that
continues to have
a negative impact.

TTL is to stop a packet caught in a forwarding loop from living
forever in the network.  It
doesn't stop more packets from getting caught in the forwarding loop.

> The use-cases are cropping up and yes we are experimenting with solutions
> for them.
>
> Please when you make comments, provide the text from the spec, so others
> reading this can understand the context.

Then my comments will be 10 times as long... but I'll try.

> So for others, here is the
> paragraph that Alia is referring to:
>
>   instance of this would be an ISP router that needs to perform traffic
>   intra-ISP traffic engineered path) or a TE-ETR within another ISP (an
>   inter-ISP traffic engineered path, where an agreement to build such a
>   path exists).
>
> It was mentioned at a working group meeting that a Traffic Engineering draft
> needs to be written, but since that is out of charter, it has not been
> assigned. Perhaps, when the working group changes charter after posting of
> the experimental RFCs, we can do this work.

Yup - that sounds like future study to me.

>> drop and SHOULD send back an ICMP message"?  I don't see an appropriate
> Right, when we go off and do the TE spec, we will decide if this should be
> lifted. We want this to be strict now because hardware engineers want a hard
> limit. My feedback from doing MPLS in hardware was that having it variable
> length and limitless was a huge problem. So most hardware implementations of
> MPLS ship with just 2 label stacks.

Yes, there's a game in MPLS of deciding how many labels down one needs to go
- but it has allowed a lot more flexibility.

Anyhow, on the packet-handling bit - what should be done if this limit would be
violated?

> I changed the text to "For initial LISP deployments, is is assumed two

"but no explicit error-handling will be done??"

> You didn't get to section 5.4 yet. When you get there, you should have your
> answers.  ;-)

Sadly, I actually had.  This is the TE-part, where an ITR needs to tell another
ITR (I guess) or the end-host that the packet is too big.

> I don't understand this comment. The summary is in the table of contents
> section names:
>
>   5.  LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 16
>     5.1.  LISP IPv4-in-IPv4 Header Format  . . . . . . . . . . . . . 17
>     5.2.  LISP IPv6-in-IPv6 Header Format  . . . . . . . . . . . . . 17
>     5.3.  Tunnel Header Field Descriptions . . . . . . . . . . . . . 19

Right - there is no description of DIFFERENT IP VERSIONS - e.g. IPv6 in IPv4
or IPv4 in IPv6

NOWHERE in the draft is this specifically said to be allowed or expected,
but list conversations certainly imply it.

>      algorithm used to select a source port based on the 5-tuple of the

Yes, I was looking for something short, pithy, and sooner.  This isn't a big
deal - obviously, it is specified.  I'd just missed it the first time
or so reading through.

>      random) source.  See [RFC4086] for advice on generating security-

Yup - that is for the Map-Request and Map-Reply. It doesn't mean that it
applies to the Echo-Nonce Locator Reachability Algorithm.

In fact, I'd assumed that it didn't..

> I think you misread this. The text and the diagrams are consistent. And you
> must note the binary settings (with the notation of "x" as don't care bits).
>  See here:
>
>   L: The L bit is the Locator-Status-Bits field enabled bit.  When this

Sorry, let me try again.  The description and diagram for the L bit ignores the
existence and changes done by the I bit.

Is it possible to have the I and L bit both set?  The description
under the I bit
implies that the L bit could be set to 1 - but gives the behavior if
the L bit is 0.

Just looking for consistency and clarity on this nit-picking detail.

> Right, the description wants to show the entire LISP header but wants you,
> the reader, to focus on the ulong that the V-bit is pertaining to.

What about a minor text change:

"This bit indicates that the first 4 bytes of the LISP header is encoded as:"
=>
"This bit indicates that the first 4 bytes of the LISP header is encoded as
shown below in the complete LISP header."

Again, this is more of a nitpick - but it was confusing the first couple times
I read it over.

> Consider text updated for all 3 places.

thanks

> Fixed typo. No it is ETR.

New text is clearer - or makes more sense to me now.

> It was agreed on by the working group to be SHOULD.

Really??  *shock*  I wonder why - it seems quite dangerous to me.

> Because there can be a bug on the ITR/PITR where it is violating the spec.

Ah - the joys of defensive coding.  Perhaps a hint that this isn't an expected
condition and is an indication of an error (or at least a SHOULD violation).

> reassembles and not the ETR.

So - I agree that the ITR should fragment first and then encapsulate - but
the ITR MAY set the DF bit to 0.  That's right above in the spec so I
don't see how
it is violating the spec - and it opens up the standard reassembly at line-rate
problems to the ETR.

> The AFI encoded addresses can carry different address formats. Once AFI is
> called LCAF. See draft-farinacci-lisp-lcaf-05.txt for details.

That still sounds like future study to me - or at least a note that
"work is on-going"
or such.

> This part introduces UDP. We go the the LISP header in the next sub-section.
> That is why it was sequenced that way. Note in section 6 there is no details
> of the format of the "LISP Message".

Ok - I still think knowing about the packet types before they're talked about is
useful - but the names are pretty descriptive in general.

> I prefer to not change it to what you suggest. Because you could imply from
> your text that a Map-Register message is encapsulated.

It can be encapsulated!!!

"  UDP:   The inner UDP header where the port assignments depends on the
      control packet being encapsulated.  When the control packet is a
      Map-Request or Map-Register, the source port is ITR/PITR selected
      and the destination port is 4342.  When the control packet is a
      Map-Reply, the source port is 4342 and the destination port is
      assigned from the source port of the invoking Map-Request.  Port
      number 4341 MUST NOT be assigned to either port.  The checksum
      field MUST be non-zero.
"

> And each section indicates how each packet is sent.

I was trying to combine the logic so it is clear what the set of
common behavior is.

> We did not want to specify it but we were thinking of an option where the
> Map-Request sender could request an authoritative request so if there were
> cachers of a matching mapping, that the cachers would send to the ETRs.

So - is this a reserved for future use thing?  Where currently a Map-Request
sender MUST set it to 0 and it MUST be ignored - for now?

> It is useful for debugging. The ETR could cache the number of PITRs that
> have sent Map-Requests to it.

K - clarification in the text?

> destination EID. It assumes that the ALT carries EID-prefixes in its routing
> system.

It does??  Where was I supposed to have figured that out?  I really did read all
these drafts thoroughly!

>> The Mapping Service is required for operation - so it should be ok for

k - I was combining the mapping database and the mapping service interface.

> We don't want to say this right here because there are too many options and
> if we reduce the set, we don't want to rewrite this text.
>
> The API to the mapping system that xTRs use are the Map-Request, Map-Reply,
> and Map-Register messages. That we don't want to change if we change the
> mapping system. Right now, the mapping system is pretty modular and it is
> easy to change in and out without modifications to ITRs and ETRs.

I was trying to specify the use of the mapping system APIs and that logic.

> provided. We don't want ITRs to ignore TTL values.

But either the ITR is in charge of its cache or it isn't!  If the ITR
can't decide
to remove the entry, then how can the ITR do cache management??

> Up to the implementation.

That's going to make management fun - particularly of mixed environments.
What about a recommendation for ICMP
or at least consideration - so that it can be manageable when implemented by
mere mortals?

> The ETR allows the ITR to decide *within the highest priority* set of

Yes, the question isn't about the "within the highest priority" set.
The question is
why is there different logic specified in p.44 first bullet:

"   o  Server-side sets weight of 0 for the RLOC subset list.  In this
      case, the client-side can choose how the traffic load is spread
      across the subset list.  Control is shared by the server-side
      determining the list and the client determining load distribution.
      Again, the client can use alternative RLOCs if the server-provided
      list of RLOCs are unreachable.
"
versus the different and inconsistent on p.34

"   Weight:  when priorities are the same for multiple RLOCs, the weight
      indicates how to balance unicast traffic between them.  Weight is
      encoded as a relative weight of total unicast packets that match
      the mapping entry.  For example if there are 4 locators in a
      locator set, where the weights assigned are 30, 20, 20, and 10,
      the first locator will get 37.5% of the traffic, the 2nd and 3rd
      locators will get 25% of traffic and the 4th locator will get
      12.5% of the traffic.  If all weights for a locator-set are equal,
      receiver of the Map-Reply will decide how to load-split traffic.
      See Section 6.5 for a suggested hash algorithm to distribute load
      across locators with same priority and equal weight values."

I am asking why setting the weights for a locator-set equal (assume case
with one priority for all) means that the ITR gets to decide how to split the
traffic?  If you want the ability to specify that, why not use a weight of 0 -
as specified on p.44 and quoted in the first paragraph above.

> The ETR can note the fact and decide to probe each one to find out what is
> going on. If the LSBs are in conflict, the ETR can conclude that the site is
> partitioned.

K - did you add some text specifying this?  Otherwise, I can see the
set bouncing...

> That is not what the 2nd paragraph on page 53 says. Again, this is confusing
> to parse since you don't sight the exact text.

I meant 2nd paragraph as opposed to the bullets.  It is below.

"   For security reasons an ITR MUST NOT process unsolicited Map-Replies.
   To avoid map-cache entry corruption by a third-party, a sender of an
   SMR-based Map-Request MUST be verified.  If an ITR receives an SMR-
   based Map-Request and the source is not in the locator-set for the
   stored map-cache entry, then the responding Map-Request MUST be sent
   with an EID destination to the mapping database system.  Since the
   mapping database system is more secure to reach an authoritative ETR,
   it will deliver the Map-Request to the authoritative source of the
   mapping data."

> Map-Requests of all kind need to be rate-limited if the implementation is
> spec compliant. If not, then the MR should rate-limit accepting them. We did
> not specify this since there are all sorts of ways to mitigate this and more
> experimentation will be necessary to understand solutions better.

?? K - where is that specified?  I agree that it makes sense for system design
- though it can cause problems in terms of latency.

> Years ago we used a concept of data-probes. That was a map-request in the
> form of an encapsulated data packet where the inner destination and outer
> destination were the same value. This assumed the core carried EID-prefixes.
> This is still in the spec because there are people who believe packets
> should not be dropped while waiting for a Map-Reply to be returned to an
> ITR.

Hmm, what about a brief intro comment such as:

"As in the case of data-probes, ..."

> When you want to redirect your encapsulation to an intermediate point for TE
> purposes, packet scrubbing purposes, to go through a stateful firewall, etc.
> And the TTL copying rules make it not loop forever.

Some specification of these cases as examples would bring clarity.
And the death of one lemming doesn't stop the others from going over
the cliff :-)

> That has not been decided by the working group.

Oh - ok.  I'm used to it being standard practice.  How else would they
be managed?

Thanks - I don't think you missed a question!

Alia

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 22 Jun 2011 18:49:20 -0400

The normal situation is that an EID block is delegated to an 
administrative authority (a company).  They use it.
They may use the main block, and use some sub-blocks.  That produces 
"holes" which are overlapping prefixes.  The handling of that is 
described in the document.  The ETRs which are responsible for the 
covering EID prefix must know which blocks are allocated elsewhere.
They have to identify those in the response.

THe details are spelled out.

The normal case would be that the division that was sold would be 
renumbered into its own or its new parents EID block.  After all, they 
are no longer part of the original site.  The overlapping prefix 
mechanisms allow for transition.

The more extreme case is not permitted.  You can not have a LISP EID 
block, within which there is a hole which is used as IP addresses but 
not as LISP EIDs.  (The inner portion can be used as both, but it has to 
be an EID.)

Yours,
Joel

On 6/22/2011 6:32 PM, Alia Atlas wrote:
> On Mon, Jun 20, 2011 at 6:19 PM, Dino Farinacci<[email-masked]>  wrote:
...

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 22 Jun 2011 19:41:01 -0400

Maybe I am missing something, but these two look like changes to the 
spec which will improve interoperability, and are easily done.
Is there a good reason not to add the clarifications that are requested 
here?

Yours,
Joel

On 6/22/2011 6:32 PM, Alia Atlas wrote:
> in the draft of decapsulation and reencapsulation&  when those should be done is
> not specified.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 22 Jun 2011 19:44:45 -0400

Since we have said repeatedly we waat this to work, it should be stated. 
  If it is already stated, I apologize but I can not find it.  The 
section you quoted from the ToC doesn't.

Yours,
Joel

---

From: Alia Atlas <[email-masked]>
Date: Thu, 23 Jun 2011 14:59:03 -0400

Joel,

Certainly I agree that the text in [LISP] addresses some of the basics
of handling overlapping
prefixes.  I had thought that one point of LISP was to avoid needing
to renumber; I believe that in
a similar case with IPv4 addresses today, it's not unusual to get the
smaller prefix announced.

However, in response to more detailed questions, I keep hearing back
assumptions or things
that have been discussed on the list and are not captured in a draft.

For a protocol like LISP, there are clearly many operational details
and assumptions to be agreed
upon and that need to be consistent.  Last time I looked at the
deployment draft, I didn't notice
them captured anywhere.

Are there plans for such a draft?

Alia

On Wed, Jun 22, 2011 at 6:49 PM, Joel M. Halpern <[email-masked]> wrote:
> The normal situation is that an EID block is delegated to an administrative
> authority (a company).  They use it.
> They may use the main block, and use some sub-blocks.  That produces "holes"
> which are overlapping prefixes.  The handling of that is described in the
> document.  The ETRs which are responsible for the covering EID prefix must
> know which blocks are allocated elsewhere.
> The normal case would be that the division that was sold would be renumbered
> into its own or its new parents EID block.  After all, they are no longer
> part of the original site.  The overlapping prefix mechanisms allow for
> transition.
>
> The more extreme case is not permitted.  You can not have a LISP EID block,
> within which there is a hole which is used as IP addresses but not as LISP
> EIDs.  (The inner portion can be used as both, but it has to be an EID.)
>
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 Jun 2011 15:46:23 -0400

While I would have liked a solution that completely removed renumbering, 
LISP does not cope with all of the cases that cause renumbering.  It is 
hard to state the tradeoff clearly and concisely, although it is 
inherent in teh fact that LISP is site oriented.  (Yes, there are some 
interesting extension to mobility, but those are out of scope...)

If there are operational issues that need to be consistent, those should 
be captured in the deployment document.  If they aren't, we need to fix 
that.  But there are limits.   I do not think we need to deal at this 
time with describing exactly what has to happen when a LISP site sells 
part of its network to another organization, that either is or is not 
using LISP.

Yours,
Joel

On 6/23/2011 2:59 PM, Alia Atlas wrote:
> On Wed, Jun 22, 2011 at 6:49 PM, Joel M. Halpern<[email-masked]>  wrote:

---

From: Alia Atlas <[email-masked]>
Date: Thu, 23 Jun 2011 16:24:29 -0400

On Thu, Jun 23, 2011 at 3:46 PM, Joel M. Halpern <[email-masked]> wrote:
> LISP does not cope with all of the cases that cause renumbering.  It is hard
> to state the tradeoff clearly and concisely, although it is inherent in teh
> fact that LISP is site oriented.  (Yes, there are some interesting extension
> to mobility, but those are out of scope...)
>
> If there are operational issues that need to be consistent, those should be
> captured in the deployment document.  If they aren't, we need to fix that.
>  But there are limits.   I do not think we need to deal at this time with
> describing exactly what has to happen when a LISP site sells part of its
> network to another organization, that either is or is not using LISP.

Sure - I'm not focused on that specific case.  What I'm after is the assumption
that an ETR knows the correct locator-set and statuses for a sub-prefix that
has been delegated away...  The locator-status bits make sense when the ETRs
are all in the same IGP; if that isn't the case, additional explicit
work is needed.

What would be useful is capturing the assumptions on knowledge and use-cases.
I know the deployment doc is a start of that, but some of this seems
to me to belong
in the protocol docs.  What must an ETR know and with what dynamics to advertise
a prefix and what issues come up with holes and delegation?

Is it a deliberate decision that there is no way for an ETR to say for
a hole that it
doesn't know what do with it - which means that if an ITR hit that
entry, it would need
to query...

>>> "holes"
>>> renumbered
>>> block,
>>>>> We have rules in section 6.1.5 "EID-to-RLOC UDP Map-Reply Message" on
>>>>> how
>>>>> to

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 Jun 2011 16:52:18 -0400

Unless I am very confused, an ETR can actually provide information that 
certain EID sub-blocks are delegated, without even providing the RLOCs. 
  For taht EID sub-prefix, it sets the locator count to 0, and sets the 
ACT bits to Send-Map-Request.  (This is useful in a number of other 
cases, for example, if a sub-block is used for something with very fine 
grain RLOCs.)

So I am still missing what needs to be specified.
The text says taht the ETR needs to know about all sub-blocks.

Yours,
Joel

On 6/23/2011 4:24 PM, Alia Atlas wrote:
> On Thu, Jun 23, 2011 at 3:46 PM, Joel M. Halpern<[email-masked]>  wrote:

---

From: Alia Atlas <[email-masked]>
Date: Thu, 23 Jun 2011 17:11:37 -0400

Ah - I had seen the negative Map-Replies - but only in the contexts
described on p. 37 of [lisp-13] (and quoted below).

I did not realize that what you are suggested was possible in what is
specified.  That answers a number
 of my concerns about the overlapping prefixes - and even seems to be
able to address the problem of
an EID sub-prefix being given away.

If a packet hits that EID sub-prefix and does the Map-Request, when
the new Map-Reply is received,
presumably it replaces the previous entry for the EID sub-prefix.
Later, if the original entries time-out
and are refreshed - does that also flush the non-negative sub-prefix
entry and replace it with the
negative Send-Map-Request entry?   I don't think doing so is a
problem, but I'm trying to clarify the
behavior.

Would it be possible to describe this very briefly in the section
about prefixes?  Something like
"The third use is when, due to overlapping prefixes, an ETR needs to
convey information about a sub-prefix
for which it does not have an accurate locator-set or know their
associated statuses.  In that case, an
ETR could include a record for that sub-prefix with an empty
locator-set and specifying an ACT of (2)
Send-Map-Request."

to go at the end of this paragraph on p. 37:

"Map-Reply records can have an empty locator-set.  A negative Map-
   Reply is a Map-Reply with an empty locator-set.  Negative Map-Replies
   convey special actions by the sender to the ITR or PTR which have
   solicited the Map-Reply.  There are two primary applications for
   Negative Map-Replies.  The first is for a Map-Resolver to instruct an
   ITR or PTR when a destination is for a LISP site versus a non-LISP
   site.  And the other is to source quench Map-Requests which are sent
   for non-allocated EIDs."

Thanks,
Alia

On Thu, Jun 23, 2011 at 4:52 PM, Joel M. Halpern <[email-masked]> wrote:
> certain EID sub-blocks are delegated, without even providing the RLOCs.  For
> taht EID sub-prefix, it sets the locator count to 0, and sets the ACT bits
> to Send-Map-Request.  (This is useful in a number of other cases, for
> example, if a sub-block is used for something with very fine grain RLOCs.)
>
>>> hard
>>> be
>>>>>>> If the site has an EID-prefix of the /16 that is the one it
>>>>>>> Map-Replies
>>>>>>> for.
>>>>>>> send Map-Replies when there are overlapping EID-prefixes and there
>>>>>>> has
>>>>>>> been

---

From: Ronald Bonica <[email-masked]>
Date: Sat, 25 Jun 2011 16:54:13 -0400

Dino,

Why not take the advice of RFC 4443? It says that a router SHOULD send an ICMP message.

                                          Ron

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 27 Jun 2011 09:06:53 -0700

> Why not take the advice of RFC 4443? It says that a router SHOULD  

Why duplicate what another document is specifying? The LISP router  
should send an ARP also when it decaps and the EID is directly  
connected. Should we specify that as well?

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 27 Jun 2011 12:23:25 -0400

Dino,

Maybe I am misreading you, but your response to me seems to contradict your response to Alia. When Alia asked, you said, "Experimentation will tell us more on what to do." When I asked, you seemed to have made up your mind about following the recommendation of RFC 4443.

Which is it?

                                                       Ron

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: Monday, June 27, 2011 12:07 PM
To: Ronald Bonica
Cc: Alia Atlas; [email-masked]
Subject: Re: [lisp] Last call for draft-ietf-lisp-12

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 27 Jun 2011 09:26:38 -0700

> Dino,
>
> Maybe I am misreading you, but your response to me seems to  
> contradict your response to Alia. When Alia asked, you said,  
> "Experimentation will tell us more on what to do." When I asked, you  
> seemed to have made up your mind about following the recommendation  
> of RFC 4443.
>
> Which is it?

I want to leave the spec as is.

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 27 Jun 2011 12:34:51 -0400

Dino,

That is to say, "silent on the matter"?

                               Ron

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: Monday, June 27, 2011 12:27 PM
To: Ronald Bonica
Cc: Alia Atlas; [email-masked]
Subject: Re: [lisp] Last call for draft-ietf-lisp-12

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Jun 2011 12:37:07 -0400

If I am reading this exchange properly, Dino, you are saying you do not 
want LISP ITRs to follow the general router advice from RFC 4443.
Is this a matter of taste?
Is there a technical difference that should be stated why different 
behavior may be appropriate?

Yours,
Joel

On 6/27/2011 12:26 PM, Dino Farinacci wrote:
>> Dino,
>>
>> Maybe I am misreading you, but your response to me seems to contradict
>> your response to Alia. When Alia asked, you said, "Experimentation
>> will tell us more on what to do." When I asked, you seemed to have
>> made up your mind about following the recommendation of RFC 4443.
>>
>> Which is it?
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 27 Jun 2011 09:39:41 -0700

> If I am reading this exchange properly, Dino, you are saying you do  
> not want LISP ITRs to follow the general router advice from RFC 4443.

I am not saying that.

> Is this a matter of taste?

No.

> behavior may be appropriate?

I am confused on this thread now. Ron is confusing matters.

Dino

>>> contradict

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Jun 2011 13:17:32 -0400

Just to clarify what you are asking Ron,
would you like the text to say "SHOULD send an ICMP"?
And in which places would you like it to say that?

Thanks,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 27 Jun 2011 10:23:12 -0700

> would you like the text to say "SHOULD send an ICMP"?

Right.

> And in which places would you like it to say that?

Which places in the spec yes.

Dino

>> "Experimentation will tell us more on what to do." When I asked,  
>> you seemed to have made up your mind about following the  
>> recommendation of RFC 4443.
>>
>> Which is it?
>>
>>                                                        Ron
>>
>>

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 27 Jun 2011 13:43:49 -0400

Joel,

An ITR should send an ICMP message whenever it discards a packet because it has been instructed to do so by a Negative Map Reply Message with indication to drop. As the document is currently organized, I am not sure where that detail fits.

                                                                   Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, June 27, 2011 1:18 PM
To: Ronald Bonica
Cc: Dino Farinacci; [email-masked]
Subject: Re: [lisp] Last call for draft-ietf-lisp-12

Thanks,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 27 Jun 2011 11:19:31 -0700

> Joel,
>
> An ITR should send an ICMP message whenever it discards a packet  
> because it has been instructed to do so by a Negative Map Reply  
> Message with indication to drop. As the document is currently  
> organized, I am not sure where that detail fits.

I will fix it.

Dino