Subject: Re: [lisp] Comments to LISP+ALT draft

From: Vince Fuller <[email-masked]>
Date: Mon, 21 Dec 2009 15:18:22 -0800

Hi Hannu-

I getting an -02 draft of the LISP+ALT document ready and am specifically
working on incorporating your comments and suggestions. To that end, I'd
like to revisit the message you send to the list in late October.

> General comment:
> 
> LISP+ALT draft lacks consistency with draft-ietf-lisp-ms-04, instead the
> term "configuration" is used quite broadly covering the area of the
> mentioned draft and leaving too much for a reader to fill in the caps.
> See below what I mean:

After further thought, I am in agreement with the sentiment above. Despite
LISP+ALT pre-dating LISP-MS, it does need some changes to be consistent
with the general  "mapping database service interface" that LISP-MS is
intended to offer.

> Section 4 
> 
> Sentence from alt-01: "Note that ETRs are not required to participate
> (or prevented from participating) in LISP+ALT; they may choose
> communicate their mappings to their serving LISP+ALT router(s) at
> subscription time via configuration." This is very true, but ETRs may
> also choose to use Map-Register messages that contain a list of
> EID-prefixes plus a set of RLOC as defined in draft-ietf-lisp-ms-04.txt
> section 4. The issue here is that this is not only subscription time
> event but a continuous (periodic to be more specific) process as defined
> in draft-lisp-ms.

I have re-written this to: "Note that an ETR is not required to participate
(or prevented from participating) in LISP+ALT; an ETR may choose communicate
its mappings to its serving LISP+ALT router(s) using subscription time static
configuration or through a dynamic mechanism such as that described in
[LISP-MS].  An ITR may similarly use a static EID "default route" or other
configuration as described in [LISP-MS] to avoid the complexity of
participating in the ALT."

> Section 5
> Sentence "A LISP+ALT router near the edge learns EID prefixes originated
> by authoritative ETRs, either by eBGP peering with them or by
> configuration." This should be aligned with ietf-lisp-ms-04.txt to cover
> Map-registering. 

Done. Sentence rewritten to: "A LISP+ALT router near the edge learns EID
prefixes originated by authoritative ETRs.  This may be via eBGP with the
ETRs, by static configuration, or through some other dynamic mechanism
such as that defined in [LISP-MS]."

> Section 5.2
> "It also implies that an ETR that originates a prefix must maintain BGP
> sessions with all ALT routers that are configured to originate an
> aggregate which covers that prefix. " This I find contradictory to the
> target to keep ETR a simple CPE device as it insists on the use of BGP
> peering.  

I've rewritten this to describe both the simple, non-ALT-connected ETR case
as well as the more complex, ALT-connected ETR case: "It also implies that
an ETR which connects to the ALT using BGP must maintain BGP sessions
with all of the ALT routers that are configured to originate an aggregate
which covers that prefix.  See also [LISP-MS] for an example of other ways
that prefix origin consistency and aggregation are maintained."

> Section 5.4
> "It receives Data Probes and Map-Requests only over GRE tunnel(s) to its
> "upstream" LISP+ALT router(s) and responds with Map- Replies for the EID
> prefixes that it "owns". " Here the text is about ETR. I guess that is
> should say "receives Data Probes and Map-Requests ... FROM its
> upstream... " 

The GRE tunnels are to the upstream ALT routers but Map-Reqeusts and
Data Probes are received over those tunnels. I've re-written this sentence
to: "It receives Data Probes and Map-Requests only from its "upstream"
LISP+ALT routers over the GRE tunnel(s) configured to it/them."

> Section 6.2
> Sentence "these LISP+ALT router(s) the ETR must route Map-Requests and
> Data Probes to the ETR and contain configuration (in effect, static
> routes) for the ETR's ..." The first occurrence of "the ETR" looks like
> a typo. If not more clarification in  the text would improve its
> readability. Notice a again the use of the term of  "configuration" in
> this context. Not really sure if this is the similar configuration that
> was implied in the earlier part of the text.

You're right, there was a typo here. Fixed.

The rest of this comment touches on an interesting question: whether to
eliminate the "low-opex" ETR description. As you may recall, a "low-opex"
ETR is one that doesn't participate in ALT BGP but does have one or more
tunnel(s) to "edge" ALT router(s) so that it can receive Map-Reqeuests from
the ALT. Static routes are defined in the ALT router(s) at the far end of
the tunnel(s) to forward Map-Reqeusts to the ETR. Similarly, a "low-opex"
ITR is defined that has one or more tunnels to "edge" ALT routers and
static "default routes" that allow it to send Map-Reqeusts into the ALT.

These "low-opex" configurations are still valid even though we expect that
use of LISP-MS will obviate their use. Should we eliminate all references
to them from the LISP+ALT spec? It would simplify things a bit and would
allow most of your comments above to be resolve by simply deleting the text
that refers to static route/default configuration.

> Section 8.1
> "Not only does this greatly improve the scalability of the global
> routing system but it also allows improved traffic engineering
> techniques by allowing richer and more fine-grained policies to be
> applied."  But how are the operator policies and the mapping system
> policies correlated? The network can only apply its existing BGP
> policies for data packets entering into its network, but not during the
> map resolution phase?

An ETR, or collection of ETRs for a site, could implement ingress traffic
engineering policy by sending different Map-Reply data depending on the
source or other attributes of particular Map-Requests. This would be
independent of any routing policy it implements using BGP in the global
routing system.

> Section 9.1
> 
> "As in the case above, the ETR is connected to LISP+ALT router(s) using
> GRE tunnel(s) but rather than BGP being used, the LISP+ALT router(s) are
> configured with what are in effect "static routes" for the EID prefixes
> "owned" by the ETR. " Maybe ETR chooses to use the Map-Register message
> as in draft-eitf-lisp-ms, or is this what is meant by static routes?
> In case the ETR happens to have connections  to multiple LISP+ALT
> routers in different parts of the ALT hierarchy how does the ETR know
> where to register/configure what EID prefix?

This is the "low-opex" ETR which does have tunnel(s) in to the ALT but
does not run BGP. Fork the ETR's EID prefixes to be propagated into ALT
BGP, each of ALT routers to which the ETR has a tunnel is configured with
a "static EID prefix route" pointing at the tunnel (and, thus, at the ETR).
These "static" routes are "redistributed" into ALT BGP on the ALT routers.

In this case, there is no Map-Register. This "low-opex" case was described
in LISP+ALT as a way to simplify ETR configuration. LISP-MS was later 
defined as a better, more dynamic way of accomplishing the same goal.
This again begs the question of whether or not to eliminate the "low-opex"
ITR/ETR description from the ALT spec.

	--Vince

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 23 Dec 2009 13:54:02 +0200

Hello Vince,

Thank for your response.

Regarding the references to low "OPEX xTRs" I am all favoring to have
such an option. I think that the overall concept becomes stronger if you
allow such devices (and related distribution of the functionality) in
LISP. So, please keep them in the books.

Best regards
And Happy holidays 

Hannu

>-----Original Message-----
>From: ext Vince Fuller [mailto:[email-masked]] 
>Sent: Tuesday, December 22, 2009 01:18
>To: Flinck, Hannu (NSN - FI/Espoo)
>Cc: [email-masked]
>Subject: Re: [lisp] Comments to LISP+ALT draft
>
>Hi Hannu-
>
>I getting an -02 draft of the LISP+ALT document ready and am 
>specifically working on incorporating your comments and 
>suggestions. To that end, I'd like to revisit the message you 
>send to the list in late October.
>
>> General comment:
>> 
>> LISP+ALT draft lacks consistency with draft-ietf-lisp-ms-04, instead 
>> LISP+the
>with the general  "mapping database service interface" that 
>LISP-MS is intended to offer.
>
>> Section 4
>> 
>> EID-prefixes plus a set of RLOC as defined in 
>> draft-ietf-lisp-ms-04.txt section 4. The issue here is that this is 
>> not only subscription time event but a continuous (periodic 
>to be more 
>> specific) process as defined in draft-lisp-ms.
>
>I have re-written this to: "Note that an ETR is not required 
>to participate (or prevented from participating) in LISP+ALT; 
>an ETR may choose communicate its mappings to its serving 
>LISP+ALT router(s) using subscription time static 
>configuration or through a dynamic mechanism such as that 
>described in [LISP-MS].  An ITR may similarly use a static EID 
>"default route" or other configuration as described in 
>[LISP-MS] to avoid the complexity of participating in the ALT."
>
>> Section 5
>> Sentence "A LISP+ALT router near the edge learns EID prefixes 
>> originated by authoritative ETRs, either by eBGP peering 
>with them or 
>> by configuration." This should be aligned with 
>ietf-lisp-ms-04.txt to 
>> cover Map-registering.
>
>Done. Sentence rewritten to: "A LISP+ALT router near the edge 
>learns EID prefixes originated by authoritative ETRs.  This 
>may be via eBGP with the ETRs, by static configuration, or 
>through some other dynamic mechanism such as that defined in 
>[LISP-MS]."
>
>> Section 5.2
>> "It also implies that an ETR that originates a prefix must maintain 
>> BGP sessions with all ALT routers that are configured to 
>originate an 
>I've rewritten this to describe both the simple, 
>non-ALT-connected ETR case as well as the more complex, 
>ALT-connected ETR case: "It also implies that an ETR which 
>connects to the ALT using BGP must maintain BGP sessions with 
>all of the ALT routers that are configured to originate an 
>aggregate which covers that prefix.  See also [LISP-MS] for an 
>example of other ways that prefix origin consistency and 
>aggregation are maintained."
>
>
>> Section 5.4
>> "It receives Data Probes and Map-Requests only over GRE tunnel(s) to 
>> its "upstream" LISP+ALT router(s) and responds with Map- Replies for 
>> the EID prefixes that it "owns". " Here the text is about 
>ETR. I guess 
>> that is should say "receives Data Probes and Map-Requests 
>... FROM its 
>> upstream... "
>
>The GRE tunnels are to the upstream ALT routers but 
>Map-Reqeusts and Data Probes are received over those tunnels. 
>I've re-written this sentence
>> routes) for the ETR's ..." The first occurrence of "the ETR" looks 
>> like a typo. If not more clarification in  the text would 
>improve its 
>> this context. Not really sure if this is the similar configuration 
>> that was implied in the earlier part of the text.
>
>The rest of this comment touches on an interesting question: 
>whether to eliminate the "low-opex" ETR description. As you 
>may recall, a "low-opex"
>tunnel(s) to "edge" ALT router(s) so that it can receive 
>Map-Reqeuests from the ALT. Static routes are defined in the 
>ALT router(s) at the far end of the tunnel(s) to forward 
>Map-Reqeusts to the ETR. Similarly, a "low-opex"
>ITR is defined that has one or more tunnels to "edge" ALT 
>routers and static "default routes" that allow it to send 
>Map-Reqeusts into the ALT.
>
>These "low-opex" configurations are still valid even though we 
>expect that use of LISP-MS will obviate their use. Should we 
>eliminate all references to them from the LISP+ALT spec? It 
>would simplify things a bit and would allow most of your 
>comments above to be resolve by simply deleting the text that 
>refers to static route/default configuration.
>
>> Section 8.1
>> policies for data packets entering into its network, but not during 
>> the map resolution phase?
>
>An ETR, or collection of ETRs for a site, could implement 
>ingress traffic engineering policy by sending different 
>Map-Reply data depending on the source or other attributes of 
>particular Map-Requests. This would be independent of any 
>routing policy it implements using BGP in the global routing system.
>
>> Section 9.1
>> 
>> "As in the case above, the ETR is connected to LISP+ALT router(s) 
>> using GRE tunnel(s) but rather than BGP being used, the LISP+ALT 
>> router(s) are configured with what are in effect "static routes" for 
>> the EID prefixes "owned" by the ETR. " Maybe ETR chooses to use the 
>> Map-Register message as in draft-eitf-lisp-ms, or is this 
>what is meant by static routes?
>This is the "low-opex" ETR which does have tunnel(s) in to the 
>ALT but does not run BGP. Fork the ETR's EID prefixes to be 
>propagated into ALT BGP, each of ALT routers to which the ETR 
>has a tunnel is configured with a "static EID prefix route" 
>pointing at the tunnel (and, thus, at the ETR).
>In this case, there is no Map-Register. This "low-opex" case 
>was described in LISP+ALT as a way to simplify ETR 
>configuration. LISP-MS was later defined as a better, more 
>dynamic way of accomplishing the same goal.