Subject: Re: [lisp] Should we use Locator-Status-Bits in Internet deployment?

From: [email-masked] (Noel Chiappa)
Date: Mon, 21 Jan 2013 16:31:38 -0500 (EST)

> From: "Lori Jakab" <[email-masked]>

    > Damien is suggesting we recommend LSB not to be used for the
    > Internet-wide deployment of LISP, see below.
    > What do you think?

I never liked the blasted things anyway, so I wouldn't lose any sleep if
we did!

(I don't remember off the top of my head why I didn't like them: I think it
was a combination of the fixed number of bits, the fact that it might be
difficult for ETR X to know the state of ETR Y, the fact that 'reachable from
ITR A' [which you _really_ need to have anyway] is a subset of 'up', etc,
etc. But we didn't desperately need the header bits, and the mechanism wasn't
positively harmful, so I didn't bother to put up a big fight over it... :-)

    > From: "Joel M. Halpern" <[email-masked]>

    > I thought the point of the locator status bits was to tell me whether
    > the individual ETRs were up, and had connectivity to the site that they
    > are serving.

Yes, that's my understanding too.

    > If so, then the unpredictability of reachability across the net from
    > the ITR(s) to the individual ETRs would seem to be irrelevant.

See comment above... :-)

	Noel

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 21 Jan 2013 14:51:17 -0800

> positively harmful, so I didn't bother to put up a big fight over it... :-)

Maybe because they could be spoofed?

But they are good in control environments to take ETRs out of service without having to update the mapping database.

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 22 Jan 2013 02:05:24 +0000

Dino,

But isn't it troubling that the bits have one meaning in a controlled environment and another in the great-wide Internet?

                                            Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dino Farinacci
> Sent: Monday, January 21, 2013 5:51 PM
> To: Noel Chiappa
> Cc: [email-masked]; [email-masked]; lisp-
> [email-masked]
> Subject: Re: [lisp] Should we use Locator-Status-Bits in Internet
> deployment?
> 
> > (I don't remember off the top of my head why I didn't like them: I
> > think it was a combination of the fixed number of bits, the fact that
> > it might be difficult for ETR X to know the state of ETR Y, the fact
> > that 'reachable from ITR A' [which you _really_ need to have anyway]
> > is a subset of 'up', etc, etc. But we didn't desperately need the
> > header bits, and the mechanism wasn't positively harmful, so I didn't
> > bother to put up a big fight over it... :-)
> 
> But they are good in control environments to take ETRs out of service
> without having to update the mapping database.
> 
> Dino
> 
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 21 Jan 2013 19:15:14 -0800

They have the same meaning in all environment. It is a question when they should be verified. An LSB that changes in a public environment can cause a Map-Request to be sent and a signed Map-Reply can verify the LSB in  an authenticated matter. 

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 22 Jan 2013 10:15:16 +0100

Hi All,

the definition of LSB as of the to-be-soon-rfc lisp specification is:

LISP Locator Status Bits (LSBs):  When the L-bit is also set, the
      locator status bits field in the LISP header is set by an ITR to
      indicate to an ETR the up/down status of the Locators in the
      source site. 

I think that this clears Damien's question since LSB has no "reachability" meaning, rather it is a message from the site telling "from my perspective ETR X is up and running".

(BTW this may help debugging, since if the ETR is running but not reachable from the outside this clearly shows that the problem is along the path somewhere. Yeah… could be a long path… but it is still useful information).

The main concern is about security. Obviously LSB can be easily spoofed in a public environment and this is documented in section 6.4.1 of the draft-ietf-lisp-threats, which recommends:

   Locator Status Bits can be blindly trusted only in secure
   environments.  In the general unsecured Internet environment, the
   safest practice for xTRs is to confirm the status change
   through the mapping system.

So IMHO the thing to do is to simply put a reference to the lisp-threats draft about the use of LSBs.

ciao

Luigi

---

From: Eliot Lear <[email-masked]>
Date: Tue, 22 Jan 2013 10:19:56 +0100

On 1/22/13 10:15 AM, Luigi Iannone wrote:
> I think that this clears Damien's question since LSB has no
> "reachability" meaning, rather it is a message from the site telling
> "from my perspective ETR X is up and running".
>
> (BTW this may help debugging, since if the ETR is running but not
> reachable from the outside this clearly shows that the problem is
> along the path somewhere. Yeah… could be a long path… but it is still
> useful information).
>
> The main concern is about security. Obviously LSB can be easily
> spoofed in a public environment and this is documented in section
> 6.4.1 of the draft-ietf-lisp-threats, which recommends:
>
> So IMHO the thing to do is to simply put a reference to the
> lisp-threats draft about the use of LSBs.
>

And actually I would recommend a small change to
draft-ietf-lisp-threats, changing 'through the mapping system' to
'through other means'.  Otherwise it is possible to introduce circular
dependencies.

---

From: Damien Saucez <[email-masked]>
Date: Tue, 22 Jan 2013 11:22:13 +0100

> I think that this clears Damien's question since LSB has no "reachability" meaning, rather it is a message from the site telling "from my perspective ETR X is up and running".

Yes, it is not a problem of reachability but a question of status. However, how is the
status defined but the router that sends the LSB? How does it know that the locator
is up or down? How can we make sure that the LSB will be the same, whatever router
is building it?

Another question, how bad/good would it be for the traffic if two routers give different
LSBs?

> (BTW this may help debugging, since if the ETR is running but not reachable from the outside this clearly shows that the problem is along the path somewhere. Yeah… could be a long path… but it is s…

I agree, that in a controlled environment LSB can be very helpful to debug
the network. In the Internet where the topology is unknown I don't know if
it is a very relevant information, but it depends how the LSB is constructed.

> So IMHO the thing to do is to simply put a reference to the lisp-threats draft about the use of LSBs.

If the LSB has to be verified, I would then prefer to use versioning.

Damien Saucez

---

From: Darrel Lewis <[email-masked]>
Date: Tue, 22 Jan 2013 09:48:36 -0800

And this verify behavior is exactly what our IOS implementation does.

-Darrel

---

From: Lori Jakab <[email-masked]>
Date: Wed, 23 Jan 2013 11:08:16 +0200

On 01/22/13 12:22, Damien Saucez wrote:
>
> On 22 Jan 2013, at 10:15, Luigi Iannone <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Hi All,
>>

I think this depends a lot on the implementation. For example, if you
wanted to have the LSBs synced, you could use the status from the
locator records in the Map-Notify messages, and you would get the Map
Server view of status. With a more complex implementation, you could
probably get a better view. But I think it depends a lot on the
implementation.

> Another question, how bad/good would it be for the traffic if two

Again, that's something implementation specific, I don't think it's specced.

> it is a very relevant information, but it depends how the LSB is

Exactly, depends on the implementation. But the document we discuss is
about deployment, so operators can only do what implementations allow
them to do.

> If the LSB has to be verified, I would then prefer to use versioning.

I will put a reference to the threats draft, and suggest versioning as
an alternative.

Thanks for all the input!

-Lori

>
> Damien Saucez
>
>
>> ciao
>>
>> Luigi
>>
>>
>>
>>
>>
>> On 22 Jan. 2013, at 04:15 , Dino Farinacci <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>> They have the same meaning in all environment. It is a question when
>>> they should be verified. An LSB that changes in a public environment
>>> can cause a Map-Request to be sent and a signed Map-Reply can verify
>>> the LSB in an authenticated matter.
>>>
>>> Dino
>>>
>>> On Jan 21, 2013, at 6:05 PM, Ronald Bonica <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>>> Dino,
>>>>
>>>> But isn't it troubling that the bits have one meaning in a
>>>> controlled environment and another in the great-wide Internet?
>>>>
>>>> Ron
>>>>
>>>>
>>>>> From: [email-masked] <mailto:[email-masked]>
>>>>> [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of
>>>>> Dino Farinacci
>>>>> Cc: [email-masked] <mailto:[email-masked]>;
>>>>> [email-masked] <mailto:[email-masked]>; lisp-
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: "Wolfgang Riedel (wriedel)" <[email-masked]>
Date: Tue, 22 Jan 2013 17:37:26 +0000

Hi Folks,

for a multi-homed side I see a use case where different ITR's signal different LSBs for the same EID space based on local conditions. This could be different from the reachability of the IP of the ITR itself.
I just think of an active-active datacenter with a ~30km distance in between which is propagating the same EID space over different ITR's. If I am doing maintenance on one side I may send out different LSB's if I want gracefully bring down the other side.

Maybe I missed something but aren't we already using LSB within the beta network which is spanned across the planet in a uncontrolled environment?
So why not just analyze the data we can get out of it instead of guessing?

Wolfgang

pxtr-even#sh ip lisp forwarding eid remote

Prefix                 Fwd action  Locator status bits
153.16.0.0/16          signal      0x00000000
  packets/bytes   19273/966730
153.16.0.0/24          encap       0x00000001
  packets/bytes    1574/79142
153.16.0.128/25        encap       0x00000001
  packets/bytes     522/24816
153.16.1.0/24          fwd native  0x00000000
  packets/bytes   31165/1722380
153.16.2.7/32          drop        0x00000000
  packets/bytes       4/1552
153.16.2.8/32          drop        0x00000000
  packets/bytes       0/0
153.16.2.62/32         drop        0x00000000
  packets/bytes       1/48
153.16.2.71/32         drop        0x00000000
  packets/bytes       0/0
153.16.2.132/32        drop        0x00000000
  packets/bytes       3/183
153.16.2.138/32        drop        0x00000000
  packets/bytes       0/0
153.16.2.165/32        drop        0x00000000
  packets/bytes       0/0
153.16.3.0/24          encap       0x00000003
  packets/bytes    3772/207186
153.16.4.0/24          encap       0x00000001
  packets/bytes  127527/9518378
153.16.5.0/24          encap       0x00000003
  packets/bytes   17350/1020128
153.16.6.0/24          fwd native  0x00000000
  packets/bytes   17844/1054819
153.16.7.0/24          fwd native  0x00000000
  packets/bytes   27836/1595624
153.16.8.0/24          encap       0x00000003
  packets/bytes    3641/189530
153.16.9.0/24          fwd native  0x00000000
Prefix                 Fwd action  Locator status bits
  packets/bytes   27698/1312693
153.16.10.0/24         encap       0x00000001
  packets/bytes   46626/4586745
153.16.11.18/32        drop        0x00000000
  packets/bytes       0/0
153.16.12.0/26         encap       0x00000001
  packets/bytes     767/39811
153.16.12.64/26        encap       0x00000001
  packets/bytes     786/50508
153.16.12.128/26       fwd native  0x00000000
  packets/bytes    7057/339336
153.16.12.192/27       fwd native  0x00000000
  packets/bytes      49/2254
153.16.12.240/29       encap       0x00000001
  packets/bytes    1308/140869
153.16.12.248/29       encap       0x00000001
  packets/bytes    4966/436764
153.16.13.0/28         encap       0x00000001
  packets/bytes     180/8966
153.16.13.16/28        fwd native  0x00000000
  packets/bytes      53/2438
153.16.13.32/28        encap       0x00000001
  packets/bytes     200/12377
153.16.13.48/28        fwd native  0x00000000
  packets/bytes    3518/302318
153.16.13.80/28        encap       0x00000001
  packets/bytes     197/16828
153.16.13.96/28        encap       0x00000001
  packets/bytes     196/9763
153.16.13.144/28       encap       0x00000001
  packets/bytes      96/4621
153.16.13.160/28       encap       0x00000001
  packets/bytes      79/4112
153.16.13.176/28       encap       0x00000001
  packets/bytes   10937/5078427
153.16.13.192/28       encap       0x00000001
  packets/bytes      99/4886
153.16.13.208/28       encap       0x00000001
  packets/bytes     126/6102
Prefix                 Fwd action  Locator status bits
153.16.13.224/28       encap       0x00000001
  packets/bytes     101/5873
153.16.14.0/24         fwd native  0x00000000
  packets/bytes   18174/1382065
153.16.15.71/32        drop        0x00000000
  packets/bytes      71/3668
153.16.16.0/24         encap       0x00000001
  packets/bytes    2291/117038
153.16.17.0/28         fwd native  0x00000000
  packets/bytes    2443/114858
153.16.17.16/28        encap       0x00000001
  packets/bytes     746/41241
153.16.17.32/28        fwd native  0x00000000
  packets/bytes    1007/46942
153.16.17.48/28        fwd native  0x00000000
  packets/bytes      28/1288
153.16.17.64/28        fwd native  0x00000000
  packets/bytes     569/27852
153.16.17.80/28        encap       0x00000001
  packets/bytes     197/9453
153.16.17.96/28        fwd native  0x00000000
  packets/bytes       0/0
153.16.17.112/28       fwd native  0x00000000
  packets/bytes       0/0
153.16.17.176/28       fwd native  0x00000000
  packets/bytes     150/6900
153.16.17.192/28       encap       0x00000001
  packets/bytes     278/28562
153.16.17.224/30       encap       0x00000001
  packets/bytes      24/1174
153.16.17.228/30       encap       0x00000001
  packets/bytes      32/1546
153.16.18.16/28        fwd native  0x00000000
  packets/bytes      56/2576
153.16.18.32/28        encap       0x00000001
  packets/bytes    2322/143949
153.16.18.64/28        encap       0x00000001
  packets/bytes     176/12465
153.16.18.80/28        encap       0x00000001
Prefix                 Fwd action  Locator status bits
  packets/bytes     178/11838
153.16.18.96/28        encap       0x00000001
  packets/bytes     183/8854
153.16.18.112/28       fwd native  0x00000000
  packets/bytes     446/20902
153.16.18.144/28       fwd native  0x00000000
  packets/bytes      15/690
153.16.18.176/28       encap       0x00000001
  packets/bytes      88/4795
153.16.18.208/28       encap       0x00000001
  packets/bytes      81/3866
153.16.18.224/28       fwd native  0x00000000
  packets/bytes       0/0
153.16.18.240/28       encap       0x00000001
  packets/bytes     103/6929
153.16.19.0/24         fwd native  0x00000000
  packets/bytes   21137/1141575
153.16.20.0/24         fwd native  0x00000000
  packets/bytes   23187/1275992
153.16.21.0/26         fwd native  0x00000000
  packets/bytes   35021/2276591
153.16.21.109/32       drop        0x00000000
  packets/bytes       0/0
153.16.21.139/32       fwd native  0x00000000
  packets/bytes     120/5760
153.16.21.141/32       fwd native  0x00000000
  packets/bytes      18/828
153.16.21.210/31       fwd native  0x00000000
  packets/bytes       0/0
153.16.22.0/26         fwd native  0x00000000
  packets/bytes   37084/2255311
153.16.22.90/32        drop        0x00000000
  packets/bytes       0/0
153.16.22.132/32       encap       0x00000003
  packets/bytes       0/0
153.16.22.136/29       fwd native  0x00000000
  packets/bytes       0/0
153.16.22.196/32       fwd native  0x00000000
  packets/bytes     116/5800
Prefix                 Fwd action  Locator status bits
153.16.22.200/29       fwd native  0x00000000
  packets/bytes       0/0
153.16.22.212/30       fwd native  0x00000000
  packets/bytes       0/0
153.16.22.216/29       fwd native  0x00000000
  packets/bytes     232/11136
153.16.22.224/27       fwd native  0x00000000
  packets/bytes    1406/80696
153.16.23.0/24         fwd native  0x00000000
  packets/bytes  131048/6980525
153.16.24.0/24         encap       0x00000001
  packets/bytes    2080/128076
153.16.25.0/28         encap       0x00000001
  packets/bytes     347/16626
153.16.25.16/28        encap       0x00000003
  packets/bytes   15523/14385604
153.16.25.32/28        fwd native  0x00000000
  packets/bytes     438/20380
153.16.25.48/28        encap       0x00000001
  packets/bytes     184/9141
153.16.25.64/28        fwd native  0x00000000
  packets/bytes     727/34886
153.16.25.112/28       fwd native  0x00000000
  packets/bytes     592/27580
153.16.25.128/28       encap       0x00000001
  packets/bytes     112/9970
153.16.25.151/32       drop        0x00000000
  packets/bytes       0/0
153.16.25.160/28       encap       0x00000001
  packets/bytes     112/8094
153.16.25.176/28       drop        0x00000001
  packets/bytes       8/368
153.16.25.192/28       encap       0x00000001
  packets/bytes      85/4104
153.16.25.224/28       encap       0x00000003
  packets/bytes    1403/756413
153.16.25.240/28       fwd native  0x00000000
  packets/bytes       0/0
153.16.26.0/28         encap       0x00000001
Prefix                 Fwd action  Locator status bits
  packets/bytes   24055/21546260
153.16.26.32/28        encap       0x00000001
  packets/bytes     206/10582
153.16.26.64/28        fwd native  0x00000000
  packets/bytes    1115/56171
153.16.26.80/28        fwd native  0x00000000
  packets/bytes    1695/80454
153.16.26.96/28        fwd native  0x00000000
  packets/bytes     474/22384
153.16.26.112/28       fwd native  0x00000000
  packets/bytes    1651/78716
153.16.26.128/28       fwd native  0x00000000
  packets/bytes       0/0
153.16.26.192/28       encap       0x00000001
  packets/bytes   12171/1390825
153.16.26.224/28       encap       0x00000001
  packets/bytes      97/5257
153.16.26.240/28       fwd native  0x00000000
  packets/bytes       0/0
153.16.27.0/24         fwd native  0x00000000
  packets/bytes    5744/375960
153.16.28.0/24         encap       0x00000001
  packets/bytes    2452/149787
153.16.29.0/24         encap       0x00000003
  packets/bytes    2423/136233
153.16.30.0/28         encap       0x00000003
  packets/bytes    2452/152600
153.16.30.16/28        fwd native  0x00000000
  packets/bytes    1884/99928
153.16.30.32/27        fwd native  0x00000000
  packets/bytes   18978/1075973
153.16.30.64/26        fwd native  0x00000000
  packets/bytes   36633/1900388
153.16.30.128/25       fwd native  0x00000000
  packets/bytes   26905/1452450
153.16.31.0/28         fwd native  0x00000000
  packets/bytes   11114/725274
153.16.31.32/27        fwd native  0x00000000
  packets/bytes   17526/1129516
Prefix                 Fwd action  Locator status bits
153.16.31.64/26        fwd native  0x00000000
  packets/bytes   33377/1795877
153.16.31.128/25       fwd native  0x00000000
  packets/bytes   32391/2164113
153.16.32.0/28         encap       0x00000001
  packets/bytes     282/13483
153.16.32.16/28        fwd native  0x00000000
  packets/bytes     517/23782
153.16.32.48/28        fwd native  0x00000000
  packets/bytes    1217/58912
153.16.32.64/28        fwd native  0x00000000
  packets/bytes    1956/275832
153.16.32.80/28        encap       0x00000003
  packets/bytes     162/7914
153.16.32.96/28        encap       0x00000003
  packets/bytes     206/9995
153.16.32.112/28       fwd native  0x00000000
  packets/bytes    2917/170863
153.16.32.144/28       fwd native  0x00000000
  packets/bytes     150/6900
153.16.32.176/28       encap       0x00000001
  packets/bytes     411/48905
153.16.32.192/28       encap       0x00000001
  packets/bytes   62747/54741368
153.16.32.208/28       fwd native  0x00000000
  packets/bytes    1103/157110
153.16.32.224/28       encap       0x0000000F
  packets/bytes    9478/934907
153.16.32.240/28       encap       0x00000001
  packets/bytes     201/13637
153.16.33.0/24         fwd native  0x00000000
  packets/bytes  125808/7498118
153.16.34.0/24         fwd native  0x00000000
  packets/bytes   20005/1211708
153.16.35.0/24         fwd native  0x00000000
  packets/bytes   28219/1661540
153.16.36.0/24         encap       0x0000000F
  packets/bytes    2403/135041
153.16.37.0/24         encap       0x00000007
Prefix                 Fwd action  Locator status bits
  packets/bytes     487/131776
153.16.38.0/25         encap       0x0000000A
  packets/bytes    4907/360740
153.16.38.128/25       encap       0x0000000A
  packets/bytes     749/44847
153.16.39.0/24         signal      0x00000000
  packets/bytes    2205/120184
153.16.40.0/24         fwd native  0x00000000
  packets/bytes  100232/5787525
153.16.41.0/24         encap       0x00000003
  packets/bytes    4757/264737
153.16.43.16/28        fwd native  0x00000000
  packets/bytes      83/3818
153.16.43.32/28        fwd native  0x00000000
  packets/bytes     455/21510
153.16.43.64/26        fwd native  0x00000000
  packets/bytes   40930/2405239
153.16.43.128/26       fwd native  0x00000000
  packets/bytes    7186/509900
153.16.43.192/27       fwd native  0x00000000
  packets/bytes     409/19286
153.16.43.224/28       fwd native  0x00000000
  packets/bytes     174/8352
153.16.43.241/32       encap       0x00000001
  packets/bytes       5/232
153.16.43.242/32       encap       0x00000001
  packets/bytes       1/48
153.16.44.0/28         fwd native  0x00000000
  packets/bytes    1584/78965
153.16.44.16/28        fwd native  0x00000000
  packets/bytes     290/13920
153.16.44.32/28        encap       0x00000003
  packets/bytes     137/7376
153.16.44.48/28        encap       0x00000001
  packets/bytes    6429/493372
153.16.44.64/28        encap       0x00000001
  packets/bytes     218/13336
153.16.44.80/28        fwd native  0x00000000
  packets/bytes     462/21870
Prefix                 Fwd action  Locator status bits
153.16.44.96/28        encap       0x00000001
  packets/bytes     230/16736
153.16.44.128/28       fwd native  0x00000000
  packets/bytes     232/11136
153.16.44.144/28       encap       0x00000001
  packets/bytes   10028/461440
153.16.44.160/28       encap       0x00000001
  packets/bytes      81/3912
153.16.44.176/28       fwd native  0x00000000
  packets/bytes       0/0
153.16.44.192/28       encap       0x00000001
  packets/bytes      63/3008
153.16.44.208/28       encap       0x00000003
  packets/bytes      73/3655
153.16.45.0/24         fwd native  0x00000000
  packets/bytes   14189/971315
153.16.46.0/24         fwd native  0x00000000
  packets/bytes   17446/1122565
153.16.47.0/28         fwd native  0x00000000
  packets/bytes     513/25414
153.16.47.16/28        encap       0x00000001
  packets/bytes     152/7558
153.16.47.32/28        fwd native  0x00000000
  packets/bytes     228/10488
153.16.47.48/28        fwd native  0x00000000
  packets/bytes      84/3864
153.16.47.64/28        fwd native  0x00000000
  packets/bytes     519/23874
153.16.47.96/28        fwd native  0x00000000
  packets/bytes    1462/70032
153.16.47.128/28       fwd native  0x00000000
  packets/bytes     477/22290
153.16.47.160/27       encap       0x00000001
  packets/bytes     150/7376
153.16.47.208/28       encap       0x00000001
  packets/bytes      90/6744
153.16.47.224/28       encap       0x00000001
  packets/bytes     726/496246
153.16.47.240/28       fwd native  0x00000000
Prefix                 Fwd action  Locator status bits
  packets/bytes     125/6000
153.16.48.0/28         encap       0x00000001
  packets/bytes    9822/787514
153.16.48.16/28        fwd native  0x00000000
  packets/bytes    1166/54548
153.16.48.32/28        encap       0x00000001
  packets/bytes    2419/1368023
153.16.48.64/26        fwd native  0x00000000
  packets/bytes   30536/1951066
153.16.48.128/25       fwd native  0x00000000
  packets/bytes   27251/1791407
153.16.49.0/24         fwd native  0x00000000
  packets/bytes   89806/5103369
153.16.50.0/23         fwd native  0x00000000
  packets/bytes  187276/10548451
153.16.52.0/22         fwd native  0x00000000
  packets/bytes  416440/23021471
153.16.56.0/21         fwd native  0x00000000
  packets/bytes  791716/45648478
153.16.64.0/24         encap       0x00000003
  packets/bytes   19959/25775078
153.16.65.0/32         drop        0x00000000
  packets/bytes       2/120
153.16.65.7/32         drop        0x00000000
  packets/bytes       0/0
153.16.65.15/32        drop        0x00000000
  packets/bytes       0/0
153.16.66.7/32         drop        0x00000000
  packets/bytes       0/0
153.16.66.16/28        fwd native  0x00000000
  packets/bytes       0/0
153.16.66.32/28        fwd native  0x00000000
  packets/bytes       0/0
153.16.66.64/28        encap       0x00000001
  packets/bytes     216/12095
153.16.66.80/28        encap       0x00000001
  packets/bytes     143/7048
153.16.66.192/28       encap       0x00000001
  packets/bytes     136/13397
Prefix                 Fwd action  Locator status bits
153.16.66.208/28       encap       0x00000001
  packets/bytes     106/5148
153.16.66.224/28       encap       0x00000001
  packets/bytes      95/4496
153.16.67.0/24         encap       0x00000003
  packets/bytes    2420/145387
153.16.68.165/32       drop        0x00000000
  packets/bytes       0/0
153.16.68.181/32       drop        0x00000000
  packets/bytes       0/0
153.16.69.62/32        drop        0x00000000
  packets/bytes       0/0
153.16.69.93/32        drop        0x00000000
  packets/bytes       0/0
153.16.69.188/32       drop        0x00000000
  packets/bytes       0/0
153.16.70.0/28         encap       0x00000003
  packets/bytes     210/11243
153.16.70.16/29        encap       0x00000002
  packets/bytes      75/3600
153.16.70.24/29        encap       0x00000002
  packets/bytes      48/2386
153.16.70.41/32        drop        0x00000000
  packets/bytes       0/0
153.16.70.64/28        encap       0x00000001
  packets/bytes    5671/891042
153.16.70.80/28        encap       0x00000001
  packets/bytes     193/9490
153.16.70.96/28        encap       0x00000001
  packets/bytes     165/9175
153.16.70.112/28       encap       0x00000001
  packets/bytes     192/9474
153.16.70.128/25       fwd native  0x00000000
  packets/bytes   34977/1919726
153.16.71.0/24         fwd native  0x00000000
  packets/bytes  113426/6058747
153.16.72.4/32         drop        0x00000000
  packets/bytes       0/0
153.16.73.0/24         fwd native  0x00000000
Prefix                 Fwd action  Locator status bits
  packets/bytes   96304/5184251
153.16.74.0/24         encap       0x00000001
  packets/bytes    2200/127117
153.16.75.0/24         fwd native  0x00000000
  packets/bytes  100121/5766560
153.16.76.0/22         fwd native  0x00000000
  packets/bytes  426560/24941173
153.16.80.0/20         fwd native  0x00000000
  packets/bytes  227475/14382760
153.16.96.0/19         fwd native  0x00000000
  packets/bytes 3275775/184546349
153.16.128.0/19        fwd native  0x00000000
  packets/bytes 3434964/196842926
153.16.160.0/19        fwd native  0x00000000
  packets/bytes 4070673/229418687
153.16.192.0/18        fwd native  0x00000000
  packets/bytes 7177127/405113420

On 22.01.2013, at 11:22, Damien Saucez <[email-masked]<mailto:[email-masked]>> wrote:

On 22 Jan 2013, at 10:15, Luigi Iannone <[email-masked]<mailto:[email-masked]>> wrote:

Hi All,

Damien Saucez

ciao

Luigi

On 22 Jan. 2013, at 04:15 , Dino Farinacci <[email-masked]<mailto:[email-masked]>> wrote:

Dino

On Jan 21, 2013, at 6:05 PM, Ronald Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Dino,

                                          Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
Dino Farinacci
Sent: Monday, January 21, 2013 5:51 PM
To: Noel Chiappa
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; lisp-
[email-masked]<mailto:[email-masked]>
Subject: Re: [lisp] Should we use Locator-Status-Bits in Internet
deployment?

Dino

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp

---

From: Dimitris Kalogeras <[email-masked]>
Date: Wed, 23 Jan 2013 12:29:44 +0200

> about deployment, so operators can only do what implementations allow

I agree with Lori, I assume that this bit carries different meanings
whether there is an "hot" association
with another instance or some "cold" association, where "hot" and "cold
" could have relevant meanings when used in standby
scenarios

--Dimitris

-- 
Dimitrios K. Kalogeras

Electrical Engineer Ph.D.
Network Engineer
NTUA/GR-Net Network Management Center
_____________________________________
skype: aweboy
voice: +30-210-772 1863
fax:   +30-210-772 1866
e-mail: [email-masked]

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 23 Jan 2013 16:35:41 +0000

Hi Dino,

Sorry to be slow, but this is one of those cases where a complete expansion might be called for:

1) On the public Internet, we shouldn't trust the LSB at all. If an ITR detects any transition (0-to-1 or 1-to-0), verify it with the mapping system.

2) In a controlled Environment, we can trust the LSB
2a) If the ITR detects a transition from 1-to-0, we should believe it. There is no need to verify. In fact, if we did check with the mapping system, we might find that the mapping system still reports the bit as 1. This is because, as you say below, LSB "are good in control[ed] environments to take ETRs out of service without having to update the mapping database."
2b) If the ITR detects a transition from 0-to-1, we should believe it. There is no need to verify. But if we did verify, it would be more likely that the mapping system would report the same thing.

Also, in the bullet points above, I am not quite sure what the definition of a "controlled environment" is. Am I correct in assuming that an environment is "controlled" if it satisfies both of the following requirements:

-controlled from a security perspective. Bad guys cannot spoof LISP control information on the data plane.
-controlled from a routing perspective. ETRs are aware of each others' status (and, therefore, can report on each others' status) because the participate in a common IGP.

                                  Ron

> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Monday, January 21, 2013 10:15 PM
> To: Ronald Bonica
> Cc: Noel Chiappa; [email-masked]; [email-masked]; lisp-
> [email-masked]
> > But isn't it troubling that the bits have one meaning in a controlled
> environment and another in the great-wide Internet?
> >
> >                                            Ron
> >
> >
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Dino Farinacci
> >>> think it was a combination of the fixed number of bits, the fact
> >>> that it might be difficult for ETR X to know the state of ETR Y,
> the
> >>> fact that 'reachable from ITR A' [which you _really_ need to have
> >>> anyway] is a subset of 'up', etc, etc. But we didn't desperately
> >>> need the header bits, and the mechanism wasn't positively harmful,
> >>> so I didn't bother to put up a big fight over it... :-)
> >>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 23 Jan 2013 17:54:14 +0100

Ron,

Sorry to be repeating myself...

> 1) On the public Internet, we shouldn't trust the LSB at all. If an ITR detects any transition (0-to-1 or 1-to-0), verify it with the mapping system.

... verify it out of band or externally (through the mapping system
being one approach).

---

From: Eliot Lear <[email-masked]>
Date: Wed, 23 Jan 2013 19:33:49 +0100

> ... verify it out of band or externally (through the mapping system

Oh and s/ITR/ETR/ right?

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 23 Jan 2013 21:37:04 -0800

> 1) On the public Internet, we shouldn't trust the LSB at all. If an ITR detects any transition (0-to-1 or 1-to-0), verify it with the mapping system.

Yes, the LSBs are hints and can be trusted, if chosen to, or with paranoia tested to be in sync or the truth. There is a control-plane/security/fast-convergence tradeoff.

> 2a) If the ITR detects a transition from 1-to-0, we should believe it. There is no need to verify. In fact, if we did check with the mapping system, we might find that the mapping system still repo…

The mapping system transports the Map-Request and the devices which advertise the LSBs are the ones that report their status of them via a returned Map-Reply. And as I said in a previous email, the Map-Reply can be signed.

You get more validation *from the mapping system* because the two parties (Map-Requestor and Map-Replier) have a shared trusted anchor point. That is the Map-Server(s) the ETR is registering with.

> 2b) If the ITR detects a transition from 0-to-1, we should believe it. There is no need to verify. But if we did verify, it would be more likely that the mapping system would report the same thing.

If the LSB transition to either state, it should be verified. The only point where I can relate to what you are saying is to "route away" to the 1-to-0 transition. And to not "route to new" when the 0-to-1 transition has not been verified. But this could be splitting hairs.

> Also, in the bullet points above, I am not quite sure what the definition of a "controlled environment" is. Am I correct in assuming that an environment is "controlled" if it satisfies both of the…

Controlled means trusted. For instance, a leaf/top-of-rack router in a data center who is encapsulating to another leaf router in the same data center or another one controlled and managed by the same organizational entity.

> -controlled from a routing perspective. ETRs are aware of each others' status (and, therefore, can report on each others' status) because the participate in a common IGP.

I believe solely on trust.

Dino