Re: Proposed changes to draft kamapabhava-01

[Stewart Bryant <[e-mail]>]

> Claude Kawa wrote:
> 
> 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.
> 

Reserving a bit with undefined behaviour does not make sense to me. 
Surely the right approach is to restore it to reserved MBZ as in Martini
and when you have a defined behaviour, request that the group allocate
you a bit from the reserved bits?

Stewart

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