Re: [trill] A tweak to option 2, if it's hard to upgrade VL guys to FGL-safe

[[e-mail]]

As FGL frames and VL frames have different Ethertype, it is easy for 
FGL-safe RBridges to differentiate the two types of frames in data plane. 
And the tweaked Option 2 allows VL-RBridges exiting at the edge of a 
nework with FGL links if their FGL-safe neighbors can differentiate the 
two type frames, I am happy with it.

So, I support this tweaked option.


Best Regards,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 
 Zhai Hongjun
 
 Tel: [phone]
 Email: [e-mail]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""





Radia Perlman <[e-mail]> 
发件人:  [e-mail]
2013-02-01 05:47

收件人
"Tissa Senevirathne (tsenevir)" <[e-mail]>
抄送
Anoop Ghanwani <[e-mail]>, Ayan Banerjee 
<[e-mail]>, Sam Aldrin <[e-mail]>, "[e-mail]" 
<[e-mail]>, Donald Eastlake <[e-mail]>, Jon Hudson 
<[e-mail]>
主题
[trill] A tweak to option 2,    if it's hard to upgrade VL guys to 
FGL-safe






The other thread was getting a bit long, so I'm changing the subject line, 
since here I'm proposing a tweak to option 2 that will make it less 
restrictive.  To review, option 2 as originally proposed had this 
property:
 
>>With option 2, a VL guy cannot even be at the edge of a network with FGL 
links unless it is upgraded to 
>>FGL-safe AND advertises that it is FGL-safe.  Option 2 says a VL guy is 
completely ostrasized once 
>>FGL-labeled links are introduced.  There is NO coexistence of VL guys 
and FGL-guys once FGL-links are
 >>advertised. 
 
Here is the proposed tweak:
 
An FGL-safe guy has two choices of what to do with a VL neighbor (once FGL 
links are advertised)
 
a) ostrasize the VL neighbor completely (as was in option 2)
b) advertise a very high cost to the VL neighbor AND ALSO discard any FGL 
frames that would be forwarded to that VL neighbor.
 
If an FGL-safe guy is capable of differentiating between FGL and VL 
frames...forwarding VL but discarding FGL to a VL neighbor, then this 
would allow VL guys to be at the edge and successfully talk across an FGL 
core.
 
If an FGL-safe guy is not capable of differentiating between FGL and VL 
frames, then the VL guy will be ostrasized.
 
As for transit...if a VL guy is in the core, its FGL neighbors will report 
such high costs to it that if there is any FGL path, that will be the one 
that is chosen, and if there isn't, then you're no worse off than if the 
VL guy were completely ostrasized....it will look like there is a path, 
but FGL packets will be lost on the path.
 
And of course, you shouldn't have the VL guy be the root of a multicast 
tree, since link costs to it won't avoid it being on the path between FGL 
guys.
 
Radia
 
 _______________________________________________
trill mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/trill