Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 5 Nov 2003 21:46:11 -0000

Hi again,

> -----Original Message-----
> From: Ling Kim Hui [mailto:[email-masked]]
> Sent: Monday, November 03, 2003 03:31
> To: [email-masked]
> Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt
> 
> 
> Dear Mr Hancock,
> 
> Thanks a lot for your timely reply. After checking the mailing list
> archieve, I realized that the framework draft -04 has already gone
> through the working group last call.  Does it mean that the draft -05
> will go directly to AD/IESG for review? Sorry for asking, 
> since I am not that familiar with the review procedure.

yes, basically -05 is now in ad/iesg hands. (this doesn't stop us 
talking about what it means, however.)

> 
> I agree with most of your comments, though I have a few more thoughts
> about them.
> 
> 
> 
> > i consider this as coming under the broad heading of route changes. 
> > there are actually several different categories of route change anyway
> > (different peer because of topology change, different peer because of 
> > NE failure but no rerouting, same peer but different ingress or egress
> > interfaces, same peer but different intermediate routers, ...)
> > 
> > exactly how each case is distinguished and handled will have to be 
> > done during protocol design. different protocol designs and indeed 
> > different implementations will be able to do different types of route 
> > change handling, so the framework can't really define this.
> 
> This makes things clearer to me.  But I think the case we listed out is
> more of a detection of false route change. Largely in the draft, the
> route change is defined as the change of route for data traffic. 
> 
> It is correct that details of handling the route change is a protocol
> design issue, but my feeling is that in the framework, we should point
> out different scenarios, so that protocol designer could be aware of
> those issues.
> 
> Therefore, it would be good to include some text to clearly identify the
> route change cases (including the false route change)

this could be done. it means referencing 3.2.5 from 5.1.2 and noting in
particular that sometimes the next peer may change even though the
topological route in the network has not.

> > the information is the flow id (4.6.1). we specifically don't call 
> > this the flow classifier, since the NTLP isn't interested in packet 
> > classification; another name for the flow id would be 'flow routing 
> > information' (which is what the NTLP draft calls it). the NSLP might 
> > use the flow id as part of a packet classifier.
> 
> Is the flow ID the only field that needs to be visible to the NTLP?  How
> would the NTLP uses information in the NSLP payload?  Should it be
> accessible by the NTLP? Shouldn't that be encrypted?
> 
> I know this maybe depend on the implementation, but is it possible to
> give me some guidance on any possible implementation method, since I am
> really curious how it should be realized? 
> 

well (just for example): the NSLP would invoke the NTLP with
- an opaque (maybe encrypted) payload (e.g. some QoS parameters)
- addressing information about the flow being signalled for

the NTLP formats the addressing information into a flow ID object,
which is carried along with other NTLP objects (message sequence
numbers and so on), and the NSLP payload. the NTLP doesn't interpret
the NSLP payload, but the flow ID is not part of the NSLP payload.
(the NSLP can find out about some NTLP objects, just like a UDP or
TCP based programme can find out about what IP addresses are associated
with a socket.)

of course, other approaches are also possible.

> 
> > formally, the f/w is not a standards track document, so it
> > cannot define and manage identifier formats in this way. at
> > the moment it seems likely that the session id will be an object in
> > the NTLP, so the NTLP specification will pin this down and the sort
> > of problems you indicate cannot arise.
> 
> I am a bit confused here. Does this mean that the session ID instead of
> Signaling Application ID would be used for demultiplexing the NSLPs?

not "instead of", "possibly as well as".

> Would the NTLP define how the Session ID be formatted?

yes. the session ID would be another object in the NTLP, so the NTLP
spec would have to define how it is formatted.

> 
> As described also in your mail, the Session ID is not able to fully
> replace the Signaling Application ID.  Therefore, I think the SAID
> format still has to be formally defined to achieve interoperability.  If
> the framework could not do it, would NTLP draft able to define it?  I
> feel maybe it is better to put a pointer in the framework 
> draft to that.

i hope that is implied by the fact that these objects are assumed to be
carried in the NTLP. maybe 4.6 should say this at the start if this is
unclear.

> 
> Also, I am not quite clear about the statement "it seems likely that the
> session id will be an object in the NTLP".  Does it mean the Session ID
> would be generated and maintained in NTLP, and it would be carried at
> NTLP headers?

to answer the second question: yes (see above).

to answer the first question: maybe, maybe not. this is a matter of
NTLP design and also an implementation issue. a good comparison is 
the IPv6 flow label specification work (draft-ietf-ipv6-flow-label-08.txt 
section 3). the details can get even more complicated in the NSIS case.

> 
> 
> 
> Thank you very much for your time and attention.
> 
> Regards,
> Kim Hui

it's a pleasure,

r.

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 5 Nov 2003 17:04:46 -0500

> - addressing information about the flow being signalled for

There are some issues here around NAT traversal that might lead
one to conclude that the "NAT application" actually belongs in
the NTLP.  Having a firewall/NAT NSLP is fine if you aren't
concerned about NAT interactions in other NSLPs, like QoS (or
anything which uses addressing information as part of the
reservation description).  Obviously you want to avoid a
situation in which the NTLP is peeking into, and parsing,
NSLP payloads, and you want to avoid a situation in which
random NSLPs must peek into a NAT NSLP (particularly if
they're encrypted using different keys).  Reimplementing NAT
function in every NSLP that uses addresses is also unattractive.

The first question, obviously, is how generalized you'd like
your NAT traversal capabilities to be.

Melinda