[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PWE3] draft-ietf-pwe3-frame-relay-05.txt last call
Carlos,
Replies are in line below.
Thanks.
Luca
Carlos Pignataro wrote:
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.
good point, this remained there from the previous version.
I'll remove them.
SPVC Switched/Soft permanent virtual circuit
***CP: Capitalize PVC in the definition.
I removed the definition ....
-----
2. Section 4.
The following two figures describe the reference models which are
***CP: There seems to be only one figure following.
Indeed ;-)
Fixed.
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
Fixed
-----
4. Section 6.2
+-------------------------------+
| Control Word |
| (See Figure 5) | 4 octets
***CP: Is the above "See Figure 4"?
Fixed.
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"
Correct. I fixed it.
[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?
Fixed.
-----
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.
I reworded the whole section.
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)?
fixed
- 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.
Yes. the problem is that we do not want to block these drafts because of
the FRAG reference.
So the bits are reserved in all the encapsulation drafts.
-----
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)
fixed.
-----
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]
???
you want me to use more brackets ?
ok.
-----
8. Section 6.6
- The C/R bit is copied in the frame relay header.
***CP: The CW bit was defined as "C bit"
only in the picture . It is defined as C/R in the text.
-----
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.
Fixed.
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).
That is out of the scope of this document. It is part of the NSP (
rfc3985) function.
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.
Fixed
-----
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).
Good catch !
I will fix it here , however the IANA draft is already in the RFC editor
queue...
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.
But why is it out of scope ?
could it not be transported in the PW ?
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.
ok , they do not need to be used i nthe document to be included here.
-----
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].
Fixed.
-----
General:
***CP: Different forms of FR (frame-relay, frame relay) and PW
***CP: (pseudo-wire, Pseudo Wire, etc) throughout the document.
Will fiix those as well.
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
_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3