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

["Georgios Karagiannis" <[e-mail]>]

Hi Robert 

Thank you very much!
Regarding points 2 and 3., see below:

>> 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?

What I mean, is:
 'is 1 up and 0 down or the other way round'?

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

Could you please give an example?

Best Regards,
Georgios

----- Original Message ----- 
From: "Hancock, Robert" <[e-mail]>
To: "Georgios Karagiannis" <[e-mail]>nl>; <[e-mail]>
Sent: Tuesday, April 26, 2005 12:47 PM
Subject: RE: [Nsis-imp] some clarification questions regarding GIMPS


> 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