Subject: [lisp] Last call comments for draft-ietf-lisp-deployment-09

From: Dino Farinacci <[email-masked]>
Date: Sat, 3 Aug 2013 14:12:38 -0700

>              LISP Network Element Deployment Considerations
>                    draft-ietf-lisp-deployment-09.txt

See enclosed my comments for this draft. This is my second review after a long gap from the first review. I must say this document is very well written, clear and concise. I really think it is ready for the IESG.

My comments are fairly mild and brief.

>    The problem is aggravated when the LISP site is multihomed.  Consider
>    the scenario in Figure 2: whenever a change to TE policies is
>    required, the customer contacts both ISP1 and ISP2 to make the
>    necessary changes on the routers (if they provide this possibility).
>    It is however unlikely, that both ISPs will apply changes
>    simultaneously, which may lead to inconsistent state for the mappings
>    of the LISP site.  Since the different upstream ISPs are usually
>    competing business entities, the ETRs may even be configured to
>    compete, either to attract all the traffic or to get no traffic.  The
>    former will happen if the customer pays per volume, the latter if the
>    connectivity has a fixed price.  A solution could be to have the
>    mappings in the Map Server(s), and have their operator give control
>    over the entries to customer, much like in the Domain Name System at
>    the time of this writing.

I would phrase this a bit differently. I would say the Map-Server could do proxy-replying and the policy applied by the Mapping System Provider (MSP) could control the mappings it provides for requesting ITRs.

>    Additionally, since xTR1, xTR2, and xTR3 are in different
>    administrative domains, locator reachability information is unlikely
>    to be exchanged among them, making it difficult to set Loc-Status-
>    Bits (LSB) correctly on encapsulated packets.  Because of this, and
>    due to the security concerns about LSB described in
>    [I-D.ietf-lisp-threats] their use is discouraged without verifying
>    ETR reachability through the mapping system or other means.  Mapping
>    versioning is another alternative [RFC6834].

I think another option is to set the L-bit to 0 and not use them when all xTRs are not under the same control.

>    This scenario has a set of implications:
> 
>    o  The site must carry at least partial BGP routes in order to choose
>       the best egress point, increasing the complexity of the network.
>       However, this is usually already the case for LISP sites that

I would say the site must carry more specific routes and typically BGP is used for this.

>     Stub1 ...   +-------+      ,-''     `--.      +-------+   ... Stub2
>              \  |   R_A1|----,'             `. ---|R_B1   |  /
>               --|       |   (     Transit     )   |       |--
>      ...  .../  |   R_A2|-----.             ,' ---|R_B2   |  \... ...
>                 +-------+      `--.     _.-'      +-------+
>      ...  ...     ISP_A            `--''            ISP_B     ... ...
> 
>                Figure 4: Inter-Service provider TE scenario
> 
>    Both ISPs deploy xTRs on on RLOC_A1/A2 and RLOC_B1/B2 respectively
>    and reach a bilateral agreement to deploy their own private mapping
>    system.  This mapping system contains bindings between the RLOCs of
>    Stub1 and Stub2 (owned by ISP_A and ISP_B respectively) and
>    RLOC_A1/A2 and RLOC_B1/B2.  Such bindings are in fact the TE policies
>    between both ISPs and the convergence time is expected to be fast,
>    since ISPs only have to update/query a mapping to/from the database.
> 
>    The packet flow is as follows.  First, a packet originated at Stub1
>    towards Stub2 is LISP encapsulated by Stub1's xTR.  The xTR of ISP_A

You did say earlier that stub1 and stub2 were LISP sites but it was not clear if they were being supported by xTRs from their service provider or by themselves. This reveals it but it could be more clear above that you say stub1 and stub2 are LISP sites where xTRs reside.

>    reencapsulates it and, according to the TE policies stored in the
>    private mapping system, the ISP_A xTR chooses RLOC_B1 or RLOC_B2 as
>    the reencapsulation destination.  Note that the packet transits
>    between ISP_A and ISP_B double-encapsulated.  Upon reception at the
>    xTR of ISP_B the packet is decapsulated and sent towards Stub2 which
>    performs the last decapsulation.

Double encapsulation means the tunneling is recursive and not re-encapsulating. You use the word "reencapsulates" above.

> 
> 3.2.  Map Resolvers
> 
>    A Map Resolver is a network infrastructure component which accepts
>    LISP encapsulated Map-Requests, typically from an ITR, and finds the
>    appropriate EID-to-RLOC mapping by either consulting its local cache
>    or by consulting the distributed mapping database.  Map Resolver
>    functionality is described in detail in [RFC6833].

But it would only do this if it was also a Map-Server. Otherwise it consults it's ALT or DDT data structures. Since you are discussing these components singularly, you probably don't want to say a map-resolver checks a local cache. Plus, "local cache" is too terse. You need to say "site cache".

Cheers,
Dino

---

From: Lori Jakab <[email-masked]>
Date: Tue, 06 Aug 2013 16:48:03 +0300

> My comments are fairly mild and brief.

Thanks for reviewing Dino!

> I would phrase this a bit differently. I would say the Map-Server could do proxy-replying and the policy applied by the Mapping System Provider (MSP) could control the mappings it provides for requ…

Much better, thank you.

> I think another option is to set the L-bit to 0 and not use them when all xTRs are not under the same control.

With "their use is discouraged" we meant setting the L-bit to 0, unless
reachability is verified through the mapping system.  Would you set the
L-bit to 0 in all cases?

> I would say the site must carry more specific routes and typically BGP is used for this.

Ok.

> You did say earlier that stub1 and stub2 were LISP sites but it was not clear if they were being supported by xTRs from their service provider or by themselves. This reveals it but it could be more…

Will do.

> Double encapsulation means the tunneling is recursive and not re-encapsulating. You use the word "reencapsulates" above.

We used "reencapsulate" as "encapsulate again with a second header", but
I seems to be used more for "remove encapsulation first and encapsulate
again", so we will change.

> But it would only do this if it was also a Map-Server. Otherwise it consults it's ALT or DDT data structures. Since you are discussing these components singularly, you probably don't want to say a…

At the time we wrote this section we were still thinking that caching
Map-Resolvers a-la-DNS were a good idea, and Map-Replies would go
through the Map-Resolver.  Since the idea was discarded, I will just
remove the reference to the local cache.

-Lori

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

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 6 Aug 2013 08:11:20 -0700

Thanks for the quick response Lori.

> With "their use is discouraged" we meant setting the L-bit to 0, unless

So maybe you should phrase it "... their use is discourage (set the L-bit to 0) without verifying ...".

> reachability is verified through the mapping system.  Would you set the

If the different ISPs are not working cooperatively, then yes, the L-bit should be set to 0 in all xTRs across all service providers.

> We used "reencapsulate" as "encapsulate again with a second header", but

Yes, I realize that. But we have language an many specs that an RTR is a re-encapsulating router meaning that re-encapsulation is the behavior of stripping a header and prepending a new one versus having a LISP header on a packet and prepending yet another one. RFC 6830 defines this clearly.

> again", so we will change.

Right.

> remove the reference to the local cache.

Thanks a lot.

Dino