The IP Over NBMA (ION) Archive

["Brian Carpenter CERN-CN" <brian@dxcoms.cern.ch>]

Ion folks,

I thought it was worth forwarding some comments I had on
Grenville Armitage's two IDs that carry the ipatm name but
now seem relevant to ion. I've included his comments on my comments.

(1) on draft-ietf-ipatm-ipv6nd-02.txt, the overview of proposals
for IPv6 neighbour discovery over ATM:

>>1. I may have lost track, but has anybody analysed stateless
>>autoconf for ATM? I know it's out of scope of your draft,
>>but it came into my mind.

>I'm not aware of any analysis per se. Most discussion on
>this sort of topic veers towards config servers (a la LANE).

>>2. In section 2.2. you refer briefly to anycast. I am a bit
>>worried about this - the whole anycast area seems to be black
>>magic, and you may or may not be right about the choice of
>>encapsulation. I would be more at ease with a separate section
>>on anycast, even if its contents are "TBD"

>Interesting. I must admit I just plopped the anycast mention
>into section 2.2 because its encaps seemed orthogonal to the
>issue of how anycast would actually work. Now that you mention
>it, the doc does have a glaring omission in that there's no
>section discussing anycast address resolution. Ooops.

>How about if the encaps is left as-is, and a new section is
>created, marked TBD, that will cover the actual mechanism for
>constructing a forwarding path VC from an anycast IPv6 address?
>(the reason I think the encaps is probably safe is because
>the more complex encaps for multicast is due entirely to the
>possible existence of Multicast Servers causing packet reflections.
>This will not occur for anycast, since once the VC is established
>it's just unicast.)

>>Otherwise I think the document is a fine overview.

(2) on draft-armitage-ipatm-tn-00.txt, Grenville's specific
proposal:

>Brian,
>
>You raise a good point. Yes, we probably need some algorithm
>that results in the source defaulting back to hop-by-hop
>forwarding if a transient neighbour becomes unreachable.
>Will have to think about this one.
>
>cheers,
>gja

>>Grenville,
>>
>>I rather like the model in draft-armitage-ipatm-tn-00.txt
>>
>>One question on section 3.3 (NUD). You say that a Transient
>>Neighbour is indistiguishable from an on-LLG neighbour.
>>But if a Transient Neighbour becomes unreachable, surely
>>in that case the sending rules are a bit special: you have
>>to start sending via a router again, without re-starting ND.
>>Isn't that slightly different from the LLG case?
>>
>>   Brian

Regards,
	Brian Carpenter (CERN)  (brian@dxcoms.cern.ch)
			 voice +41 22 767 4967, fax +41 22 767 7155