RE: [Nsis-imp] some clarification questions regarding GIMPS

["Hancock, Robert" <[e-mail]>]

hi georgios,

thanks for the questions! see in line...

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[e-mail]] 
> Sent: 26 April 2005 10:44
> To: [e-mail]
> Subject: [Nsis-imp] some clarification questions regarding GIMPS
> 
> 
> Dear all
> 
> We at the moment implementing the GIMPS protocol and we find 
> that there are some issues
> that would need some clarification, etc.
> 
> These issues are:
> 
> 1- For the implementation of the discovery mechanism,it is 
> important to know 
> if a procedure has to be implemented to check whether the 
> sender of the 
> Query cookie is also the sender of the confirm cookie.

this is a hard question. the ideal answer is 'yes' but, given
that the purpose of the 3 way handshake is supposed to allow 
the responding node to forget the query contents and work only
with the confirm, it is not clear to me at the moment that it
is possible in general, unless the responder cookie is designed
to refer to information that will be repeated in the confirm.
(we have started this discussion at 
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue17)

we need to do more work on this, and i have text lying around,
but still need to make it comprehensible (and plausible).

> 
> 2- The value of the D-flag that corresponds to the upstream and 
> downstream has to be specified.

do you just mean 'is 1 up and 0 down or the other way round'?
or something more subtle?

> 
> 3- The function of the source prefix and destination prefix of the 
> MRI object has to be defined.

this is to allow wildcarding on address fields. the signalling message
delivery uses the actual addresses, but the MRI is interpreted as
referring to the whole subnet (e.g. might be used by an NSLP as a
wildcard in a traffic classifier). GIMPS should reject 'too broad'
wildcards (in a manner to be defined in the next version of the
draft).

> 
> 4- In our implementation we are only using IP-Ver 4. 
> Therefore it might be 
> useful to know if the entire 32 bit word for the Flow Label 
> parameter in the 
> MRI object must be ignored or set to zero (empty object).

wrong on both counts (see
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue34
which we wrote during the interoperability testing
in minneapolis). the short answer is:
if the flag for a field in set in the first word, the field must
be present and interpreted as significant
otherwise, the field must not be present at all.

(this is supposed to be implied by the ':' symbols in the box
notation indicating 'optional fields' but I accept it is a bit
hard to spot and the next version will be more explicit.)

at the moment my expectation is not to try to pin down exactly
which version/flag combinations must be supported, but to 
rely on common sense (e.g. people won't generate MRIs with v=4
and F set) and defining a general purpose ICMP-like 'parameter 
problem' message to allow people to report that they don't like
particular settings. i'd appreciate input on that, however.

hope this helps,

r.
> 
> Could you clarify the above?
> 
> Best regards,
> Georgios
> 

_______________________________________________
NSIS-imp mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis-imp