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

From: Luca Martini <[email-masked]>
Date: Fri, 02 Dec 2005 17:52:50 -0700

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
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/pwe3
>>
> 

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 05 Dec 2005 21:05:21 -0500

Luca,

Please see inline.

> I will fix it here , however the IANA draft is already in the RFC editor

Yes; the description in the next paragraph says "indicating the length
of the frame relay DLCI field." Instead, it should say "indicating the
length of the FR Header expressed in octets."

> could it not be transported in the PW ?

Yes, it could be transported over the PW if it was defined in the native
service. The "out of scope" is a suggestion because the native service
specs say it's "not supported" for FR UNI (FRF1.2 Section 2.2.3) and
"outside the scope of this implementation agreement" for FR NNI (FRF2.2
Section 2.1.4).

Thanks,

--Carlos.

-- 
--Carlos.
Escalation RTP - cisco Systems

---

From: Luca Martini <[email-masked]>
Date: Mon, 05 Dec 2005 21:29:10 -0700

> length of the FR Header expressed in octets."
yes. I got this one too.

Thanks.
Luca