z**r
发帖数: 17771 | |
w*f
发帖数: 111 | |
R*****A
发帖数: 127 | 3 LISP头一回听说，idea不错。
有了这个，internet routing table可以shrink一下。
对ISP来说，又多了一个dabase需要维护（LISP mapping database), 加上routing
table, DNS database. 可以考虑将RR 设计成三个database的集成。
PE直接将L2的整个打包成IP, ASIC设计上可以让其更快？有点意思，，， |
p*****s
发帖数: 344 | 4 学习了。粗看起来感觉上又是通过加头的方法。等于是说现在开始为了解决问题从新分
配IP |
j*a
发帖数: 14423 | 5 这就像个nat
mpls感觉倒是挺完整一体系解决方案
【在 p*****s 的大作中提到】
: 学习了。粗看起来感觉上又是通过加头的方法。等于是说现在开始为了解决问题从新分
: 配IP
|
s******v
发帖数: 4495 | 6 router在lookup EID找到LOCATOR,这个可行吗？岂不是把routing table放到一个
centralized地方，通过udp/tcp在lookup？
【在 z**r 的大作中提到】
: lisp.cisco.com
|
z**r
发帖数: 17771 | 7 ISP其实可以完全透明，因为LIST ITR/ETR等等都是可以放在CPE上的
【在 R*****A 的大作中提到】
: LISP头一回听说，idea不错。
: 有了这个，internet routing table可以shrink一下。
: 对ISP来说，又多了一个dabase需要维护（LISP mapping database), 加上routing
: table, DNS database. 可以考虑将RR 设计成三个database的集成。
: PE直接将L2的整个打包成IP, ASIC设计上可以让其更快？有点意思，，，
|
z**r
发帖数: 17771 | 8 不加头不行啊，Internet只认IP
【在 p*****s 的大作中提到】
: 学习了。粗看起来感觉上又是通过加头的方法。等于是说现在开始为了解决问题从新分
: 配IP
|
z**r
发帖数: 17771 | 9 跟NAT没有可比性吧，无论从可维护性，可扩展性，网络结构以及灵活性，都不是一个
档次的
【在 j*a 的大作中提到】
: 这就像个nat
: mpls感觉倒是挺完整一体系解决方案
|
j*a
发帖数: 14423 | 10 那像不像tacacs
【在 z**r 的大作中提到】
: 跟NAT没有可比性吧，无论从可维护性，可扩展性，网络结构以及灵活性，都不是一个
: 档次的
|
|
|
z**r
发帖数: 17771 | 11 这个可以有redendancy，比如一个anycast就轻松解决了，加上本身也可以提供。整个
MAP-SERVER/REGISTRITION这一套，和DNS非常相似，DNS的可扩展性应该已经证明没有
问题了。LOOKUP是通过UDP倒是没错
【在 s******v 的大作中提到】
: router在lookup EID找到LOCATOR,这个可行吗？岂不是把routing table放到一个
: centralized地方，通过udp/tcp在lookup？
|
z**r
发帖数: 17771 | 12 有可比性？
【在 j*a 的大作中提到】
: 那像不像tacacs
|
j*a
发帖数: 14423 | 13 有那么一丁点儿
【在 z**r 的大作中提到】
: 有可比性？
|
w***s
发帖数: 321 | 14 第一反应就是MPLS VPN再投胎。
1. IP Based L3VPN，已经在用
2. 只有一个VPN，所以不需要真正建立Tunnel
3. Tunnel END查询和H.323 Gatekeeper原理一致
剩下的问题在于解析这部分，没有cache，每个包都查一边受不了吧，如果有cache，PE上就有全路由了，如果是CE去做会
好点。
搞这东西的老大们说明应用场景了么？
【在 z**r 的大作中提到】
: lisp.cisco.com
|
s*****g
发帖数: 1055 | 15 The way I understand LISP:
1. Data plane is more like moving MPLS to customer edge. Today service
provider can have BGP free core by transport IP over MPLS, while LISP
extended this "tunneling" to customer's edge router without customer running MPLS, service provider can still run existing MPLS network or they can have a pure IP core but its routers don't need full internet table. LISP
encapsulation has more overhead than MPLS. However, you can not transport IP/MPLS across multiple SPs (maybe you can with the help of BGP, but that capability is mostly for inter-AS/CsC, it won't be scale for internet routing, I am sure, somebody can shed some light here?), while LISP does not care, so this is a big plus for LISP.
2. Control plane is very much like DNS, (it is more like DNS than H323 gatekeeper in the sense that there is really no admission control involved) what I don't fully understand is DNS record change can take hours to propagate, while internet routing will not tolerate any where near that level of convergence time. With today's IP routing architecture any route change can be propagated by BGP in seconds, and the route change will immediately trigger routers' FIB program change. Would LISP's control plane converge as fast as BGP?
PE上就有全路由了，如果是CE去做会
【在 w***s 的大作中提到】
: 第一反应就是MPLS VPN再投胎。
: 1. IP Based L3VPN，已经在用
: 2. 只有一个VPN，所以不需要真正建立Tunnel
: 3. Tunnel END查询和H.323 Gatekeeper原理一致
: 剩下的问题在于解析这部分，没有cache，每个包都查一边受不了吧，如果有cache，PE上就有全路由了，如果是CE去做会
: 好点。
: 搞这东西的老大们说明应用场景了么？
|
w***s
发帖数: 321 | 16 其实说MPLS VPN也误导了，就是标准的MPLS + BGP结构，一样的BGP free Core效果，
只是用IPinIP模式，MPLS就可以省了。但是在MPLS方案里面PE还是有全路由，所以LISP
最重要的就是Map－Request功能。
之所以说这个更象H323查询过程，而不是DNS，原因有两个：
1. 系统里面已经有DNS，再搞一个会混淆
2. DNS没有做EID-RLOC转换，还是EID的不同表达方式，而从电话号码到Gateway的映射
更类似于EID-RLOC的关系，Admission Control就不是重点了，不过加上这功能也不错
，实际上在MAP Server上是可以实现一定级别的路由策略的。
最后的问题就是Tunnel End Router选取，取PE，就恢复到原始的MPLS＋BGP方案，MAP
Cache的规模多少近似于全路由。CE会好的多，毕竟一个site的用户不会访问整个
Internet，当然DC除外。如果允许有Default RLOC的话，整个方案看起来很不错。
running MPLS, service provider can still run existing MPLS network or they
can have a pure IP core but its routers don't need full internet table. LISP
IP/MPLS across multiple SPs (maybe you can with the help of BGP, but that
capability is mostly for inter-AS/CsC, it won't be scale for internet
routing, I am sure, somebody can shed some light here?), while LISP does not
care, so this is a big plus for LISP.
gatekeeper in the sense that there is really no admission control involved)
what I don't fully understand is DNS record change can take hours to
propagate, while internet routing will not tolerate any where near that
level of convergence time. With today's IP routing architecture any route
change can be propagated by BGP in seconds, and the route change will
immediately trigger routers' FIB program change. Would LISP's cont: rol
plane converge as fast as BGP?
【在 s*****g 的大作中提到】
: The way I understand LISP:
: 1. Data plane is more like moving MPLS to customer edge. Today service
: provider can have BGP free core by transport IP over MPLS, while LISP
: extended this "tunneling" to customer's edge router without customer running MPLS, service provider can still run existing MPLS network or they can have a pure IP core but its routers don't need full internet table. LISP
: encapsulation has more overhead than MPLS. However, you can not transport IP/MPLS across multiple SPs (maybe you can with the help of BGP, but that capability is mostly for inter-AS/CsC, it won't be scale for internet routing, I am sure, somebody can shed some light here?), while LISP does not care, so this is a big plus for LISP.
: 2. Control plane is very much like DNS, (it is more like DNS than H323 gatekeeper in the sense that there is really no admission control involved) what I don't fully understand is DNS record change can take hours to propagate, while internet routing will not tolerate any where near that level of convergence time. With today's IP routing architecture any route change can be propagated by BGP in seconds, and the route change will immediately trigger routers' FIB program change. Would LISP's control plane converge as fast as BGP?
:
: PE上就有全路由了，如果是CE去做会
|
z**r
发帖数: 17771 | 17 I agree with you on the second point. for the first point, if you call any
addtional header MPLS like, you could, but I would say the biggest advantage
of LISP is dynamic tunnel from CPE to CPE
running MPLS, service provider can still run existing MPLS network or they
can have a pure IP core but its routers don't need full internet table. LISP
IP/MPLS across multiple SPs (maybe you can with the help of BGP, but that
capability is mostly for inter-AS/CsC, it won't be scale for internet
routing, I am sure, somebody can
gatekeeper in the sense that there is really no admission control involved)
what I don't fully understand is DNS record change can take hours to
propagate, while internet routing
【在 s*****g 的大作中提到】
: The way I understand LISP:
: 1. Data plane is more like moving MPLS to customer edge. Today service
: provider can have BGP free core by transport IP over MPLS, while LISP
: extended this "tunneling" to customer's edge router without customer running MPLS, service provider can still run existing MPLS network or they can have a pure IP core but its routers don't need full internet table. LISP
: encapsulation has more overhead than MPLS. However, you can not transport IP/MPLS across multiple SPs (maybe you can with the help of BGP, but that capability is mostly for inter-AS/CsC, it won't be scale for internet routing, I am sure, somebody can shed some light here?), while LISP does not care, so this is a big plus for LISP.
: 2. Control plane is very much like DNS, (it is more like DNS than H323 gatekeeper in the sense that there is really no admission control involved) what I don't fully understand is DNS record change can take hours to propagate, while internet routing will not tolerate any where near that level of convergence time. With today's IP routing architecture any route change can be propagated by BGP in seconds, and the route change will immediately trigger routers' FIB program change. Would LISP's control plane converge as fast as BGP?
:
: PE上就有全路由了，如果是CE去做会
|
z**r
发帖数: 17771 | 18 LISP老大明确说了这个查询是类似DNS。
LISP
MAP
【在 w***s 的大作中提到】
: 其实说MPLS VPN也误导了，就是标准的MPLS + BGP结构，一样的BGP free Core效果，
: 只是用IPinIP模式，MPLS就可以省了。但是在MPLS方案里面PE还是有全路由，所以LISP
: 最重要的就是Map－Request功能。
: 之所以说这个更象H323查询过程，而不是DNS，原因有两个：
: 1. 系统里面已经有DNS，再搞一个会混淆
: 2. DNS没有做EID-RLOC转换，还是EID的不同表达方式，而从电话号码到Gateway的映射
: 更类似于EID-RLOC的关系，Admission Control就不是重点了，不过加上这功能也不错
: ，实际上在MAP Server上是可以实现一定级别的路由策略的。
: 最后的问题就是Tunnel End Router选取，取PE，就恢复到原始的MPLS＋BGP方案，MAP
: Cache的规模多少近似于全路由。CE会好的多，毕竟一个site的用户不会访问整个
|
s*****g
发帖数: 1055 | 19 LDP signaled LSP can be considered as dynamic tunnel too ...
All in all, there is nothing new under the sun. Openflow/SDN is an exception.
advantage
LISP
)
【在 z**r 的大作中提到】
: I agree with you on the second point. for the first point, if you call any
: addtional header MPLS like, you could, but I would say the biggest advantage
: of LISP is dynamic tunnel from CPE to CPE
:
: running MPLS, service provider can still run existing MPLS network or they
: can have a pure IP core but its routers don't need full internet table. LISP
: IP/MPLS across multiple SPs (maybe you can with the help of BGP, but that
: capability is mostly for inter-AS/CsC, it won't be scale for internet
: routing, I am sure, somebody can
: gatekeeper in the sense that there is really no admission control involved)
|
p*****s
发帖数: 344 | 20 今天看到个一年前的ppt说，C-公司在狂推，现在情况怎样？ |
|
|
w***s
发帖数: 321 | 21 感觉比MPLS要好，不需要在Core起额外的协议，没有了MPLS最让人厌恶的Label的本地
有效性，也没有了不可聚合路由的要求。不过这东西在IPv6普世之后还有更广泛的应用
么？
advantage
LISP
)
【在 z**r 的大作中提到】
: I agree with you on the second point. for the first point, if you call any
: addtional header MPLS like, you could, but I would say the biggest advantage
: of LISP is dynamic tunnel from CPE to CPE
:
: running MPLS, service provider can still run existing MPLS network or they
: can have a pure IP core but its routers don't need full internet table. LISP
: IP/MPLS across multiple SPs (maybe you can with the help of BGP, but that
: capability is mostly for inter-AS/CsC, it won't be scale for internet
: routing, I am sure, somebody can
: gatekeeper in the sense that there is really no admission control involved)
|
z**r
发帖数: 17771 | 22 这个就是在ipv6 ipv4混合的时候最有用，可以无缝连接v4 v6网络。如果都dual stack
了，也就没必要用这个了
【在 w***s 的大作中提到】
: 感觉比MPLS要好，不需要在Core起额外的协议，没有了MPLS最让人厌恶的Label的本地
: 有效性，也没有了不可聚合路由的要求。不过这东西在IPv6普世之后还有更广泛的应用
: 么？
:
: advantage
: LISP
: )
|
s*****g
发帖数: 1055 | 23 KAO, why did those words come from? "无缝连接", "不可聚合路由", "普世"
Don't get me wrong, those words sound very NB.
stack
【在 z**r 的大作中提到】
: 这个就是在ipv6 ipv4混合的时候最有用，可以无缝连接v4 v6网络。如果都dual stack
: 了，也就没必要用这个了
|
z**r
发帖数: 17771 | 24 无缝 - seamless, lol
普世 - pussy
不可聚合路由 - non agregatable routes
【在 s*****g 的大作中提到】
: KAO, why did those words come from? "无缝连接", "不可聚合路由", "普世"
: Don't get me wrong, those words sound very NB.
:
: stack
|
s*****g
发帖数: 1055 | 25 ZAN 普世 - pussy, are you sure about your 无缝 definition? :-)
【在 z**r 的大作中提到】
: 无缝 - seamless, lol
: 普世 - pussy
: 不可聚合路由 - non agregatable routes
|
z**r
发帖数: 17771 | 26 听着很毛啊
【在 s*****g 的大作中提到】
: ZAN 普世 - pussy, are you sure about your 无缝 definition? :-)
|
he
发帖数: 2025 | 27 你俩的讨论"激情"四射
【在 z**r 的大作中提到】
: 听着很毛啊
|
z**r
发帖数: 17771 | 28 然后被语音专家现场录音？
【在 he 的大作中提到】
: 你俩的讨论"激情"四射
|
v**n
发帖数: 951 | 29 不是特别看好，关键不是protocol本身，这个map server想做大做好不容易。。。
【在 z**r 的大作中提到】
: lisp.cisco.com
|
z**r
发帖数: 17771 | 30 多大算大？现阶段scale到10K很轻松，还是用ISR G2做，要是用ASR1K或者更高端的做
，更轻松
【在 v**n 的大作中提到】
: 不是特别看好，关键不是protocol本身，这个map server想做大做好不容易。。。
|
|
|
s******v
发帖数: 4495 | 31 这个够呛，改CPE是个非常艰巨而且不可能的任务，要是光应用在green-field，那要等
到猴年马月啊？
我的理解就是，ce/pe看到一个新的destination，然后通过udp lookup locator，然后
加个报头，等于是直接tunnel到destination。
工作量是一样的，只是把1）workload分到CE上一部分，2）local lookup变成lookup
over udp 3)整个routing table从分布在每个PE上，变成集中式
【在 z**r 的大作中提到】
: ISP其实可以完全透明，因为LIST ITR/ETR等等都是可以放在CPE上的
|
z**r
发帖数: 17771 | |
w*f
发帖数: 111 | |
R*****A
发帖数: 127 | 34 LISP头一回听说，idea不错。
有了这个，internet routing table可以shrink一下。
对ISP来说，又多了一个dabase需要维护（LISP mapping database), 加上routing
table, DNS database. 可以考虑将RR 设计成三个database的集成。
PE直接将L2的整个打包成IP, ASIC设计上可以让其更快？有点意思，，， |
p*****s
发帖数: 344 | 35 学习了。粗看起来感觉上又是通过加头的方法。等于是说现在开始为了解决问题从新分
配IP |
j*a
发帖数: 14423 | 36 这就像个nat
mpls感觉倒是挺完整一体系解决方案
【在 p*****s 的大作中提到】
: 学习了。粗看起来感觉上又是通过加头的方法。等于是说现在开始为了解决问题从新分
: 配IP
|
s******v
发帖数: 4495 | 37 router在lookup EID找到LOCATOR,这个可行吗？岂不是把routing table放到一个
centralized地方，通过udp/tcp在lookup？
【在 z**r 的大作中提到】
: lisp.cisco.com
|
z**r
发帖数: 17771 | 38 ISP其实可以完全透明，因为LIST ITR/ETR等等都是可以放在CPE上的
【在 R*****A 的大作中提到】
: LISP头一回听说，idea不错。
: 有了这个，internet routing table可以shrink一下。
: 对ISP来说，又多了一个dabase需要维护（LISP mapping database), 加上routing
: table, DNS database. 可以考虑将RR 设计成三个database的集成。
: PE直接将L2的整个打包成IP, ASIC设计上可以让其更快？有点意思，，，
|
z**r
发帖数: 17771 | 39 不加头不行啊，Internet只认IP
【在 p*****s 的大作中提到】
: 学习了。粗看起来感觉上又是通过加头的方法。等于是说现在开始为了解决问题从新分
: 配IP
|
z**r
发帖数: 17771 | 40 跟NAT没有可比性吧，无论从可维护性，可扩展性，网络结构以及灵活性，都不是一个
档次的
【在 j*a 的大作中提到】
: 这就像个nat
: mpls感觉倒是挺完整一体系解决方案
|
|
|
j*a
发帖数: 14423 | 41 那像不像tacacs
【在 z**r 的大作中提到】
: 跟NAT没有可比性吧，无论从可维护性，可扩展性，网络结构以及灵活性，都不是一个
: 档次的
|
z**r
发帖数: 17771 | 42 这个可以有redendancy，比如一个anycast就轻松解决了，加上本身也可以提供。整个
MAP-SERVER/REGISTRITION这一套，和DNS非常相似，DNS的可扩展性应该已经证明没有
问题了。LOOKUP是通过UDP倒是没错
【在 s******v 的大作中提到】
: router在lookup EID找到LOCATOR,这个可行吗？岂不是把routing table放到一个
: centralized地方，通过udp/tcp在lookup？
|
z**r
发帖数: 17771 | 43 有可比性？
【在 j*a 的大作中提到】
: 那像不像tacacs
|
j*a
发帖数: 14423 | 44 有那么一丁点儿
【在 z**r 的大作中提到】
: 有可比性？
|
w***s
发帖数: 321 | 45 第一反应就是MPLS VPN再投胎。
1. IP Based L3VPN，已经在用
2. 只有一个VPN，所以不需要真正建立Tunnel
3. Tunnel END查询和H.323 Gatekeeper原理一致
剩下的问题在于解析这部分，没有cache，每个包都查一边受不了吧，如果有cache，PE上就有全路由了，如果是CE去做会
好点。
搞这东西的老大们说明应用场景了么？
【在 z**r 的大作中提到】
: lisp.cisco.com
|
s*****g
发帖数: 1055 | 46 The way I understand LISP:
1. Data plane is more like moving MPLS to customer edge. Today service
provider can have BGP free core by transport IP over MPLS, while LISP
extended this "tunneling" to customer's edge router without customer running MPLS, service provider can still run existing MPLS network or they can have a pure IP core but its routers don't need full internet table. LISP
encapsulation has more overhead than MPLS. However, you can not transport IP/MPLS across multiple SPs (maybe you can with the help of BGP, but that capability is mostly for inter-AS/CsC, it won't be scale for internet routing, I am sure, somebody can shed some light here?), while LISP does not care, so this is a big plus for LISP.
2. Control plane is very much like DNS, (it is more like DNS than H323 gatekeeper in the sense that there is really no admission control involved) what I don't fully understand is DNS record change can take hours to propagate, while internet routing will not tolerate any where near that level of convergence time. With today's IP routing architecture any route change can be propagated by BGP in seconds, and the route change will immediately trigger routers' FIB program change. Would LISP's control plane converge as fast as BGP?
PE上就有全路由了，如果是CE去做会
【在 w***s 的大作中提到】
: 第一反应就是MPLS VPN再投胎。
: 1. IP Based L3VPN，已经在用
: 2. 只有一个VPN，所以不需要真正建立Tunnel
: 3. Tunnel END查询和H.323 Gatekeeper原理一致
: 剩下的问题在于解析这部分，没有cache，每个包都查一边受不了吧，如果有cache，PE上就有全路由了，如果是CE去做会
: 好点。
: 搞这东西的老大们说明应用场景了么？
|
w***s
发帖数: 321 | 47 其实说MPLS VPN也误导了，就是标准的MPLS + BGP结构，一样的BGP free Core效果，
只是用IPinIP模式，MPLS就可以省了。但是在MPLS方案里面PE还是有全路由，所以LISP
最重要的就是Map－Request功能。
之所以说这个更象H323查询过程，而不是DNS，原因有两个：
1. 系统里面已经有DNS，再搞一个会混淆
2. DNS没有做EID-RLOC转换，还是EID的不同表达方式，而从电话号码到Gateway的映射
更类似于EID-RLOC的关系，Admission Control就不是重点了，不过加上这功能也不错
，实际上在MAP Server上是可以实现一定级别的路由策略的。
最后的问题就是Tunnel End Router选取，取PE，就恢复到原始的MPLS＋BGP方案，MAP
Cache的规模多少近似于全路由。CE会好的多，毕竟一个site的用户不会访问整个
Internet，当然DC除外。如果允许有Default RLOC的话，整个方案看起来很不错。
running MPLS, service provider can still run existing MPLS network or they
can have a pure IP core but its routers don't need full internet table. LISP
IP/MPLS across multiple SPs (maybe you can with the help of BGP, but that
capability is mostly for inter-AS/CsC, it won't be scale for internet
routing, I am sure, somebody can shed some light here?), while LISP does not
care, so this is a big plus for LISP.
gatekeeper in the sense that there is really no admission control involved)
what I don't fully understand is DNS record change can take hours to
propagate, while internet routing will not tolerate any where near that
level of convergence time. With today's IP routing architecture any route
change can be propagated by BGP in seconds, and the route change will
immediately trigger routers' FIB program change. Would LISP's cont: rol
plane converge as fast as BGP?
【在 s*****g 的大作中提到】
: The way I understand LISP:
: 1. Data plane is more like moving MPLS to customer edge. Today service
: provider can have BGP free core by transport IP over MPLS, while LISP
: extended this "tunneling" to customer's edge router without customer running MPLS, service provider can still run existing MPLS network or they can have a pure IP core but its routers don't need full internet table. LISP
: encapsulation has more overhead than MPLS. However, you can not transport IP/MPLS across multiple SPs (maybe you can with the help of BGP, but that capability is mostly for inter-AS/CsC, it won't be scale for internet routing, I am sure, somebody can shed some light here?), while LISP does not care, so this is a big plus for LISP.
: 2. Control plane is very much like DNS, (it is more like DNS than H323 gatekeeper in the sense that there is really no admission control involved) what I don't fully understand is DNS record change can take hours to propagate, while internet routing will not tolerate any where near that level of convergence time. With today's IP routing architecture any route change can be propagated by BGP in seconds, and the route change will immediately trigger routers' FIB program change. Would LISP's control plane converge as fast as BGP?
:
: PE上就有全路由了，如果是CE去做会
|
z**r
发帖数: 17771 | 48 I agree with you on the second point. for the first point, if you call any
addtional header MPLS like, you could, but I would say the biggest advantage
of LISP is dynamic tunnel from CPE to CPE
running MPLS, service provider can still run existing MPLS network or they
can have a pure IP core but its routers don't need full internet table. LISP
IP/MPLS across multiple SPs (maybe you can with the help of BGP, but that
capability is mostly for inter-AS/CsC, it won't be scale for internet
routing, I am sure, somebody can
gatekeeper in the sense that there is really no admission control involved)
what I don't fully understand is DNS record change can take hours to
propagate, while internet routing
【在 s*****g 的大作中提到】
: The way I understand LISP:
: 1. Data plane is more like moving MPLS to customer edge. Today service
: provider can have BGP free core by transport IP over MPLS, while LISP
: extended this "tunneling" to customer's edge router without customer running MPLS, service provider can still run existing MPLS network or they can have a pure IP core but its routers don't need full internet table. LISP
: encapsulation has more overhead than MPLS. However, you can not transport IP/MPLS across multiple SPs (maybe you can with the help of BGP, but that capability is mostly for inter-AS/CsC, it won't be scale for internet routing, I am sure, somebody can shed some light here?), while LISP does not care, so this is a big plus for LISP.
: 2. Control plane is very much like DNS, (it is more like DNS than H323 gatekeeper in the sense that there is really no admission control involved) what I don't fully understand is DNS record change can take hours to propagate, while internet routing will not tolerate any where near that level of convergence time. With today's IP routing architecture any route change can be propagated by BGP in seconds, and the route change will immediately trigger routers' FIB program change. Would LISP's control plane converge as fast as BGP?
:
: PE上就有全路由了，如果是CE去做会
|
z**r
发帖数: 17771 | 49 LISP老大明确说了这个查询是类似DNS。
LISP
MAP
【在 w***s 的大作中提到】
: 其实说MPLS VPN也误导了，就是标准的MPLS + BGP结构，一样的BGP free Core效果，
: 只是用IPinIP模式，MPLS就可以省了。但是在MPLS方案里面PE还是有全路由，所以LISP
: 最重要的就是Map－Request功能。
: 之所以说这个更象H323查询过程，而不是DNS，原因有两个：
: 1. 系统里面已经有DNS，再搞一个会混淆
: 2. DNS没有做EID-RLOC转换，还是EID的不同表达方式，而从电话号码到Gateway的映射
: 更类似于EID-RLOC的关系，Admission Control就不是重点了，不过加上这功能也不错
: ，实际上在MAP Server上是可以实现一定级别的路由策略的。
: 最后的问题就是Tunnel End Router选取，取PE，就恢复到原始的MPLS＋BGP方案，MAP
: Cache的规模多少近似于全路由。CE会好的多，毕竟一个site的用户不会访问整个
|
s*****g
发帖数: 1055 | 50 LDP signaled LSP can be considered as dynamic tunnel too ...
All in all, there is nothing new under the sun. Openflow/SDN is an exception.
advantage
LISP
)
【在 z**r 的大作中提到】
: I agree with you on the second point. for the first point, if you call any
: addtional header MPLS like, you could, but I would say the biggest advantage
: of LISP is dynamic tunnel from CPE to CPE
:
: running MPLS, service provider can still run existing MPLS network or they
: can have a pure IP core but its routers don't need full internet table. LISP
: IP/MPLS across multiple SPs (maybe you can with the help of BGP, but that
: capability is mostly for inter-AS/CsC, it won't be scale for internet
: routing, I am sure, somebody can
: gatekeeper in the sense that there is really no admission control involved)
|
|
|
p*****s
发帖数: 344 | 51 今天看到个一年前的ppt说，C-公司在狂推，现在情况怎样？ |
w***s
发帖数: 321 | 52 感觉比MPLS要好，不需要在Core起额外的协议，没有了MPLS最让人厌恶的Label的本地
有效性，也没有了不可聚合路由的要求。不过这东西在IPv6普世之后还有更广泛的应用
么？
advantage
LISP
)
【在 z**r 的大作中提到】
: I agree with you on the second point. for the first point, if you call any
: addtional header MPLS like, you could, but I would say the biggest advantage
: of LISP is dynamic tunnel from CPE to CPE
:
: running MPLS, service provider can still run existing MPLS network or they
: can have a pure IP core but its routers don't need full internet table. LISP
: IP/MPLS across multiple SPs (maybe you can with the help of BGP, but that
: capability is mostly for inter-AS/CsC, it won't be scale for internet
: routing, I am sure, somebody can
: gatekeeper in the sense that there is really no admission control involved)
|
z**r
发帖数: 17771 | 53 这个就是在ipv6 ipv4混合的时候最有用，可以无缝连接v4 v6网络。如果都dual stack
了，也就没必要用这个了
【在 w***s 的大作中提到】
: 感觉比MPLS要好，不需要在Core起额外的协议，没有了MPLS最让人厌恶的Label的本地
: 有效性，也没有了不可聚合路由的要求。不过这东西在IPv6普世之后还有更广泛的应用
: 么？
:
: advantage
: LISP
: )
|
s*****g
发帖数: 1055 | 54 KAO, why did those words come from? "无缝连接", "不可聚合路由", "普世"
Don't get me wrong, those words sound very NB.
stack
【在 z**r 的大作中提到】
: 这个就是在ipv6 ipv4混合的时候最有用，可以无缝连接v4 v6网络。如果都dual stack
: 了，也就没必要用这个了
|
z**r
发帖数: 17771 | 55 无缝 - seamless, lol
普世 - pussy
不可聚合路由 - non agregatable routes
【在 s*****g 的大作中提到】
: KAO, why did those words come from? "无缝连接", "不可聚合路由", "普世"
: Don't get me wrong, those words sound very NB.
:
: stack
|
s*****g
发帖数: 1055 | 56 ZAN 普世 - pussy, are you sure about your 无缝 definition? :-)
【在 z**r 的大作中提到】
: 无缝 - seamless, lol
: 普世 - pussy
: 不可聚合路由 - non agregatable routes
|
z**r
发帖数: 17771 | 57 听着很毛啊
【在 s*****g 的大作中提到】
: ZAN 普世 - pussy, are you sure about your 无缝 definition? :-)
|
he
发帖数: 2025 | 58 你俩的讨论"激情"四射
【在 z**r 的大作中提到】
: 听着很毛啊
|
z**r
发帖数: 17771 | 59 然后被语音专家现场录音？
【在 he 的大作中提到】
: 你俩的讨论"激情"四射
|
v**n
发帖数: 951 | 60 不是特别看好，关键不是protocol本身，这个map server想做大做好不容易。。。
【在 z**r 的大作中提到】
: lisp.cisco.com
|
|
|
z**r
发帖数: 17771 | 61 多大算大？现阶段scale到10K很轻松，还是用ISR G2做，要是用ASR1K或者更高端的做
，更轻松
【在 v**n 的大作中提到】
: 不是特别看好，关键不是protocol本身，这个map server想做大做好不容易。。。
|
s******v
发帖数: 4495 | 62 这个够呛，改CPE是个非常艰巨而且不可能的任务，要是光应用在green-field，那要等
到猴年马月啊？
我的理解就是，ce/pe看到一个新的destination，然后通过udp lookup locator，然后
加个报头，等于是直接tunnel到destination。
工作量是一样的，只是把1）workload分到CE上一部分，2）local lookup变成lookup
over udp 3)整个routing table从分布在每个PE上，变成集中式
【在 z**r 的大作中提到】
: ISP其实可以完全透明，因为LIST ITR/ETR等等都是可以放在CPE上的
|
v**n
发帖数: 951 | 63 10k TPS? 还是10k的ID/destinations pairs？
【在 z**r 的大作中提到】
: 多大算大？现阶段scale到10K很轻松，还是用ISR G2做，要是用ASR1K或者更高端的做
: ，更轻松
|
t*******r
发帖数: 3271 | 64 说得简洁明了, 顶~
【在 s******v 的大作中提到】
: 这个够呛，改CPE是个非常艰巨而且不可能的任务，要是光应用在green-field，那要等
: 到猴年马月啊？
: 我的理解就是，ce/pe看到一个新的destination，然后通过udp lookup locator，然后
: 加个报头，等于是直接tunnel到destination。
: 工作量是一样的，只是把1）workload分到CE上一部分，2）local lookup变成lookup
: over udp 3)整个routing table从分布在每个PE上，变成集中式
|
t*******r
发帖数: 3271 | 65 LISP有点扯了,LISP某种程度能实现节点和IP解耦合，但本质还是IPinIP，可作为部分
目的节点选择，但无法对中间链路进行选路处理，google早就自研BGP SERVER来实现目
的IDC的选择调度了。OP和MPLS TE要做的是中间链路只能调度 |
c*****e
发帖数: 3226 | 66 网络技术已经很难圈到钱了。没办法，吾等草民只能追逐泡泡，不知道下个是什么。
【在 z**r 的大作中提到】
: lisp.cisco.com
|
n*********a
发帖数: 1956 | 67 实际上就是个P2P的DNS equivalence。
所有的LISP-capable routers（一般是access routers，即end-hosts的uplink router
)知晓这个P2P的DNS equal协议。
在一个LISP router转发IP包时，destination end-host的IP是查表时用的key，查出来
的value是其当时对应的LISP router，IP包就转给该LISP router了。
Core network和end hosts都没什么改变，改的是一大圈access routers。 |
