Subject: [midcom] Comments on the semantics draft: flow specification issues

From: Tom Taylor <[email-masked]>
Date: Wed, 30 Jul 2003 15:54:57 -0400

Thanks to Alain, Pyda and Juergen for their comments on the semantics draft.  I'll 
be giving my response to all of their comments, but some topics were common and big 
enough to deal with in a separate note.  The issues associated with flow 
specification are an area we need to review.

===========
Alain said:
===========

Issue 6:
--------
2.3.5.  Address Tuples

     Request and reply messages of the PRR, PER, and PRS transactions
     contain address specifications for IP and transport addresses.  These
     parameters include

        - IP version
        - IP address
        - IP address prefix length
        - transport protocol
        - port number
        - port parity
        - port range

==> Actually, if one wants to specify a flow, this is not enough.
      In particular, in the early stages of IPv6 deployment,
      we see a lot of encapsulated traffic, IPv6/IPv4 (proto 41)
      or IPv6/UDP/IPv4.
      This would be of importance if the middlebox is a de-capsulator,
      or a NAT/forwarder of IPv4 proto 41 and you'd like to use the
      MIDCOM protocol to configure it.

Issue 7:
- --------
2.3.6.  Address Parameter Constraints
[...]
     The value of the transport protocol parameter can have one of the
     following values: 'TCP', 'UDP', 'ANY'.

==> What about other transport protocols? Previous comment applies here
too.  The semantic here should be extended to be more general.

==========
Pyda said:
==========

  1. I suggest, the document state upfront that the focus of the draft was
principally TCP and UDP based applications ( I think, section 2.3.6 states
this).

=============
Juergen said:
=============

  (h) The text specifically talks about TCP and UDP. There are of course
     more transports to consider. In fact, you may want to filter based
     on the contained protocol number or something equivalent.

==============================================
Response (probably leading to more discussion)
==============================================

There is an issue with complete generalization here.  SCTP was on the list earlier, 
and concern was expressed that there is as yet no specification for how NATs handle 
SCTP when it involves multihoming.  Alain's issue 6 regarding encapsulation seems to 
have somewhat of the same flavour -- that is, it requires an additional description 
of middlebox functionality to serve as a starting point*.  The Midcom protocol is 
supposed to be about controlling that functionality, not defining it.  In other 
words, any middlebox capability we invoke should itself be specified in some other 
document, which we should include as a reference in this one.

*(Such a description may exist for encapsulation, in which case, could someone 
please provide the reference.)

  Tom Taylor

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