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

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 6 Jul 2003 12:48:22 +0200

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

2. The PWE3 framework and PWE3 Protocol Layers drafts referenced 
   in the document has been merged into a common PWE3 architecure 
   document.

3. Requirement to "detect detectable" transmission errors looks
   somewhat vague. (I believe that nobody expects the FRoPW to detect
   undetectable transmission errors:-)

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.

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

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

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?:-)

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

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

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

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