Re: Proposed changes to draft kamapabhava-01

["W. Mark Townsley" <[e-mail]>]

Just two comments. Thanks Claude.

- Mark

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

Why did you relegate I and L to 0 0, but still keep the P bit (half)defined?
There seems to be an inconsistency here.

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

I propose that the IP section does not fit within the architecture and should be
removed. Realistically, we have FR over MPLS and FR over L2TPv3. 

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