Re: [trill] Thoughts on active-active edge

[Mingui Zhang <[e-mail]>]

Hi Thomas,

The whole problem is how to provide end-nodes (end-stations or LAGs) with a mechanism of active-active access into the TRILL campus. The baseline requirement for this mechanism is that traffic duplication or loops MUST be avoided. However, as the mechanism is being developed, new problems appear. I'd like to list those problems as follows. 

1.	RPFC issue. 
The CMT draft addresses this issue. 

2.	Nickname configuration
It is necessary to denote the active-active edge group with a virtual RBridge, say RBv. The member RBridges act as the agents of the nickname allocation for RBv and they MUST act in consistence.

As defined in RFC6325, pseudonode nickname is actually allocated by the DRB. DRB is elected through exchanging HELLOs. The LAG or end-station is not a LAN anymore. As a result, no HELLOs can be exchanged on it. No HELLO no DRB. So, a new pseudonode nickname allocation method is needed.

3.	MAC sharing 
The MAC addressed learnt by one member RB should be synchronized up with other RBs in the same group. Or else, if a frame destined to such a MAC is via other RBs, it will cause unnecessary unknown unicast.

4.	Failure recovery
When a member RBridge or link fails, how does the whole active-active edge group response? A method is needed here to automate that process. 

I am OK with the idea to compose a problem statement draft. However, IMO, it is impossible to provide _one_ solution draft to solve all these problems.

Thanks,
Mingui



>-----Original Message-----
>From: Thomas Narten [mailto:[e-mail]]
>Sent: Thursday, December 13, 2012 6:58 AM
>To: Sam Aldrin
>Cc: Mingui Zhang; Tissa Senevirathne (tsenevir); Radia Perlman; [e-mail]
>Subject: Re: [trill] Thoughts on active-active edge
>
>
>Sam Aldrin <[e-mail]> writes:
>
>> On Dec 12, 2012, at 12:25 PM, Thomas Narten <[e-mail]> wrote:
>
>> >> I believe we have discussed these scenarios (different solution
>> >> types) previously.  WG should reach consensus and move forward with
>> >> the agreed solution.  Atleast from the IETF WG sessions, I presumed
>> >> there was a consensus on the solution.  Am I wrong in that
>> >> assumption?
>> >
>> > what "solution" are you referring above as maybe having consensus?
>
>> Cmt draft
>
>If you mean draft-ietf-trill-cmt-01.txt, I at least am not in
>agreement.
>
>I have several issues with the document.
>
>For starters, it's incomplete. It needs to be paired with another
>document to get an actual "standard" you can implement. We don't have
>such a companion document yet.  It's been suggested that
>draft-hu-trill-pseudonode-nickname-04.txt is one such document. But
>that document is not a WG document and I'm not sure what its status
>is. (And it needs work...)
>
>As a general rule (not TRILL specific) I don't like WGs doing "partial
>work" where they standardize one document, that is incomplete by
>itself, independent of other documents that are needed to produce a
>complete implementable solution to some real problem.
>
>I've raised issues on the list about CMT and its unclarity
>wrt. LAG/MC-LAG, etc. I did not really get my questions answered.
>
>What I'd really like to start with on CMT is a clear problem
>statement. I.e., exactly what problem/use case it is trying to
>solve. I have not been able to get that out of the two  documents.
>
>As for draft-hu-trill-pseudonode-nickname-04.txt, I have other
>concerns. E.g., it talks about tunneling at one point, but that is
>completely unspecified.
>
>What I don't want to do is spend a lot of time on the *solution*
>details. I first want a clear problem statement/use case. Without
>that, it is difficult to assess how well potential solutions address
>the stated problem.
>
>Thomas
>