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

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

hi georgios,

answers below:

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[e-mail]] 
> Sent: 28 April 2005 09:29
> To: Hancock, Robert; [e-mail]
> Subject: Re: [Nsis-imp] some clarification questions regarding GIMPS
> 
> 
> 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'?

the D=direction flag is:
if clear: in the same direction as the flow
if set: in the opposite direction to the flow

for example, a Query would normally have D=0 and the 
Response D=1.

i've given myself an editorial issue to make this clearer.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue42

> 
> > 
> >> 
> >> 3- The function of the source prefix and destination prefix of the 
> >> MRI object has to be defined.
> 
> Could you please give an example?

this is a more interesting question, which will send me into 
discursive mode briefly:

the addresses in the MRI have a dual significance:
- they tell GIMPS how to encapsulate the Q/R/C messages (i.e. what
source and destination addresses to use for them) and hence 
implicitly define the path;
- they form part of the definition of which packets the signalling
is about (i.e. is used as part of the packet classifier).

For the second, sometimes a wildcard is appropriate (see e.g.
draft-bajko-nsis-FW-reqs-00.txt and the various protocol
specs). An example would be a IPv6 'leaf network' with a /64
address range allocated (like a cellular host) which wanted to
signal something about all its addresses (e.g. it might be using
privacy addresses) without carrying out multiple signalling
exchanges. For this reason, you can apply a prefix length to the
addresses to implement this wildcarding.

To take a concrete example of a single GIMPS data message
  MRI(IPversion = 4,
	Flow source = 123.231.112.45,
	Flow destination = 56.78.90.12,
	Source prefix length = 24,
	Destination prefix length = 32,
	Direction = 0 [downstream])

The message will go along the path between 123.231.112.45 and
56.78.90.12 (and a Query message would use precisely those addresses
in its IP header), but will refer to packets from anywhere in 
123.231.112.0/24 to 56.78.90.12.

It's possible for wildcarding to be too wild (e.g. setting a
prefix length to 0). If the prefix length is too short for the
path (i.e. it includes addresses for which the packets would
go along different paths), it's up to GIMPS to reject the
message. I am working on the error messages at the moment ;-)

Hope this helps,

Robert H.

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