d****i
发帖数: 1038 | 1 Can VC types in a VPLS different? Say in a single VPLS instance (a VFI in
cisco world), can some VC be type 4,
others be type 5? Is this allowed/disallowed by some RFC? |
s*****g
发帖数: 1055 | 2 One instance corresponds to one VC id, within the same VCid, circuit type
must match, if you are asking one peer, different VC type, then it is OK. |
d****i
发帖数: 1038 | 3 Let me use the cisco configuration as an example to elaborate my question:
if I have:
l2 vfi VFI man
vpn id 1111
neighbor 1.1.1.2 pw-class vc4
neighbor 1.1.1.3 pw-class vc5
pseudowire-class vc4
encap mpls
interworking vlan
pseudowire-class vc5
encap mpls
The pw class vc4 will ensure the VC to 1.1.1.2 type 4, while pw class vc5
will generally make VC to 1.1.1.3
type 5. Currently Cisco routers does not support the above configuration
because it does not support
interworking vlan for vpls yet, but if that is supported, does it violate
any RFC?
Thanks.
【在 s*****g 的大作中提到】
: One instance corresponds to one VC id, within the same VCid, circuit type
: must match, if you are asking one peer, different VC type, then it is OK.
|
s*****g
发帖数: 1055 | 4 RFC probably does not care about this situation, vendor should implement in
a way that if VC-type mis-matches, it will automatically adjust one side VC-
type in order to bring up the VC. |
d****i
发帖数: 1038 | 5 sure we can configure other PEs in a way that brings up VC, and we can
configure in the way one VC type 4,
one VC type 5 and both VCs are up. So it is not a violation to any RFC? It
will certainly add more complexity for
vendor's products though.
in
VC-
【在 s*****g 的大作中提到】
: RFC probably does not care about this situation, vendor should implement in
: a way that if VC-type mis-matches, it will automatically adjust one side VC-
: type in order to bring up the VC.
|
t*******r
发帖数: 3271 | 6 我觉得自适应会带来非技术性的其他问题.
自适应? 谁适应谁? 互不相让, 这不就打起来了嘛~~~
in
VC-
【在 s*****g 的大作中提到】
: RFC probably does not care about this situation, vendor should implement in
: a way that if VC-type mis-matches, it will automatically adjust one side VC-
: type in order to bring up the VC.
|
s*****g
发帖数: 1055 | 7 It is a very simple state machine.
【在 t*******r 的大作中提到】
: 我觉得自适应会带来非技术性的其他问题.
: 自适应? 谁适应谁? 互不相让, 这不就打起来了嘛~~~
:
: in
: VC-
|
d****i
发帖数: 1038 | 8 basically, if one end is 4 the other end is 5, both end will become 4. and
once in 4, it cannot become 5 again
to prevent pingpong.
【在 t*******r 的大作中提到】
: 我觉得自适应会带来非技术性的其他问题.
: 自适应? 谁适应谁? 互不相让, 这不就打起来了嘛~~~
:
: in
: VC-
|
d****i
发帖数: 1038 | 9 Is Junipor solution supporting vc 4 and 5 in the same vpls instance?
【在 t*******r 的大作中提到】
: 我觉得自适应会带来非技术性的其他问题.
: 自适应? 谁适应谁? 互不相让, 这不就打起来了嘛~~~
:
: in
: VC-
|
z**r
发帖数: 17771 | 10 I don't see why it cannot, but it'll depend on the vendor implementations ...
【在 d****i 的大作中提到】
: Can VC types in a VPLS different? Say in a single VPLS instance (a VFI in
: cisco world), can some VC be type 4,
: others be type 5? Is this allowed/disallowed by some RFC?
|
z**r
发帖数: 17771 | 11 agree
in
VC-
【在 s*****g 的大作中提到】
: RFC probably does not care about this situation, vendor should implement in
: a way that if VC-type mis-matches, it will automatically adjust one side VC-
: type in order to bring up the VC.
|
z**r
发帖数: 17771 | 12 negociate最起码的原则就是相互商量啊，得有个标准啊，就像OSPF/ISIS里谁做DR，谁
做BDR，STP里谁做root，10M/100M/1000M到底应该是多少，等等
【在 t*******r 的大作中提到】
: 我觉得自适应会带来非技术性的其他问题.
: 自适应? 谁适应谁? 互不相让, 这不就打起来了嘛~~~
:
: in
: VC-
|
