[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PWE3] draft-ietf-pwe3-frame-relay-05.txt last call

Please find comments on draft-ietf-pwe3-frame-relay-05.txt:


-----

1. Section 3.

      Bc      Committed burst size
      Be      Excess burst size
      BECN    Backward Explicit Congestion Notification
      CE      Customer Edge
      CIR     Committed Information Rate

***CP: Some acronyms such as Bc, Be, CIR are not used.

      SPVC    Switched/Soft permanent virtual circuit

***CP: Capitalize PVC in the definition.

-----

2. Section 4.

   The following two figures describe the reference models which are

***CP: There seems to be only one figure following.

   derived from [RFC3985] to support the frame relay PW emulated
   services.


-----

3. Section 6.1

   between PEs and within the MPLS core network for forwarding purposes
   of PW packets. A MPLS tunnel corresponds to "PSN Tunnel" of Figure 1.

***CP:            ^An MPLS

-----

4. Section 6.2

    +-------------------------------+
    |       Control Word            |
    |      (See Figure 5)           | 4 octets

***CP: Is the above "See Figure 4"?

       The MPLS Tunnel label(s) corresponds to the PSN transport header
       of Figure 3.  The label(s) is/are used by MPLS LSRs to forward a

***CP: Is the above reference to Figure 2? If so, Figure 2 says "MPLS
***CP: Transport header"

       [snip]

       The PW label identifies one PW (i.e. one LSP) assigned to a frame
       relay VC in one direction. It corresponds to the PW header of
       Figure 3. Together the MPLS Tunnel label(s) and PW label form an

***CP: Is the above reference to Figure 2?

-----

5. Section 6.3

   When carrying frame relay over an MPLS network, sequentiality may
   need to be preserved. The REQUIRED control word defined here
   addresses this requirement.

***CP: The CW is REQUIRED because the need to transport FECN, BECN, etc
***CP: from the FR Header. That should be mentioned here instead of
***CP: sequentiality.

   The meaning of the Control Word fields (Figure 5) is as follows (see
   also [X36 and X76] for frame relay bits):

***CP: Should this be "Figure 4 and Figure 5" or "Figure 4" alone
***CP: (instead of Figure 5)?

     - Res  (bits 8 and 9):  These bits are reserved and MUST be set to
       0 upon transmission and ignored upon reception.

***CP: There is an Informative Reference to FRAG, although unused.

-----

6. Section 6.4

   |0 0 0 0|B|F|D|C|Res|  Length   | Sequence Number               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

***CP: Missing Figure caption (this should be Figure 5)

-----

7. Section 6.5.1

     - The payload of the PW packet is the contents of ITU-T
       Recommendations X.36/X.76 [X36, X76] frame relay frame
       information field stripped from any bit or byte stuffing.

***CP: [X36, X76] are 2 independent references [X36] and [X76]

-----

8. Section 6.6

     - The C/R bit is copied in the frame relay header.

***CP: The CW bit was defined as "C bit"

-----

9. Section 6.9

   If the PE detects a service-affecting condition for a particular
   DLCI, as defined in [ITUQ] Q.933 Annex A.5 sited in IA FRF1.1, the PE

***CP: It seems to me [ITUQ] reference that currently includes Q.922 and
***CP: Q.933 should be split into 2 individual references. Q.933 should
***CP: point to the 2003 revision that superseded the 1995 one.

   MUST communicate to the remote PE the status of the PW that
   corresponds to the frame relay DLCI status. The Egress PE SHOULD

***CP: It would be useful to detail how this communication (PW Status)
***CP: happens. That is, the relationship between PW Status messages and
***CP: the PVC status management procedures (Q.933A).

   generate the corresponding errors and alarms as defined in [ITUQ] on
   the egress Frame relay PVC. There are two frame relay flags to

***CP: The sentence that starts with "There are two frame relay flags
***CP: to" above changes subject, and may be more clear in a new para.

-----

10. Section 6.9.1

     - 0x08 Frame-Relay DLCI Length.

***CP: This interface parameter seems like a misnomer, it conveys the
***CP: "FR Header Length" (2- or 4-octet) and not the "FR DLCI Len" (10-
***CP: or 23-bit).

       An optional 16 bit value indicating the length of the frame relay
       DLCI field. This OPTIONAL interface parameter can have value of 2
       , or 4, with the default being equal to 2. If this interface

***CP: Q.922 also defines a 3-octet FR Header, but FRF specs (such as
***CP: FRF1.2) say that it is "unsupported". A clarification that a
***CP: 3-octet FR Header Length is out-of-scope would be useful.

       parameter is not present the default value of 2 is assumed.


-----

11. Section 12.

***CP: The references [ITUG] and [RFC3031] seem to be not used in the
***CP: document.

-----

12. Section 13.

***CP: Some informative references seem not used in the document, such
***CP: as [FRAG] (which is duplicate), [I233], most/all [FRF_]. Also
***CP: note the above comment about splitting [ITUQ].

-----

General:

***CP: Different forms of FR (frame-relay, frame relay) and PW
***CP: (pseudo-wire, Pseudo Wire, etc) throughout the document.


Thanks !!

--Carlos.

Circa 5/31/2005 11:40 AM, Stewart Bryant said the following:
> 
> This is the start of last call for
> 
> draft-ietf-pwe3-frame-relay-05.txt
> 
> Last call will close on 20 June 2005
> 
> - Stewart
> 
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3 at ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

-- 
--Carlos.
Escalation RTP - cisco Systems

_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3