From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 25-JUN-1993 11:45:03.97 To: EVERHART CC: Subj: DECnet IV/V migration issues - a rebuttal Date: Thu, 24 Jun 1993 18:40:36 -0700 From: Arun Sastry Message-Id: <199306250140.AA29838@regal.cisco.com> To: knibbe@cisco.com, agt@cisco.com, gkunis@cisco.com, dkatz@cisco.com Cc: afeather@cisco.com, dickey@cisco.com, williams_b@snd01.pcr.co.uk, Info-VAX@kl.sri.COM, KEDDIE@sndsu1.sinet.slb.com, larmer@nstg.enet.dec.com Subject: DECnet IV/V migration issues - a rebuttal Phase IV/V conversion and migration =================================== This is with regard to the talk I gave at DECUS in Atlanta two weeks ago on DECnet IV/V issues. It has come to my attention that some people have been having major concerns about cisco's implementation of the IV/V conversion algorithm. There seems to be a perception that cisco does not follow the algorithm that is specified in DEC's PhaseV architecture and is somehow 'different'. This might be because I did not emphasize the fact that our algorithms adhere to the specifications (as outlined in DEC's Phase V architecture) and I focussed more on the differences between the two philosophies. The differences between the two vendors' approaches has to do with WHEN the conversion is done. A DEC router running Phase V will always convert Phase IV packets to Phase V i.e. conversion occurs as soon as possible. With this scheme, a packet from a Phase IV host bound for another Phase IV host will undergo two conversions if it encounters a Phase V router - from IV to V, then through the V cloud, and then back to IV when it exits the V cloud. This is what I referred to as the "integrated" approach. Cisco routers on the other hand follow the "Ships-in-the-night" approach. With this scheme, a packet will be forwarded in its native format for as long as possible, and will get converted only when there is no forwarding information in the native format. In this case, a cisco router will convert the packet and send it on if a route exists. The advantage of this scheme is that we can avoid conversion in some cases. The other issue has to do with the way a cisco router with conversion enabled deals with adjacencies. When a cisco router hears a IV hello, it creates an Phase IV adjacency and also converts the address to Phase V and stores it in its Phase V data base. Similarly, a Phase V hello is converted to Phase IV (if it is Phase-IV compatible) and stored in the Phase IV data base. On the other hand, a DEC router running Phase V will convert a Phase IV hello and store it in its Phase V data base. There is no duplication of end-system information in a DEC router. I also spoke about the fact that DEC architecture specifies that an area must be either Phase IV or V, while cisco's allows you to have both IV and V in some (or all) routers. The advantage of this scheme is that there is no need to convert the entire backbone to Phase V, and so allows a more gradual migration strategy. I then spoke about a new feature that we were coming out with in the next software release. This had to do with being able to propagate Phase IV area information through a Phase V cloud. Currently, reachability to remote Phase IV *AREAS* is not "redistributed" through OSI, so that IV nodes on one side of the cloud will not hear about other Phase IV areas hanging off of the router at the other end. The scheme I outlined was a static one, since Phase IV areas that needed to be advertised had to be statically entered. This was a first step in overcoming this limitation. In connection with this, I also mentioned that a more elegant scheme would be to have a dynamic IV/V route redistribution. It is important to note here that what this capability gives you is to be able to advertise ADDITIONAL Phase IV AREAS across the cloud; we have always been able to propagate level-1 reachability through a Phase V cloud. Let me reiterate again that the translation algorithms followed by both vendors' implementations are the same, and there should be no interoperability problems arising from this. I apologize if I did not present the facts more clearly and if I raised any red flags. Furthermore I apologize if I have misunderstood the concerns you were trying to raise, and if so, I will be happy to clarify them and put them to rest. Please send all mail to cs-decnet@cisco.com so that it will be seen by all the right people. Regards, - Arun Sastry Software Engineer cisco Systems 1525 O'Brien Drive Menlo Park, CA 94025