=?GB2312?B?u9i4tDpSZTogu9i4tDpSZTogW3JicmlkZ2VdIFF1ZXN0aW9uIA==?= =?GB2312?B?YWJvdXQgdGhlIGZ1dHVyZSB3b3JrIDE6IFRyaWxsIG92ZXIgSVA=?=

[Erik Nordmark]

On 11/ 8/10 02:34 AM, xuxiaohu 41208 wrote:

>> TRILL is based on the nicknames being assigned randomly and then
>> checkedfor duplicates using IS-IS. That doesn't match how IP
>> addresses are
>> normally assigned.
>>
>> Even if you somehow modify how the IP addresses would be assigned to
>> match TRILL's expectations, you'd still need a way to carry other
>> information that is in the TRILL header. For example, the
>> multi-destination bit is a key part which affects how RBridges forward
>> frames.
> 
> Can't the class D IP addresses and the PIM protocol fill the multicast function that trill does?
> 
> Anything else which is important to trill?

I think you are talking about a protocol which isn't TRILL.

What was discussed in the future work presentation was how to carry
TRILL over what could be viewed as a (virtual) port that uses IP
encapsulation, analogous to how TRILL is carried over Ethernet or PPP.
Nothing in that would change the approved draft-ietf-trill-rbridge-protocol.

What you seem to be talking about is a different protocol that
draft-ietf-trill-rbridge-protocol which does not use nicknames or many
of the other TRILL concepts.

Given that the working group as well as the IESG approved
draft-ietf-trill-rbridge-protocol, such a change seems completely out of
scope.

As I think Donald has pointed out earlier, the WG did discuss different
forms of encapsulation in the early days of the WG, and settled on the
TRILL header (and related concepts).

Regards,
   Erik