RE: Proposed changes to draft kamapabhava-01

[Shahram Davari <[e-mail]>]

Claude,
 
Just a couple of short comments.
 
-Shahram
 

-----Original Message-----
From: Claude Kawa [mailto:[e-mail]]
Sent: Thursday, April 18, 2002 10:29 PM
To: [e-mail]
Subject: [PWE3] Proposed changes to draft kamapabhava-01





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

To be consistant with FR/MPLS-Forum and the FR header, I suggest changing the order of the flags from BFDC to FBDC.

 w e 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."  

Does this mean that the FR header will be transported?

 -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