Subject: RE: [NSIS] new draft "GIST over SCTP" and some comments to GIST

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 17 Oct 2005 22:47:11 +0100

hi xiaoming,

some more discussion:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Xiaoming Fu
> Sent: 17 October 2005 09:40
> To: Hancock, Robert; [email-masked]
> Subject: Re: [NSIS] new draft "GIST over SCTP" and some 
> comments to GIST
> 
> 
> Hancock, Robert wrote:
> > 
> > (non-trivial)
> > 3.3: i didn't really understand this section. multi-homing
> > (or any multi-interface) issues have their impact in D mode
> > only (in fact, query mode messages and NLI payloads), which
> > are unchanged; the linkage to MAs is done by cookie matching,
> > which is also unchanged. so I don't see why the fact that the
> > MA can use a multi-homing transport protocol should make any
> > difference.
> 
> I think there might be two issues here:
> - only two end hosts are multihoming. This can have impact on how the 
> MRIs are maintained, using which IP info in MRM of query messages and 
> how to update the MRIs when a primary IP is changed from one 
> to another.

these are all multihoming issues, but i don't see what they have
to do with the use of SCTP as a transport. note that multihoming
for user data is not really visible to GIST (GIST sees this as
several independent flows; it is up to the signalling applications
to realise they are related to a single session). so you if you
have several MRIs they are handled independently, and each MRI
is handled quite deterministically.

> - two neighboring GIST peers are multihoming. This may be 
> related to how 
> to represent multiple IP address pairs in the MA entry (or just the 
> "node identifier" of its peer), in connection with SCTP 
> association/chunk relationship.

true, but (if you want to) this is already the case even with TCP
as a transport for the messaging associations. the way that routing
state is bound to messaging associations causes a new association
to be set up for each address pair (this is a consequence of the
state matching rules), BUT if nodes can determine that they are
peering over multiple associations they can use a single one and
discard the rest. 

it may be that more text could be written (probably implementation
guidance) about how this can be done. but i would not tie together
the facts that multiple address pairs for routing state are relevant 
between multi-interface nodes and that SCTP can support multiple
address pairs. indeed, even in the non-multi-homed case, the IP
peer addresses used in the routing state do not need to be closely
tied to the IP addresses used by the transport layer protocol for
the messaging association (they are tied together by cookie 
matching, not address matching). so i certainly would not try to
bind the two together in the multi-homed case.

cheers,

r.

> Xiaoming
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Xiaoming Fu <[email-masked]>
Date: Tue, 18 Oct 2005 23:25:49 +0200

robert,

thanks for your further comments. my comments inline:
> is handled quite deterministically.

i think this is viable way.
> peering over multiple associations they can use a single one and

in the case of sctp, it is clear a given gist pair can have up to one 
sctp association, per rfc2960.
> bind the two together in the multi-homed case.
maybe i am a bit puzzled here - yes a cookie requires to be repeated in 
the query-response, but the problem here is a mrs is required to 
identify the right identities of its upstream and downstream peer. which 
identify should be relied on? in the current world likely will still be 
ip address i guess.
xiaoming