Proposed changes to draft kamapabhava-01

["Claude Kawa"<[e-mail]>]

I would like to propose changes to draft kamapabhava-01 taking into account
the comments received the last few days in order to progress this work. I
will be able to produce a new draft in 2-3 weeks (next week I am out of the
office).

Proposed changes to draft-kamapabhava-01:

-Fragmentation is an important issue, if we cannot resolve it now I propose
the following changes to the FRoPW header: We encode bits I and L used to
identified the fragments as 0 0 (0 0 means a complete frame) and work on the
solution without preventing the draft to progress.

-The P bit used to identified the payload as user data or network management
data, I propose that we keep this bit with the following description:

P - Payload Type  (bit 3):
   If set to zero then the payload field contains user's data else its 
   contents is not specified in this document.
   
   With this proposal, network and vendor may use P=1 in a proprietary way
to carry whatever they want to carry with the caveat that standardization of
the use of P=1 in the future may obsolete its proprietary use.
   
With these two changes the header will look like: 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res |P|B|F|D|C|0|0|  Length   | Sequence Number               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

We have now the header in draft-martini (when P = 0). 

Now I will address emails proposing other changes/explanations. If I missed
anything let met know.

-Sasha email: 
Item 1 was addressed above: " I have noticed that the FRoPW Control Word
still 
   contains bit "P" that distinguishes user and maintenance
   traffic - in spite of the maintenance protocol issue being
   removed from the draft."
   
Item 2: This one is about dropping frame out-of order vs. re-ordering them
We can re-introduce and improve the text of version 00: "Packets, which are
received out of order, MAY be dropped or reordered at
the discretion of the receiver".

Item 3: "The draft defines two modes of operation, but if only one of
   them - port to port - is referred to as a "mode". What is more,
   one mode (the same) is defined as OPTIONAL but neither is
   defined as REQUIRED. Setting aside - for the moment - which mode
   should be which, explicit names for all the modes and
   explicit specification of the REQUIRED mode would be very 
   much in place. In particular, this would help with creating
   a 'per mode' applicability statement (preferably inline -
   the draft is not too long)".

About what is optional and what is mandatory. I prefer to address this item
later since we have IP and L2TPv3 too in addition to MPLS tunnels. I propose
that we do not specify what is mandatory and what is optional now but wait
to see the complete spec covering other tunnels.
   
Item 4: "The draft specifies a set of requirements for FRoPW. 
   Have you considered providing a check-list
   matching these requirements with the design spec? 
   IMHO this would be very useful and (hopefully) not too 
   difficult (in the worst case you can always drop an
   especially inconvenient requirement :-). 
   Personally I would like to understand how the requirement 
   for mapping the traffic management parameters is met
   with this spec."
   
   We will check the requirements list against the design spec and
drop/change what needs to be dropped/changed. However for traffic
management, it will take a little bit more time to address. We will not do
it in the next version if we produce it in 2-3 weeks as we propose. Traffic
management is definitely a high priority item.
   
   
-Comment from George Wilkie about the control word: We will follow the
suggestion in George's email: 
  
  "The doc appears to require the use of the FRoPW control word for all
types of
PSN.I understand the need for MPLS, not clear to me for other PSNs, e.g.
L2TPv3.
L2TPv3 can do without the control word since it has its own sequencing
capability and IP has no need for length field.
The DLCI can remain on the frame to carry the FBDC bits and avoid
inefficient
copy out/in."

-Next comments are from LLoyd Wood email that came today (Thursday)

1-We will address the use of IP tunnel. We have a placeholder for that but
MPLS seemed to have a higher priority.

2-About the security section we will use what is draft-bryant-pwe3-fr-encap.
It looks good. 

3-We will try to adopt other useful material from draft bryant complementing
draft kamapabhava-01.

Anything else I missed?

Now I would like to propose to write a new version of kamapabhava  with the
above changes/additions as a working group draft.

Claude Kawa