Subject: RE: draft response #6,8 Multiple controllers/redundancy

From: [email-masked]
Date: Sun, 15 Aug 1999 21:42:43 +0300

I think the difference between 6 and 8 is that one had to do with 
support for active control channels while 8 has to do with allowing 
switch hardware redundancy, and all that may entail.

I agree that Req #6 (multiple active VSCEs becomes somewhat more 
tractable if Req #5 were to be satisfied.  But I still think that there 
would be issues with #6 alone.

> -----Original Message-----
> From: EXT Joachim Buerkle [mailto:[email-masked]]
> Sent: 14 August, 1999 6:27 PM
> To: [email-masked]; [email-masked]
> Subject: Re: draft of draft-ietf-gsmp-msf-response-00.txt
> 

> 
> >>Requirement #6:        
> It shall be possible for the VSCEs 
> that make up a VSC to run
> on physically separate platforms and to access the VS over 
> separate physical paths
> (links).

> >>GSMPv3 compliance:     
> NS. requirement believed not to be 
> satisfied. There is
> currently no support for redundant controllers in [3]. In 
> order to fulfill this
> requirement proposals are needed.
> 
> Please compare with the GSMP WG answer for Requirement 8# (see below).
> Q: Are there really other issues beside a new adjacency?
> St: In my view the function for the switchover (between VSCs 
> or VSCEs) should not
> make further additions to the SCI at least in the case where:
> - the second VSC or VSCE is running as hot-standby and
> - the VSCs or VSCEs are running in parallel because of 
> loadsharing etc.
> (The second case is not supported by the GSMP but in my view 
> this has no impact to
> this requirement, since as soon the 
> multiple-VSCEs-to-one-VS-relationship is
> supported by GSMP this requirement is supported also)

I think your second point is the crux of the issue.  GSMP does not
currently have any mechanism for allowing multiple controller 
adjacencies to be established with the same partition.  This would 
require changes to the protocol.

Further, while the MSF requirements do not call for it, there is some 
sentiment among GSMP folk that such a setup would require more then just 
changes to the adjacency protocol.  There is a concern many of us have 
that allowing such a mechanism without putting in safeguards against 
misbehaving controllers (e.g. controllers which disagree, backup 
controllers that take over before their time, primary controllers that 
don't relinquish control ...) would be risky.  

I think this is an area where some contributions that work out the 
issues are required before we will to make changes which allow support 
for this.  

What I have said so far, however, refers more to Req #5 then to #6.  
However, #6 would probably involve further complications in establishing 
multiple adjacencies, as well as complications dealing with the 
introduction of control distributed among several control channels.

In fact, I will admit that I have trouble separating the issues with 
Req #5, from the issues involved in Req #6.

> 
> 
> >>Requirement 8#:        
> The SCI shall not restrict the 
> switch redundancy scheme and
> must allow for m:n hardware level redundancy in the switch 
> (e.g., Card level
> redundancy, other component level switching, APS on interfaces).

> >>GSMPv3 compliance:     
> PS/E. requirement believed to be 
> partially satisfied. There
> are no mechanisms in GSMPv3, which restrict hardware level 
> redundancy.  There are
> also no mechanisms, which support such redundancy.  This 
> requirement needs further
> clarification in order to understand whether such a passive 
> lack of restrictions
> meets the requirement.
> 
-----------------------------------
avri doria
+1 617 678 9402