Subject: Re: Call for Frame-relay WG document.

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 11 Jul 2002 17:33:42 +0200

> Claude Kawa wrote:
> 
> Reply with some questions for clarification are in-line preceded by [CK].
> 
> In general I agree with the comments, in particular points 1 and 2.
> 
> If there are no objections do we make the next version of the draft addressing
> Stewart Bryant's comments a WG draft?

Comments inline...

> 
> Thanks
> 
> Claude
> 
> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Tuesday, July 09, 2002 10:47 AM
> To: Kawa, Claude [CAR:CS40:EXCH]
> Cc: [email-masked]; Luca Martini
> Subject: Re: [PWE3] Call for Frame-relay WG document.
> 
> Although I am generally supportive of this document, I have some
> comments on the draft (see below). Of these points, the first
> two need to addressed (or the plan to address them needs to be
> agreed) before this becomes a WG draft. The other points are
> just normal technical issues that need to be addressed before
> final closure.
> 
> Stewart
> 
> 1) The title should reflect the scope, or the scope should reflect
> the title  - mpls or ip and mpls?
> 
>                "Frame Relay Encapsulation over Pseudo-Wires
>                    draft-martini-frame-encap-mpls-01.txt"
> 
> [CK] Are we referring to the title "Frame Relay Encapsulation over
> Pseudo-Wires " or the draft Id
> "draft-martini-frame-encap-mpls-01.txt"?
> 
> If it is the title we are open to suggestion.
> 
> if it is the draft Id, we agree that it does not reflect the scope. We used
> the previous Id (draft-martini-...) with a new version number. With a working
> group draft this situation will be corrected.

I still find a lot of this draft as bulky and somewhat irrelevant or redundant
for L2TPv3. In fact, I think one could largely implement Frame Relay PWE3 over
L2TP by consulting only the L2TPv3 base spec and the short l2tp frame relay
draft mentioned above. 

I have never really understood the advantage of bundling L2TP-specific text and
MPLS-specific text in the same document.

Ideally, I would like to see a concise, fairly short, PWE3 document that
discusses some of the generic faithfulness issues for PWE3 emulation regarding
frame relay with little or no mention to MPLS, L2TP, GRE, IP, etc. etc. This
would include such generic issues as sequencing, BECN and FECN, LMI, and so
forth discussed in an abstracted manner as it relates to the given PW emulation
at hand.

Then, in short PSN-specific documents, we explain how to do PW for MPLS, and how
to do PW for L2TP. Thus, an L2TP developer doesn't wade through MPLS gorp and an
MPLS developer does wade through L2TP gorp. But, both can look at the common
PWE3 issues in one place. These common issues begin with faithfulness, and end
at the encapsulation formats.

The other advantage here is that if L2TP or MPLS dies, or a new tunneling method
is born, we do not deprecate or date the PWE3 specification in the process. 

> 
> 2) This work also needs to align with the frame relay drafts that
> Mark Townsley et al have been woring on - either by adjustment
> of scope or incorporation.
> 
> [CK] OK. I counted three drafts:
> 
> 1-Frame-Relay Pseudo-Wire Extensions for L2TP
> 2-Frame-Relay Pseudo-Wire Extensions for L2TP
> 3-Pseudowires and L2TPv3

1 and 2 are just updates of one another, current version is:
draft-ietf-l2tpext-pwe3-fr-01.txt

#3 is generally applicable to PWE3 and L2TP, but not FR in a specific sense.

> 
> Some (if not all) of them came after we uploaded the "martini FR/PWE3" or at
> the same time.

Version -00 of the relevant draft above came in Feb 2002, before -00 or -01 of
draft-martini-frame-encap-mpls-01.txt :-)

> 
> We will address them in the next version with the exception of the control
> aspects since we are limiting ourselves in this draft to the encapsulation
> only. Is this agreeable?
> 
> 3) Please use another acronym for the PLD and not [LYR] :)
> 
> [CK] OK will use PLD
> 
> 4) I think we need to prune the terminology section to just
> FR new terms. This is a  general observation on a number of docs.
> 
> [CK] Agree. There was a suggestion (by Danny) to remove the common terminolgy
> from the various drafts and to refer to the requirement and framework drafts.

Yes. In general, I see a lot of duplicate text across multiple draftss. Makes me
think of cut-and-paste coding that needs to be replaced with a healthy dose of
modularization.

> 
> 5) Do we need the requirements section (sect 4)?
> 
> [CK] This section is intended to show what the PE will/should/... provide as a
> service.
> It can be removed if we do not want to list what the PEs will provide and the
> users will get or as suggested below it can merge with an applicability
> statement.
> 
> 6)      "3. Frame ordering: Must preserve FR frames order.
> Must is too strong, we know that some networks as happy without
> it. "
> 
> If an application claims order support, it must work, but
> I do not think it is a MUST.
> 
> [CK] OK we will change the wording
> 
> 7)        "Sequence number (Bit 16 to 31):
>             If it is not used, it is set to zero by the sender and
>             ignored by the receiver. Otherwise it specifies the sequence
>             number of a FRoPW packet. A circular list of sequence
>             numbers is used. A sequence number takes a value from 1 to
>             65535 (2**16-1). Arithmetic modulo 2**16 is performed to
>             generate a new sequence number. The value of zero indicates
>             that the sequence number field is not used."
> 
> In some document there should be an applicability statement regarding the
> suitability of a 16 bit sequence number.
> 
> [CK] OK. This apply to the other drafts also (ATM, ETh in particular)
> 
> 8) I think that DE bit setting is an NSP function, and so outside the PWE3
> scope. PWE3 should transmit the bit unmodified. The same applies to FECN
> and BECN.
> 
> [CK]  Ok in principle but need to think about this point.

These are certainly the types of things one would discuss in a common
frame-relay PWE3 document, and I would be more than please to be able to
reference them from draft-ietf-l2tpext-pwe3-fr-01.txt

> 
> 9) "The initial packet transmitted on the frame relay PW must use sequence
> number 1." - I am not sure that this is a must.
> 
> [CK] Agree to have the right statement in the draft but need to think more
> whether 1 is the first value or not and what is the impact.

It certainly is not an L2TPv3 must.

> 
> 10) These diagrams do not conform to the IETF bit order notation, and
> this could lead to confusion. I suggest that you use the diagram in
> <draft-ietf-l2tpext-pwe3-fr-01.txt>
> 
> [CK} Ok they were done without thinking about the ITU vs IETF bit order.
> 
>  bit 8  7   6   5   4   3   2   1    bit   8  7   6   5   4   3   2   1
>    +-------------------------------+  +-------------------------------+
>    |   Upper DLCI          |C/R| 0 |  |   Upper DLCI          |C/R| 0 |
>    +-------------------------------   +-------------------------------+
>    |  Lower DLCI   | F | B | DE| 1 |  |   DLCI        | F | B | DE| 0 |
>    +-------------------------------+  +-------------------------------+
>    |                               |  |           DLCI            | 0 |
>    :  Q.922  Information field     :  +-------------------------------+
>    :    (i.e. FR payload)          :  |          Lower DLCI   | 0 | 1 |
>    |                               |  +-------------------------------+
>    +-------------------------------+  |                               |
>                                       :  Q.922  Information field     :
>                                       :    (i.e. FR payload)          :
>                                       |                               |
>                                       +-------------------------------+
> 
>     (a) With 10 bits for the DLCI      (b) With 23 bits for the DLCI
> 
> 11) I think that a single section should be used to cover requiremensta and
> applicability (ie Frame relay service over pseudo-wires)
> 
> [CK] Agree. The idea of section 11 is to become an applicability statement. It
> is a good idea to include in one section the requirements and the
> apllicability statement.
> 
> With the above comments do we agree update the draft
> "draft-martini-frame-encap-mpls-01.txt" and make it a PWE3 WG draft?
> 
> Thanks
> 
> Claude

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 11 Jul 2002 14:11:41 -0400

>at the encapsulation formats.

         This sounds like a reasonable approach. In fact, we took this same
approach with the MIBs.

         --Tom

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

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.