Subject: Comments draft-ietf-pwe3-frame-relay-02.txt

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 4 Feb 2004 11:05:25 +0200

Claude and all,
After having read the -02 draft I sorry to say that almost all my
comments to the -01 version have remained unresolved.

Please find below the (indented) text of the original comments
with the added status of their resolution (marked [02-status]). 
In some cases I've added some fresh considerations and suggestions.

Hopefully these comments will be useful.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Sasha Vainshtein 
> Sent: Sunday, July 06, 2003 12:48 PM
> To: [email-masked]'
> Cc: PWE3 WG (E-mail)
> Subject: Comments draft-ietf-pwe3-frame-relay-01.txt
> 
> 
> Claude and all,
> Please see below several comments on the latest revision 
> of the FRoPW draft. Some of these are purely editorial nits, 
> while some other look to me like substantial omissions.
> 
> 1. The Intro section defines the difference between one-to-one 
>    and many-to-one modes like following:
> 
> <quote>
>    Two mapping modes are defined between FR VCs and FR PWs: The first
>    one is called "one-to-one" mapping. because there is a one-to-one
>    correspondence between a FR VC and a pair of 
> unidirectional PWs. The
>    second mapping is called "many-to-one" mapping or "port 
> mode" because
>    multiple FR VCs assigned to a port are mapped to one pair of PWs.
> <end quote>   
> 
>    I think that "unidirectional PWs" are not defined anywhere in the
>    PWE3 architecture. And somehow "unidirectional" is missing in the 
>    definition of the "many-to-one" mode while the "pair" remains.
>    Pairs of PWs are also mentioned in the Reference Model section...
>    but Section 7.2 changes the language and discusses a pair of
>    (unidirectional) VC LSPs per a FR VC. And section 9 explicitly
>    refers to "a PW, i.e. a pair of VC LSPs"...
> 
[02-status] - no change found. Of coures, this is mainly editorial stuff...
>
> 2. The PWE3 framework and PWE3 Protocol Layers drafts referenced 
>    in the document has been merged into a common PWE3 architecure 
>    document.
> 
[02-status] - Done
> 
> 3. Requirement to "detect detectable" transmission errors looks
>    somewhat vague. (I believe that nobody expects the FRoPW to detect
>    undetectable transmission errors:-)
>
[02-status] - almost no change (brackets have been placed around the word
"detectable"). 
> 
> 4. The draft mentions padding at the end of the FRoPW packet "when 
>    a pseudo-wire traverses a link that requires a minimum layer 2 
>    frame length". Since the PWE3 functionality resides exclusively
>    in the edge devices which are, at most, aware, of the
>    types of links they terminate, the text is misguiding. 
>    a) Section 7.4.1.1 seems to define padding as part of the 
> ingress PE 
>       functionality. It states that "If the link layer 
> protocol does not 
>       have a minimum length requirement then Length_field is 
> set to zero
>       and no padding is required." Would this logic really be 
> implemented,
>       the egress PE would be unable to recover the actual 
> length of a short
>       FR frame if the PW crosses an Ethernet link somewhere 
> in the PSN core
>       while the ingress PE uses, say, POS for its connection 
> to the PSN.
>    b) The definition of padding characters in Section 7.3. 
> states that 
>       "any 8-bit character with a decimal value from 0 to 255 
>       may be used as a padding character" as if 8-bit characters with 
>       other decimal values exist...
>    IMO, padding is the function of the appropriate link 
> anywhere in the
>    network, and not of the PW IWF. The ingress PE must set 
> the length field 
>    to sizeof (payload + FRoPW header) if this size is  less 
> then 64 bytes, 
>    otherwise the length field  must be set to 0. The egress 
> PE then always
>    can recover the length of the payload. 
>    And, of course, padding is irrelevant with and IP PSN.
>
[02-status] - No changes found. This is NOT an editorial comment,
since the PWE3 Charter explicitly limits the PW functionality
to the PEs!  
Please compare this text to the (IMHO, correct!) padding-related 
wording taken from draft-ietf-pwe3-atm-encap-04.txt:
<quote>
   If the Pseudo Wire traverses a network link that requires a minimum
   frame size such as Ethernet as a practical example, with a minimum
   frame size of 64 octets, then such links will apply padding to the
   Pseudo Wire PDU to reach its minimum frame size. In this case the
   control word must include a length field set to the PDU length. A
   mechanism is required for the egress PE to detect and remove such
   padding.
<end quote>
I suggest to copy and paste this text (assuming, of course, that the ATM
draft authors do not object) as a replacement of all the padding-related
considerations in the FR draft. Among other things, it would also make
the draft shorter...
> 
> 5. There are two "B" bits in the FRoPW control word (one carrying 
>    the BECN bit of the encapsulated FR frame, and one belonging 
>    to the fragmentation mechanism).
>
[02-status] - No changes found!!! 
> 
> 6. The draft says that D and F bits of the FRoPW header are "copied" 
>    to DE and FECN bits of the recovered FR frame and then 
> explains that
>    a cleared bit can become set as the result of this "copying".
>
[02-status] - No changes found. This is mainly editorial stuff...
> 
> 7. The following text seems superfluous:
> <quote>
>             Re-ordering FRoPW packets is an implementation option but
>             requires that the sender numbers FRoPW packets.
> <end quote>
>    (Does anybody expect the egress PE to reorder unnumbered 
> packets?:-)
>
[02-status] - No changes found. In addition, I'd like to note that the draft
seems controversial wrt numbering of FRoPW packets: on one hand, it states
(in Section 4, item 3) that FR frames order must be preserved; on the other
hand,
it does not absolutely disallow using "unnumbered" packets (i.e. with the
sequence
number set to 0). The draft does not even preculde mixing numbered and
unnumbered
packets on the same FR PW. I suggest to state explicitly that such a mixture
MUST NOT be used!

And, BTW, Section 4 (Requirements) does not use the IETF all-capitals
"MUST"s and "SHOULD"s even if Section 2 (Terminology) provides an
appropriate 
reference to RFC 2119. Does this mean that these words are interpreted 
differently? E.g. "must" clauses do not specify absolute requirements?
This would account for handling of the numbering issue in the draft...
> 
> 8. Section 7.5 says that a FRoPW packet received with errors must be
>    silently discarded. It is not clear to which errors this section
>    refers:
>    a) Frames with L2 errors are (usually) discarded 
> regardless of being or
>       not being FRoPW packets (indeed, I am not sure one can identifiy
>       such frames as belonging to any specific PW)
>    b) No FRoPW specific errors are defined in the draft
>    c) In particular, it is not clear how to treat a packet 
> with L2 size
>       exceeding by far 64 bytes (after skipping the label stack) 
>       and non-zero Length field.
>
[02-status] - No changes found. The draft actually says that in such a case
the receiver must believe to what the Length field says (Section 7.4.2.2). 
This is acceptable and leaves just one possible FRoPW error to check:
(Lenght-field != 0) && (Length_FRoPW_packet < Length-field).
BTW, this case is not considered in the draft!!!
>
> 9. The draft does not specify whether the DE indications in 
> the FR frames
>    may be somehow reflected in the Diffserv markings of the 
> PSN headers.
>    (The WG Charter explicitly provides for such an activity.)
>
[02-status] - No changes found. I'd like to note that the draft mentions
the need to map FR transfer and discard priorities to "appropriately 
engineered PWs and PSN tunnels" (Section 4, item 8). Since, 
AFAIK, PWs are not engineered and, in any case their parameters cannot
be perceived by the PSN, the words "PWs and" seem superfluous. In other
words, the QoS requirement is neither spelled out properly nor met!
> 
> 10.With full respect to Steve Vogelsang, his name appears twice
>    in the list of the draft co-authors (but only once in the authors' 
>    addresses list:-).
>
[02-status] - no changes found!!! 
>
> Hopefully these comments will be useful.
> 
> With best regards,
>                                    Sasha Vainshtein
> email:     [email-masked]
> tel:       +972-3-7659993 (office)
>            +972-8-9254948 (res.)
>            +972-58-674833 (cell.)
>

---

From: [email-masked]
Date: Wed, 4 Feb 2004 6:39:58 -0500

Sasha, and others,

OK will work now to try to correct the text beforeloosing Sasha comments. 

claude 
> 
> From: Sasha Vainshtein <[email-masked]>
> Date: 2004/02/04 Wed AM 04:05:25 EST
> To: "[email-masked]'" <[email-masked]>
> CC: "'PWE3 WG (E-mail)'" <[email-masked]>,  "Andrew G. Malis (E-mail)"
> 	 <[email-masked]>,  "Rao Cherukuri (E-mail)" <[email-masked]>,  
> 	"David Sinicrope (E-mail)" <[email-masked]>,  
> 	Alik Shimelmits <[email-masked]>,  Sharon Galtzur <[email-masked]>,  
> 	Israel Sasson <[email-masked]>,  Itsik Goldraich <[email-masked]>
> Subject: Comments draft-ietf-pwe3-frame-relay-02.txt
> 
> Claude and all,