[rbridge] Proposed compromise for short/long hellos

[mike shand]

Radia,
    Re-reading draft-ietf-trill-rbridge-protocol-12, isn't the 
combination of adjacency hellos and protection hellos essentially the 
same as what I proposed below? So why are you proposing that it should 
be reversed to have non-padded IS-IS hellos (which would also have to 
have the IS-IS rules changed with respect to not using only UP 
adjacencies and still electing even when there are no other adjacencies) 
and (optional?) MTU discovery hellos, which interact in some yet to be 
completely specified way with the adjacency formation rules. Why is that 
better than what seems to be the natural approach of keeping the IS-IS 
stuff unchanged and adding something which has the required TRILL 
semantics for the identification of  the forwarders. It seems to have 
traded two hellos, one of which was identical to the existing IS-IS 
mechanisms, for two hellos, neither of which are the same as IS-IS.

    Mike



Radia.Perlman at sun.com wrote:
> Mike Shand said:
>
>     So would it make more sense to leave the hellos, adjacency
> establishment rules, DIS election exactly as it is for IS-IS and use
> THAT for the IS-IS related stuff like generating pseudonodes, running
> the LAN reliable update process and advertising connectivity, and then
> have a new small TRILL hello which behaved the way you described and use
> that for electing the DRB from the point of view of determining who does
> the forwarding?
>
>     Mike
>
> ****************************************
>
> I don't think so. It's basically the same thing, with some different rules.
> If we did the TRILL Hellos and DRB election, we wouldn't need the other
> one also. So I think we should just modify the rules for TRILL.
>
> It's possible we should even rewrite the spec for exactly how TRILL IS-IS should work.
> There isn't any other IETF protocol that doesn't get updated every few years with new versions.
>
> Radia
>
>
>