Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3)
+1 I am however interested in the comparison, but I don't see it as part of an introduction or other lisp specification document Victor > On Aug 11, 2014, at 4:33 PM, "Dino Farinacci" wrote: > > We should not compare LISP to any other protocol. We should define what LISP > is. BGP and LISP solve different problems. > > Dino > >> On Aug 11, 2014, at 4:13 PM, Ronald Bonica wrote: >> >> Darrel, >> >> Clearly, this is a WG document and the entire WG gets a chance to review, >> accept or reject a contribution. That goes without saying for any document. >> >> >>Ron >> >>> -Original Message- >>> From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com] >>> Sent: Monday, August 11, 2014 7:10 PM >>> To: Ronald Bonica >>> Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list >>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >>> >>> >>> >>> I mentioned that I'd want to see the text before supporting (or opposing) >>> its >>> inclusion... So adding sections seems somewhat premature. >>> >>> >>> -D On Aug 11, 2014, at 3:55 PM, Ronald Bonica wrote: Darrel, Fair enough. Could the editors leave an empty section between the sections that are >>> now numbered 6.4 and 6.5. The Title of that section is "Differences Between >>> LISP and BGP". I will provide text within the next week or so. Ron > -Original Message- > From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com] > Sent: Monday, August 11, 2014 1:29 PM > To: Ronald Bonica > Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list > Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) > > >> On Aug 11, 2014, at 9:59 AM, Ronald Bonica wrote: >> >> >> In order to help the reader understand the difference between LISP >> and > BGP, it might be a good idea to add a few pages that compare and > contrast the two. It should answer the following questions: >> >> - In BGP, how does the producer of a route know that it is time to >> push it >> - In LISP, how does the consumer of a route know that it is time to >> pull it >> - In BGP, what happens when the control path between the producer >> and > consumer of a route becomes degraded or unusable >> - In LISP, what happens when the control path between the producer >> and > consumer of a route becomes degraded or unusable >> >> >> Ron > > I eagerly await your suggested text. > > -D > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
Dino, Exactly! The Intro doc needs text that is a) easy to parse and b) technically correct. This will certainly be more coarse that the definition in 6830, but probably a little more verbose than what we have already proposed. Ron > > Let's have descriptions where they are needed and formal definitions in the > specs that were already published. And we should have the intro document > make the descriptions more coarser than the technical definitions in the > specs. Agree? > > Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3)
We should not compare LISP to any other protocol. We should define what LISP is. BGP and LISP solve different problems. Dino On Aug 11, 2014, at 4:13 PM, Ronald Bonica wrote: > Darrel, > > Clearly, this is a WG document and the entire WG gets a chance to review, > accept or reject a contribution. That goes without saying for any document. > > >Ron > >> -Original Message- >> From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com] >> Sent: Monday, August 11, 2014 7:10 PM >> To: Ronald Bonica >> Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list >> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >> >> >> >> I mentioned that I'd want to see the text before supporting (or opposing) its >> inclusion... So adding sections seems somewhat premature. >> >> >> -D >> On Aug 11, 2014, at 3:55 PM, Ronald Bonica wrote: >> >>> >>> >>> Darrel, >>> >>> Fair enough. >>> >>> Could the editors leave an empty section between the sections that are >> now numbered 6.4 and 6.5. The Title of that section is "Differences Between >> LISP and BGP". I will provide text within the next week or so. >>> >>> Ron >>> >>> -Original Message- From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com] Sent: Monday, August 11, 2014 1:29 PM To: Ronald Bonica Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) On Aug 11, 2014, at 9:59 AM, Ronald Bonica wrote: > > In order to help the reader understand the difference between LISP > and BGP, it might be a good idea to add a few pages that compare and contrast the two. It should answer the following questions: > > - In BGP, how does the producer of a route know that it is time to > push it > - In LISP, how does the consumer of a route know that it is time to > pull it > - In BGP, what happens when the control path between the producer > and consumer of a route becomes degraded or unusable > - In LISP, what happens when the control path between the producer > and consumer of a route becomes degraded or unusable > > > Ron I eagerly await your suggested text. -D > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
> Darrel,
>
> The definitions offered by Albert and seconded by Dino is clear and succinct.
> This because they make blanket statements about the EID being independent of
> locator semantics and the RLOC being independent of identifier semantics.
>
> By contrast, the RFC 6830 definitions of EID and RLOC are closer to being
> technically correct. This is because the hedge around the issue of whether
> the EID is really devoid of locator semantics. Sadly, the RFC 6830
> definitions never really spell out the degree to which EIDs can carry locator
> semantics. Also, the RFC 6830 definitions are verbose and difficult to parse.
>
> As a WG, we need to come to consensus on this issue and document it in a
> manner that is comprehensible to newcomers reading the document.
Let's have descriptions where they are needed and formal definitions in the
specs that were already published. And we should have the intro document make
the descriptions more coarser than the technical definitions in the specs.
Agree?
Dino
>
>
>Ron
>
>
>
>> -Original Message-
>> From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com]
>> Sent: Monday, August 11, 2014 5:38 PM
>> To: Ronald Bonica
>> Cc: Darrel Lewis (darlewis); acabe...@ac.upc.edu; LISP mailing list list
>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
>>
>> I believe the satisfactory answer is the one that ended up in the definitions
>> section of RFC 6830.
>>
>> -D
>> On Aug 11, 2014, at 12:39 PM, Ronald Bonica wrote:
>>
>>> Darrel,
>>>
>>> Yes, we have. Sadly, I don't recall every having seen a satisfactory answer
>> on the mailing list. Can you point me to one?
>>>
>>>
>>> Ron
>>>
>>>
-Original Message-
From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com]
Sent: Monday, August 11, 2014 1:29 PM
To: Ronald Bonica
Cc: Darrel Lewis (darlewis); acabe...@ac.upc.edu; LISP mailing list
list
Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
Ron,
It strikes me that we've had discussions on what an EID is many, many
times before on this list. Perhaps looking at those archived
conversations would be useful.
-Darrel
On Aug 11, 2014, at 7:38 AM, Ronald Bonica wrote:
> Hi Albert,
>
> Your definition misses one small but important point. The degree to
> which
an EID carries topological information depends largely upon the
observer's location.
>
> For example, assume that a LISP site is served by two XTRs and both
> XTRs
go down. Nodes within the site can still communicate with one
another, even though no device that is operating has a LOCATOR. In
this case, where does topological information come from?
>
> Also, when an EID is advertised into the global Internet by a PITR,
> does it
continue to be an EID? If so, does it continue to be devoid of
location semantics?
>
>
> Ron
>
>> -Original Message-
>> From: Albert Cabellos [mailto:albert.cabel...@gmail.com]
>> Sent: Thursday, August 07, 2014 11:49 AM
>> To: Ronald Bonica
>> Cc: LISP mailing list list
>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
>>
>> Hi Ron
>>
>>
>>
>> On Wed, Aug 6, 2014 at 8:30 PM, Ronald Bonica
>> wrote:
>>> Folks,
>>>
>>> The following text is lifted from Section 6.1. At best, it is difficult
>>> to
>> parse.
>> At worst, it is incorrect. Is there a better way to distinguish
>> between an IED and a LOC?
>>>
>>
>> What about stating that RLOCs are topologically assigned to network
>> attachment points while EIDs are independent of the topology and
>> used to identify devices.
>>
>> Albert
>>
>>> Rn
>>>
>>> "The second key concept is that if one wants to be as
>>> forward-looking as
>> possible, conceptually one should think of the two kinds of names
>> (EIDs and
>> RLOCs) as naming different classes of entities.
>>>
>>> On the one hand, EIDs are used to name nodes - or rather, their
>>> end- end
>> communication entities. RLOC(s), on the other hand, name interfaces,
>> i.e.
>> places to which the system of routers sends packets.
>>>
>>> This distinction, the formal recognition of different kinds of
>>> entities
>> ("endpoints" and interfaces), and their association with the two
>> different classes of names, is also important. Clearly recognizing
>> interfaces and endpoints as distinctly separate classes of objects
>> is another improvement to the existing Internet" architecture."
>>>
>>>
>>>
>>> ___
>>> lisp mailing list
>>>
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3)
Darrel, Clearly, this is a WG document and the entire WG gets a chance to review, accept or reject a contribution. That goes without saying for any document. Ron > -Original Message- > From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com] > Sent: Monday, August 11, 2014 7:10 PM > To: Ronald Bonica > Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list > Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) > > > > I mentioned that I'd want to see the text before supporting (or opposing) its > inclusion... So adding sections seems somewhat premature. > > > -D > On Aug 11, 2014, at 3:55 PM, Ronald Bonica wrote: > > > > > > > Darrel, > > > > Fair enough. > > > > Could the editors leave an empty section between the sections that are > now numbered 6.4 and 6.5. The Title of that section is "Differences Between > LISP and BGP". I will provide text within the next week or so. > > > > Ron > > > > > >> -Original Message- > >> From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com] > >> Sent: Monday, August 11, 2014 1:29 PM > >> To: Ronald Bonica > >> Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list > >> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) > >> > >> > >> On Aug 11, 2014, at 9:59 AM, Ronald Bonica wrote: > >> > >>> > >>> In order to help the reader understand the difference between LISP > >>> and > >> BGP, it might be a good idea to add a few pages that compare and > >> contrast the two. It should answer the following questions: > >>> > >>> - In BGP, how does the producer of a route know that it is time to > >>> push it > >>> - In LISP, how does the consumer of a route know that it is time to > >>> pull it > >>> - In BGP, what happens when the control path between the producer > >>> and > >> consumer of a route becomes degraded or unusable > >>> - In LISP, what happens when the control path between the producer > >>> and > >> consumer of a route becomes degraded or unusable > >>> > >>> > >>> Ron > >> > >> I eagerly await your suggested text. > >> > >> -D ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
Darrel,
The definitions offered by Albert and seconded by Dino is clear and succinct.
This because they make blanket statements about the EID being independent of
locator semantics and the RLOC being independent of identifier semantics.
By contrast, the RFC 6830 definitions of EID and RLOC are closer to being
technically correct. This is because the hedge around the issue of whether the
EID is really devoid of locator semantics. Sadly, the RFC 6830 definitions
never really spell out the degree to which EIDs can carry locator semantics.
Also, the RFC 6830 definitions are verbose and difficult to parse.
As a WG, we need to come to consensus on this issue and document it in a manner
that is comprehensible to newcomers reading the document.
Ron
> -Original Message-
> From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com]
> Sent: Monday, August 11, 2014 5:38 PM
> To: Ronald Bonica
> Cc: Darrel Lewis (darlewis); acabe...@ac.upc.edu; LISP mailing list list
> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
>
> I believe the satisfactory answer is the one that ended up in the definitions
> section of RFC 6830.
>
> -D
> On Aug 11, 2014, at 12:39 PM, Ronald Bonica wrote:
>
> > Darrel,
> >
> > Yes, we have. Sadly, I don't recall every having seen a satisfactory answer
> on the mailing list. Can you point me to one?
> >
> >
> > Ron
> >
> >
> >> -Original Message-
> >> From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com]
> >> Sent: Monday, August 11, 2014 1:29 PM
> >> To: Ronald Bonica
> >> Cc: Darrel Lewis (darlewis); acabe...@ac.upc.edu; LISP mailing list
> >> list
> >> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
> >>
> >> Ron,
> >>
> >> It strikes me that we've had discussions on what an EID is many, many
> >> times before on this list. Perhaps looking at those archived
> >> conversations would be useful.
> >>
> >> -Darrel
> >>
> >>
> >> On Aug 11, 2014, at 7:38 AM, Ronald Bonica wrote:
> >>
> >>> Hi Albert,
> >>>
> >>> Your definition misses one small but important point. The degree to
> >>> which
> >> an EID carries topological information depends largely upon the
> >> observer's location.
> >>>
> >>> For example, assume that a LISP site is served by two XTRs and both
> >>> XTRs
> >> go down. Nodes within the site can still communicate with one
> >> another, even though no device that is operating has a LOCATOR. In
> >> this case, where does topological information come from?
> >>>
> >>> Also, when an EID is advertised into the global Internet by a PITR,
> >>> does it
> >> continue to be an EID? If so, does it continue to be devoid of
> >> location semantics?
> >>>
> >>>
> >>> Ron
> >>>
> -Original Message-
> From: Albert Cabellos [mailto:albert.cabel...@gmail.com]
> Sent: Thursday, August 07, 2014 11:49 AM
> To: Ronald Bonica
> Cc: LISP mailing list list
> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
>
> Hi Ron
>
>
>
> On Wed, Aug 6, 2014 at 8:30 PM, Ronald Bonica
> wrote:
> > Folks,
> >
> > The following text is lifted from Section 6.1. At best, it is difficult
> > to
> parse.
> At worst, it is incorrect. Is there a better way to distinguish
> between an IED and a LOC?
> >
>
> What about stating that RLOCs are topologically assigned to network
> attachment points while EIDs are independent of the topology and
> used to identify devices.
>
> Albert
>
> > Rn
> >
> > "The second key concept is that if one wants to be as
> > forward-looking as
> possible, conceptually one should think of the two kinds of names
> (EIDs and
> RLOCs) as naming different classes of entities.
> >
> > On the one hand, EIDs are used to name nodes - or rather, their
> > end- end
> communication entities. RLOC(s), on the other hand, name interfaces,
> i.e.
> places to which the system of routers sends packets.
> >
> > This distinction, the formal recognition of different kinds of
> > entities
> ("endpoints" and interfaces), and their association with the two
> different classes of names, is also important. Clearly recognizing
> interfaces and endpoints as distinctly separate classes of objects
> is another improvement to the existing Internet" architecture."
> >
> >
> >
> > ___
> > lisp mailing list
> > lisp@ietf.org
> > https://www.ietf.org/mailman/listinfo/lisp
> >>> ___
> >>> lisp mailing list
> >>> lisp@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/lisp
> >
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3)
I mentioned that I’d want to see the text before supporting (or opposing) its inclusion… So adding sections seems somewhat premature. -D On Aug 11, 2014, at 3:55 PM, Ronald Bonica wrote: > > > Darrel, > > Fair enough. > > Could the editors leave an empty section between the sections that are now > numbered 6.4 and 6.5. The Title of that section is "Differences Between LISP > and BGP". I will provide text within the next week or so. > > Ron > > >> -Original Message- >> From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com] >> Sent: Monday, August 11, 2014 1:29 PM >> To: Ronald Bonica >> Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list >> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >> >> >> On Aug 11, 2014, at 9:59 AM, Ronald Bonica wrote: >> >>> >>> In order to help the reader understand the difference between LISP and >> BGP, it might be a good idea to add a few pages that compare and contrast >> the two. It should answer the following questions: >>> >>> - In BGP, how does the producer of a route know that it is time to push it >>> - In LISP, how does the consumer of a route know that it is time to pull it >>> - In BGP, what happens when the control path between the producer and >> consumer of a route becomes degraded or unusable >>> - In LISP, what happens when the control path between the producer and >> consumer of a route becomes degraded or unusable >>> >>> >>> Ron >> >> I eagerly await your suggested text. >> >> -D ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3)
Darrel, Fair enough. Could the editors leave an empty section between the sections that are now numbered 6.4 and 6.5. The Title of that section is "Differences Between LISP and BGP". I will provide text within the next week or so. Ron > -Original Message- > From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com] > Sent: Monday, August 11, 2014 1:29 PM > To: Ronald Bonica > Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list > Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) > > > On Aug 11, 2014, at 9:59 AM, Ronald Bonica wrote: > > > > > In order to help the reader understand the difference between LISP and > BGP, it might be a good idea to add a few pages that compare and contrast > the two. It should answer the following questions: > > > > - In BGP, how does the producer of a route know that it is time to push it > > - In LISP, how does the consumer of a route know that it is time to pull it > > - In BGP, what happens when the control path between the producer and > consumer of a route becomes degraded or unusable > > - In LISP, what happens when the control path between the producer and > consumer of a route becomes degraded or unusable > > > > > > Ron > > I eagerly await your suggested text. > > -D ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3)
It is not a LISP versus BGP comparison we need to do. Because if we did that, then we would have to compare LISP with mobile-IP, IPsec, DNS, and other similar features that overlap. Plus there are enivronments where LISP is used where BGP doesn't exist, so how could we compare. Dino On Aug 11, 2014, at 9:59 AM, Ronald Bonica wrote: > Dino, > > You have a very good point! > > In order to help the reader understand the difference between LISP and BGP, > it might be a good idea to add a few pages that compare and contrast the two. > It should answer the following questions: > > - In BGP, how does the producer of a route know that it is time to push it > - In LISP, how does the consumer of a route know that it is time to pull it > - In BGP, what happens when the control path between the producer and > consumer of a route becomes degraded or unusable > - In LISP, what happens when the control path between the producer and > consumer of a route becomes degraded or unusable > > > Ron > > >> -Original Message- >> From: Dino Farinacci [mailto:farina...@gmail.com] >> Sent: Wednesday, August 06, 2014 5:07 PM >> To: Ronald Bonica >> Cc: LISP mailing list list >> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >> >> >>> LISP is different from GRE and L3VPN because it pulls mapping information >> to itself. By contrast, GRE mapping information is generally configured >> statically. L3VPN mapping information is pushed by BGP. Therefore, LISP >> must deal with the problems of stale mapping information and cache misses. >> Also, LISP must deal with the problem of egress encapsulation node liveness. >> >> Ron, I have to keep you honest here. It doesn't matter if you pull or push, >> ANY information that is distributed can be stale. >> >> If a route changes in BGP and there is a congested path and the Update is >> continually being retransmitted by TCP to get to the BGP peer, that BGP peer >> has stale information. >> >> Dino > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
I believe the satisfactory answer is the one that ended up in the definitions
section of RFC 6830.
-D
On Aug 11, 2014, at 12:39 PM, Ronald Bonica wrote:
> Darrel,
>
> Yes, we have. Sadly, I don't recall every having seen a satisfactory answer
> on the mailing list. Can you point me to one?
>
>
> Ron
>
>
>> -Original Message-
>> From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com]
>> Sent: Monday, August 11, 2014 1:29 PM
>> To: Ronald Bonica
>> Cc: Darrel Lewis (darlewis); acabe...@ac.upc.edu; LISP mailing list list
>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
>>
>> Ron,
>>
>> It strikes me that we've had discussions on what an EID is many, many times
>> before on this list. Perhaps looking at those archived conversations would be
>> useful.
>>
>> -Darrel
>>
>>
>> On Aug 11, 2014, at 7:38 AM, Ronald Bonica wrote:
>>
>>> Hi Albert,
>>>
>>> Your definition misses one small but important point. The degree to which
>> an EID carries topological information depends largely upon the observer's
>> location.
>>>
>>> For example, assume that a LISP site is served by two XTRs and both XTRs
>> go down. Nodes within the site can still communicate with one another, even
>> though no device that is operating has a LOCATOR. In this case, where does
>> topological information come from?
>>>
>>> Also, when an EID is advertised into the global Internet by a PITR, does it
>> continue to be an EID? If so, does it continue to be devoid of location
>> semantics?
>>>
>>>
>>> Ron
>>>
-Original Message-
From: Albert Cabellos [mailto:albert.cabel...@gmail.com]
Sent: Thursday, August 07, 2014 11:49 AM
To: Ronald Bonica
Cc: LISP mailing list list
Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
Hi Ron
On Wed, Aug 6, 2014 at 8:30 PM, Ronald Bonica
wrote:
> Folks,
>
> The following text is lifted from Section 6.1. At best, it is difficult
> to parse.
At worst, it is incorrect. Is there a better way to distinguish
between an IED and a LOC?
>
What about stating that RLOCs are topologically assigned to network
attachment points while EIDs are independent of the topology and used
to identify devices.
Albert
> Rn
>
> "The second key concept is that if one wants to be as
> forward-looking as
possible, conceptually one should think of the two kinds of names
(EIDs and
RLOCs) as naming different classes of entities.
>
> On the one hand, EIDs are used to name nodes - or rather, their end-
> end
communication entities. RLOC(s), on the other hand, name interfaces, i.e.
places to which the system of routers sends packets.
>
> This distinction, the formal recognition of different kinds of
> entities
("endpoints" and interfaces), and their association with the two
different classes of names, is also important. Clearly recognizing
interfaces and endpoints as distinctly separate classes of objects is
another improvement to the existing Internet" architecture."
>
>
>
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
>>> ___
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
Darrel,
Yes, we have. Sadly, I don't recall every having seen a satisfactory answer on
the mailing list. Can you point me to one?
Ron
> -Original Message-
> From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com]
> Sent: Monday, August 11, 2014 1:29 PM
> To: Ronald Bonica
> Cc: Darrel Lewis (darlewis); acabe...@ac.upc.edu; LISP mailing list list
> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
>
> Ron,
>
> It strikes me that we've had discussions on what an EID is many, many times
> before on this list. Perhaps looking at those archived conversations would be
> useful.
>
> -Darrel
>
>
> On Aug 11, 2014, at 7:38 AM, Ronald Bonica wrote:
>
> > Hi Albert,
> >
> > Your definition misses one small but important point. The degree to which
> an EID carries topological information depends largely upon the observer's
> location.
> >
> > For example, assume that a LISP site is served by two XTRs and both XTRs
> go down. Nodes within the site can still communicate with one another, even
> though no device that is operating has a LOCATOR. In this case, where does
> topological information come from?
> >
> > Also, when an EID is advertised into the global Internet by a PITR, does it
> continue to be an EID? If so, does it continue to be devoid of location
> semantics?
> >
> >
> > Ron
> >
> >> -Original Message-
> >> From: Albert Cabellos [mailto:albert.cabel...@gmail.com]
> >> Sent: Thursday, August 07, 2014 11:49 AM
> >> To: Ronald Bonica
> >> Cc: LISP mailing list list
> >> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
> >>
> >> Hi Ron
> >>
> >>
> >>
> >> On Wed, Aug 6, 2014 at 8:30 PM, Ronald Bonica
> >> wrote:
> >>> Folks,
> >>>
> >>> The following text is lifted from Section 6.1. At best, it is difficult
> >>> to parse.
> >> At worst, it is incorrect. Is there a better way to distinguish
> >> between an IED and a LOC?
> >>>
> >>
> >> What about stating that RLOCs are topologically assigned to network
> >> attachment points while EIDs are independent of the topology and used
> >> to identify devices.
> >>
> >> Albert
> >>
> >>> Rn
> >>>
> >>> "The second key concept is that if one wants to be as
> >>> forward-looking as
> >> possible, conceptually one should think of the two kinds of names
> >> (EIDs and
> >> RLOCs) as naming different classes of entities.
> >>>
> >>> On the one hand, EIDs are used to name nodes - or rather, their end-
> >>> end
> >> communication entities. RLOC(s), on the other hand, name interfaces, i.e.
> >> places to which the system of routers sends packets.
> >>>
> >>> This distinction, the formal recognition of different kinds of
> >>> entities
> >> ("endpoints" and interfaces), and their association with the two
> >> different classes of names, is also important. Clearly recognizing
> >> interfaces and endpoints as distinctly separate classes of objects is
> >> another improvement to the existing Internet" architecture."
> >>>
> >>>
> >>>
> >>> ___
> >>> lisp mailing list
> >>> lisp@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/lisp
> > ___
> > lisp mailing list
> > lisp@ietf.org
> > https://www.ietf.org/mailman/listinfo/lisp
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
Ron,
It strikes me that we’ve had discussions on what an EID is many, many times
before on this list. Perhaps looking at those archived conversations would be
useful.
-Darrel
On Aug 11, 2014, at 7:38 AM, Ronald Bonica wrote:
> Hi Albert,
>
> Your definition misses one small but important point. The degree to which an
> EID carries topological information depends largely upon the observer's
> location.
>
> For example, assume that a LISP site is served by two XTRs and both XTRs go
> down. Nodes within the site can still communicate with one another, even
> though no device that is operating has a LOCATOR. In this case, where does
> topological information come from?
>
> Also, when an EID is advertised into the global Internet by a PITR, does it
> continue to be an EID? If so, does it continue to be devoid of location
> semantics?
>
>
>Ron
>
>> -Original Message-
>> From: Albert Cabellos [mailto:albert.cabel...@gmail.com]
>> Sent: Thursday, August 07, 2014 11:49 AM
>> To: Ronald Bonica
>> Cc: LISP mailing list list
>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
>>
>> Hi Ron
>>
>>
>>
>> On Wed, Aug 6, 2014 at 8:30 PM, Ronald Bonica
>> wrote:
>>> Folks,
>>>
>>> The following text is lifted from Section 6.1. At best, it is difficult to
>>> parse.
>> At worst, it is incorrect. Is there a better way to distinguish between an
>> IED
>> and a LOC?
>>>
>>
>> What about stating that RLOCs are topologically assigned to network
>> attachment points while EIDs are independent of the topology and used to
>> identify devices.
>>
>> Albert
>>
>>> Rn
>>>
>>> "The second key concept is that if one wants to be as forward-looking as
>> possible, conceptually one should think of the two kinds of names (EIDs and
>> RLOCs) as naming different classes of entities.
>>>
>>> On the one hand, EIDs are used to name nodes - or rather, their end- end
>> communication entities. RLOC(s), on the other hand, name interfaces, i.e.
>> places to which the system of routers sends packets.
>>>
>>> This distinction, the formal recognition of different kinds of entities
>> ("endpoints" and interfaces), and their association with the two different
>> classes of names, is also important. Clearly recognizing interfaces and
>> endpoints as distinctly separate classes of objects is another improvement to
>> the existing Internet" architecture."
>>>
>>>
>>>
>>> ___
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3)
On Aug 11, 2014, at 9:59 AM, Ronald Bonica wrote: > > In order to help the reader understand the difference between LISP and BGP, > it might be a good idea to add a few pages that compare and contrast the two. > It should answer the following questions: > > - In BGP, how does the producer of a route know that it is time to push it > - In LISP, how does the consumer of a route know that it is time to pull it > - In BGP, what happens when the control path between the producer and > consumer of a route becomes degraded or unusable > - In LISP, what happens when the control path between the producer and > consumer of a route becomes degraded or unusable > > > Ron I eagerly await your suggested text. -D ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3)
Dino, You have a very good point! In order to help the reader understand the difference between LISP and BGP, it might be a good idea to add a few pages that compare and contrast the two. It should answer the following questions: - In BGP, how does the producer of a route know that it is time to push it - In LISP, how does the consumer of a route know that it is time to pull it - In BGP, what happens when the control path between the producer and consumer of a route becomes degraded or unusable - In LISP, what happens when the control path between the producer and consumer of a route becomes degraded or unusable Ron > -Original Message- > From: Dino Farinacci [mailto:farina...@gmail.com] > Sent: Wednesday, August 06, 2014 5:07 PM > To: Ronald Bonica > Cc: LISP mailing list list > Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) > > > > LISP is different from GRE and L3VPN because it pulls mapping information > to itself. By contrast, GRE mapping information is generally configured > statically. L3VPN mapping information is pushed by BGP. Therefore, LISP > must deal with the problems of stale mapping information and cache misses. > Also, LISP must deal with the problem of egress encapsulation node liveness. > > Ron, I have to keep you honest here. It doesn't matter if you pull or push, > ANY information that is distributed can be stale. > > If a route changes in BGP and there is a congested path and the Update is > continually being retransmitted by TCP to get to the BGP peer, that BGP peer > has stale information. > > Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 1)
Dino, I am not convinced that draft-farinacci-lisp-te provides a superset of the functionality provided by MPLS-TE. A more accurate statement would be to say that it provides a partially overlapping set of functionality. That said, I think that it is possible to avoid the entire argument not using the words "Traffic Engineering". A better approach would be to describe what LISP offers in this area, explicitly, in a few paragraphs. Ron > -Original Message- > From: Dino Farinacci [mailto:farina...@gmail.com] > Sent: Monday, August 11, 2014 12:00 PM > To: Ronald Bonica > Cc: Albert Cabellos; LISP mailing list list > Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 1) > > > > Hi Albert, > > > > LISP solves one part of the TE problem. That is, it allows the ITR to choose > the ETR through which traffic enters the destination LISP site. However, it > doesn't determine the path that traffic takes between IETR and ETR. So, it > that sense, LISP TE is different from traffic engineering with MPLS. > > Read draft-farinacci-lisp-te Ron. A path CAN be chosen. And it is a super-set > of functionality that MPLS-TE provides. > > > Also, I am not sure that it is *always* a good idea to let the ITR choose > > the > ETR through which traffic enters the destination LISP site. A discussion of > when this is and isn't a good idea might be appropriate in the intro > document. > > The intro document should not be subjective. We should have learned from > previous mistakes on this topic. > > Dino > > > > > Ron > > > >>> - Section 7.3 needs to be rethought. LISP doesn't provide TE, in the same > >> sense that MPLS does. It's quite different. > >>> > >> > >> RFC6830 states that LISP offers TE. > >> > > > > ___ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 1)
> Hi Albert, > > LISP solves one part of the TE problem. That is, it allows the ITR to choose > the ETR through which traffic enters the destination LISP site. However, it > doesn't determine the path that traffic takes between IETR and ETR. So, it > that sense, LISP TE is different from traffic engineering with MPLS. Read draft-farinacci-lisp-te Ron. A path CAN be chosen. And it is a super-set of functionality that MPLS-TE provides. > Also, I am not sure that it is *always* a good idea to let the ITR choose the > ETR through which traffic enters the destination LISP site. A discussion of > when this is and isn't a good idea might be appropriate in the intro document. The intro document should not be subjective. We should have learned from previous mistakes on this topic. Dino > > Ron > >>> - Section 7.3 needs to be rethought. LISP doesn't provide TE, in the same >> sense that MPLS does. It's quite different. >>> >> >> RFC6830 states that LISP offers TE. >> > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Fwd: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt
Dear all, we reviewed the draft and following offline discussions with Albert, you will find below a few comments. Best regards, Matthieu Coudron Stefano Secci 2. Underlay definition "The underlay corresponds to the RLOC space" This appears as too restrictive, as information about the underlay could come also from local AS/domain-level information such as traffic engineering databases, monitoring tools, etc, unaware of LISP. 3.2 MPTCP "Each of these sub-flows behaves as a legacy TCP flow and hence, from the network point of view, each sub-flow is a different TCP session. The network conditions over the different paths the sub-flows follow affect the whole MPTCP session. Since MPTCP has to keep the aggregate session consistent, each aggregated flow can perform as good as the worst of the sub flows it integrates." This paragraph seems incorrect. MPTCP RFC 6182 section 2.1 states that MPTCP should be at least as good as TCP, which in practice is true except in a few cases (e.g., if a subflow with a large share of the window becomes inactive, then you need to wait several timeouts before being able to be aggressive enough on other subflows). The RFC does not precisely address the scheduling mechanisms, but if for instance you consider the Linux implementation (http://www.multipath-tcp.org), it sends a maximum amount of data on the subflow with the lowest RTT and once its window is full, it will send on the 2nd lowest RTT subflow etc... so providing there is enough buffering at each endpoint, in terms of sheer throughput MPTCP should be able to aggregate all the subflows independently of their latency. It is true though that if packets are not scheduled carefully on each subflow, then application latency may increase. At LIP6, we already run LISP+MPTCP coupling experimentations (LISP providing topology informations and forwarding capabilities to the MPTCP layer), we documented last year in this article “Cross-layer Cooperation to Boost Multipath TCP Performance in Cloud Networks” available at: http://www-phare.lip6.fr/~secci/papers/CoSePuRaGa-CLOUDNET13.pdf . In our experiment, RTTs of the different paths were close to each other, which lead to very good performance, as the lower the RTT gap the better MPTCP performance. See here another interesting article about this matter: "How hard can it be? Designing and Implementing a Deployable MPTCP" available at https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf 4. Requirements / Device Discovery "This is solved for xTRs by sending Map Register messages." Did you mean Map Requests? Or can you explain why only Map Register? 4. Requirements / Forwarding Actions "These actions can be implemented as extensions to the current specifications of LISP-TE or LISP-SR or be defined by means of a new LCAF." Here it would be better not to exclude existing LCAF. For the MPTCP use-case, we have a prototype using already proposed LCAF messages. 7. Security Considerations "When including capabilities to allow for the discovery of devices and its capabilities, as well as the collection of metrics regarding the underlay and the local device itself, it should be taken into consideration that proper controls are put in place to enforce strict policies as to which devices can access what type(s) of information." Do you have any protocol in mind to get metrics from the overlay to the underlay? Relevant nodes should be chosen carefully so that they are not malicious or misfunctioning. For instance the TCP RTT seen by a VM is higher than one seen by a physical machine due to the hypervisor scheduling latency. On 11/08/2014 16:46, Matthieu Coudron wrote: -- Forwarded message -- From: Alberto Rodriguez-Natal Date: 2014-07-04 15:16 GMT+02:00 Subject: [lisp] Fwd: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt To: "lisp@ietf.org list" Dear all, We have just submitted a new draft discussing OAM (Operations Administration Management) use-cases and requirements for LISP. Please, feel free to review it and provide feedback. Thanks, Alberto -- Forwarded message -- From: Date: Fri, Jul 4, 2014 at 10:01 PM Subject: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt To: Albert Cabellos-Aparicio , Marc Portoles-Comeras , Alberto Rodriguez-Natal , Michael Kowal , Darrel Lewis , Fabio Maino A new version of I-D, draft-rodrigueznatal-lisp-oam-00.txt has been successfully submitted by Alberto Rodriguez-Natal and posted to the IETF repository. Name: draft-rodrigueznatal-lisp-oam Revision: 00 Title: LISP-OAM (Operations Administration Management): Use cases and requirements Document date: 2014-07-04 Group: Individual Submission Pages: 13 URL: http://www.i
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 1)
Hi Albert, LISP solves one part of the TE problem. That is, it allows the ITR to choose the ETR through which traffic enters the destination LISP site. However, it doesn't determine the path that traffic takes between IETR and ETR. So, it that sense, LISP TE is different from traffic engineering with MPLS. Also, I am not sure that it is *always* a good idea to let the ITR choose the ETR through which traffic enters the destination LISP site. A discussion of when this is and isn't a good idea might be appropriate in the intro document. Ron > > - Section 7.3 needs to be rethought. LISP doesn't provide TE, in the same > sense that MPLS does. It's quite different. > > > > RFC6830 states that LISP offers TE. > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
Hi Albert,
Your definition misses one small but important point. The degree to which an
EID carries topological information depends largely upon the observer's
location.
For example, assume that a LISP site is served by two XTRs and both XTRs go
down. Nodes within the site can still communicate with one another, even though
no device that is operating has a LOCATOR. In this case, where does topological
information come from?
Also, when an EID is advertised into the global Internet by a PITR, does it
continue to be an EID? If so, does it continue to be devoid of location
semantics?
Ron
> -Original Message-
> From: Albert Cabellos [mailto:albert.cabel...@gmail.com]
> Sent: Thursday, August 07, 2014 11:49 AM
> To: Ronald Bonica
> Cc: LISP mailing list list
> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2)
>
> Hi Ron
>
>
>
> On Wed, Aug 6, 2014 at 8:30 PM, Ronald Bonica
> wrote:
> > Folks,
> >
> > The following text is lifted from Section 6.1. At best, it is difficult to
> > parse.
> At worst, it is incorrect. Is there a better way to distinguish between an IED
> and a LOC?
> >
>
> What about stating that RLOCs are topologically assigned to network
> attachment points while EIDs are independent of the topology and used to
> identify devices.
>
> Albert
>
> >Rn
> >
> > "The second key concept is that if one wants to be as forward-looking as
> possible, conceptually one should think of the two kinds of names (EIDs and
> RLOCs) as naming different classes of entities.
> >
> > On the one hand, EIDs are used to name nodes - or rather, their end- end
> communication entities. RLOC(s), on the other hand, name interfaces, i.e.
> places to which the system of routers sends packets.
> >
> > This distinction, the formal recognition of different kinds of entities
> ("endpoints" and interfaces), and their association with the two different
> classes of names, is also important. Clearly recognizing interfaces and
> endpoints as distinctly separate classes of objects is another improvement to
> the existing Internet" architecture."
> >
> >
> >
> > ___
> > lisp mailing list
> > lisp@ietf.org
> > https://www.ietf.org/mailman/listinfo/lisp
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
