The IP Over NBMA (ION) Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] RE: I-D ACTION:draft-ietf-rolc-nhrp-08.txt
[David Horton writes:] > 1. Target address unclear > > Specifically for resolution requests which field contains > the protocol address of the station for which the NBMA address > is desired, i.e. the target? > In nhrp-07, it was the "Destination Protocol Address", however > I can now place 3 interpretations on the text as written. > (2) Destination Protocol Address is of the target, and that the > NHRP packet is routed all the way to that target (or the egress > router from the NBMA), and the target responds This is the correct interpretation. I will add clarifying text. > 2. Registering addresses in multiple LIS > > With multiple CIEs (protocol->NBMA mappings) being allowed in a single > registration packet, there is an ambiguity created where the device > exists on multiple subnets. These subnets may be served by different > NHS. So again the packet has to either be split or rejected. The Client sends 1 packet per subnet containing whatever it wants to register on that subnet. > I presume that the packet is still expected to be routed to the > NHS specified in the Destination Protocol Address in the common > mandatory part. Correct. One other possibility is to setup a vc to the NBMA address of the NHS on the given LIS/LAG directly and send the registration request that way. Ths last case may get somewhat sticky depending on how tightly you interact with routing if the NHS and NHC are on different LIS. > 3. Request ID reintroduced to Purge > > I am not sure if this was intentional, but I think it is a good thing > if this has the behaviour of allowing the client to match up purge > replys to purge requests it sent. Exactly correct. In fact, had you never read NHRPv4 you would not ask this question. I am trying to get NHRP ready for last call so I did not want to introduce reference to previous usage since its usage is clear in context but somewhat muddled if you are a history buff :-) > 4. Reuse of CIE for extensions > > Why not make the structures for the extensions :- > 3. responder address extension > 4. NHRP Forward Transit NHS Record Extension > 5. NHRP Reverse Transit NHS Record Extension > use the CIE structure instead of the abbreviated form. > There would need to be additions to the text saying that certain > fields, e.g. code, must be set to zero. > I think developers of both the client and servers would > appreciate not having to decode extra formats. Hmmm. I thought about that but decided I would let someone else suggest it since I was not sure what I thought about this. Consider it done. --JIm |
|