[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [NSIS] new GIMPS version
Hi Takako,
The phrasing is sloppy (my fault).
Case 1 could better say "... the RAO is relevant to NSIS but
not the specific node, but the IP layer is unable to recognise
whether it needs to be passed to GIMPS for further processing
or whether the packet should be forwarded just like a normal
IP datagram."
(In this case, because the RAO is not relevant to the specific
node, the GIMPS processing is to do whatever should have
been done to a normal datagram. In some implementations,
GIMPS would not be invoked at all here.)
Case 2 is different because the RAO *is* associated with a set
of signaling applications, some of which are processed on the
node (but not this specific one).
Section 8.4 is also relevant here.
Hope this helps,
robert h.
> -----Original Message-----
> From: Takako Sanda [mailto:sanda.takako at jp.panasonic.com]
> Sent: 02 June 2004 08:35
> To: Hancock, Robert
> Cc: nsis at ietf.org
> Subject: Re: [NSIS] new GIMPS version
>
>
> Hi Robert,
>
> I have a question about section 4.2.4 (Bypass Forwarding).
>
> What is a difference between:
> 1. A downstream datagram mode message contains an RAO value associated
> with NSIS, and the IP layer is unable to determine whether
> to forward
> it.
> and
> 2. A downstream datagram mode message contains an RAO value which is
> relevant to the node, but the signaling application for the actual
> NSLPID is not processed.
>
> I cannot understand the situation "IP layer is unable to
> determine whether to forward it" in case 1.
>
> Best Regards,
> Takako
>
>
>
> On Mon, 31 May 2004 01:23:18 +0100
> "Hancock, Robert" <robert.hancock at roke.co.uk> wrote:
>
> > Dear all,
> >
> > There is a new version of the GIMPS draft just in time (OK,
> not really
> > in time,
> > but I plead excessive viral computer fun as a
> distraction...) for the
> > interim.
> > Catch it now at http://nsis.srmr.co.uk/draft-ietf-nsis-ntlp-02.txt.
> >
> > The change log in 9.1 summarises what has changed since the -01
> > version.
> >
> > We've been asked to indicate how the early review comments
> have been
> > taken into account in this version. Most of the details are in the
> > change log, so I'll just provide some pointers at the end of this
> > mail.
> >
> > Happy reading!
> >
> > Robert H.
> >
> > Early Review Comment Resolution:
> >
> > From Alex (see
> > http://www.tschofenig.priv.at/nsis/IETF59/nsis-zinin-ietf59.ppt)
> > Q: Why per-flow routing info in NTLP?
> > A: More explanation added at end of 4.1.1
> > Q: Suggests flow based routing?
> > A: This is a misunderstanding; in any case, related
> developments have
> > changed the text (see change number 6)
> >
> > From Dave (see
> > http://www.ietf.org/mail-archive/web/nsis/current/msg03809.html)
> > Q: Flow definition excludes multicast, splitting
> > A: Definitions modified, see change number 1
> > Q: How do you handle not-on-path proxies
> > A: We don't - clarified proxy definition in 3.2
> > Q: Why a hop count rather than a VIA header?
> > A: The rationale is in the mailing list archive for March;
> we haven't
> > put this in the document in the interest of brevity.
> (However, there is
> > improved text on loop handling, see change number 8)
> > Q: The D-mode messages have to follow the data flow
> > A: Yes, existing text on the subject has been gathered
> (from the rest of
> > the document) into section 5.3
> > Q: Does having GIMPS do NAT traversal hijack signaling
> application role?
> > A: This is still open for discussion. The text in section
> 6.3 is clear
> > on this. It needs discussion with the NATFW people (i.e. it
> is not just
> > a GIMPS issue); at the moment, the NATFW NSLP regards handling NAT
> > traversal aspects of non-NATFW NSLPs as out of scope, so
> the boundary is
> > consistent
> > Q: Tunneling nit
> > A: Text in 6.4 adjusted accordingly
> > Q: Does 8.2 really rule out raw-IP?
> > A: The text in 8.2 on the subject has been expanded to say why.
> > Q: Aggregation is per-interface, not per-node
> > A: Text in 8.4 on aggregation handling adjusted accordingly
> >
> > _______________________________________________
> > nsis mailing list
> > nsis at ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
>
>
> _______________________________________________
> nsis mailing list
> nsis at ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis