Gen-Art LC Review: draft-ietf-pwe3-tdmoip-05.txt

I am the assigned Gen-ART reviewer for draft-ietf-pwe3-tdmoip-05.txt.
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

(Minor note: I am copying only the first of the authors as otherwise 
filters may complain about the number of adressees.  I will send a 
separate copy to the other authors, as I expect the copy to the WG 
list to be delayed.)

Please resolve these comments along with any other
Last Call comments you may receive.

This document is nearly ready for publication as an RFC.  There are 
some items which warrant attention.

Question: Section 3 appears to define specific bits on the wire.  It 
defines the order of RTP vs other headers, and defines the setting of 
specific bits in the RTP header.  Later sections define wire formats 
for other headers.  Given such definitions, I would expect the 
document to be either Experimental or Standards track, rather than 
Informational.  I presume that this has been addressed, but since the 
tracker does not show anything, I am raising the question.
(I suspect that the WGs view is that the formats are all normatively 
defined elsewhere, and are just being collected here for 
reference.  Collecting packet formats by value, rather than by 
reference, is nice for books, but not usually a good idea for 
RFCs.  And at least the RTP header order and header field settings 
appear to be defined normatively here.)
Further, the presence of distinctly marked "informative" appendix 
indicates that the document is defining expected behavior and is 

RE: Gen-Art LC Review: draft-ietf-pwe3-tdmoip-05.txt

Joel, thanks for the review.

My comments on your findings are interleaved below.

Y(J)S

-----Original Message-----
From: Joel M. Halpern [mailto:joel <at> stevecrocker.com] 
Sent: Monday, September 04, 2006 02:48
To: Mary Barnes; gen-art <at> ietf.org
Cc: Mark Townsley; Stewart Bryant; Danny McPherson; Yaakov Stein;
pwe3 <at> ietf.org
Subject: Gen-Art LC Review: draft-ietf-pwe3-tdmoip-05.txt

I am the assigned Gen-ART reviewer for draft-ietf-pwe3-tdmoip-05.txt.
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

(Minor note: I am copying only the first of the authors as otherwise
filters may complain about the number of adressees.  I will send a
separate copy to the other authors, as I expect the copy to the WG list
to be delayed.)

Please resolve these comments along with any other Last Call comments
you may receive.

This document is nearly ready for publication as an RFC.  There are some
items which warrant attention.

Question: Section 3 appears to define specific bits on the wire.  It 

FW: [PCN] PCN (Pre-Congestion Notification) draft charter

_______________________________________________
nsis mailing list
nsis <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nsis

Re: Gen-Art LC Review: draft-ietf-pwe3-tdmoip-05.txt

>Question: Section 3 appears to define specific bits on the wire.  It 
>defines the order of RTP vs other headers, and defines the setting of 
>specific bits in the RTP header.  Later sections define wire formats 
>for other headers.  Given such definitions, I would expect the 
>document to be either Experimental or Standards track, rather than 
>Informational.  I presume that this has been addressed, but since the 
>tracker does not show anything, I am raising the question.
>(I suspect that the WGs view is that the formats are all normatively 
>defined elsewhere, and are just being collected here for 
>reference.  Collecting packet formats by value, rather than by 
>reference, is nice for books, but not usually a good idea for 
>RFCs.  And at least the RTP header order and header field settings 
>appear to be defined normatively here.)
>Further, the presence of distinctly marked "informative" appendix 
>indicates that the document is defining expected behavior and is 
>itself more than informational.
>
>[YJS] The designation of SAToP as standards track,
>and of TDMoIP and CESoPSN as informative, 
>was the result of a 3-year long battle in the PWE3 WG.
>Although I quite agree that the document defines a specific
>protocol (and one that has been widely deployed),
>I suggest not bringing that question up again.
>  
>
Yes, please can we allow that particular dog to remain soundly asleep!  :)

Yaakov's comments to the other issues look fine to me.

- Stewart

RE: Gen-Art LC Review: draft-ietf-pwe3-tdmoip-05.txt

I understand that the 0.2% number comes from the ITU, and is 
significant for the protocol choice.
However, characterizing IP networks with reliabilities above that as 
"extremely reliable and overprovisioned" seems a very odd 
characterization.  And that kind of debate simply does not belong in 
this document.

Yours,
Joel

At 02:00 AM 9/4/2006, Yaakov Stein wrote:
>moderate: The paragraph on SAToP in section 2.seems to characterize a
>loss rate of one fifth of one percent as an "extremely reliable and
>overprovisioned PSN."  While I do not want to get in to an argument
>about what is acceptable, it is to be noted that even TCP will have
>performance problems with a link with a 0.2% loss rate.  ISPs with
>loss rates much lower than that are still not usually referred to as
>"extremely reliable."  I would recommend simply removing the sentence.
>
>[YJS] This number come up from two sources.
>1) documents presented to the ITU question that worked in parallel
>to PWE3 showing that this is indeed a kind of dividing line between
>well-engineered networks and best-effort ones.
>2) empirical results that the user experience of circuit emulation
>with AIS substitiution drops at this level (see
>draft-stein-pwe3-tdm-packetloss-01.txt
>now expired).
>In any case, we are continually asked to characterize when to
>stop using SAToP and go over to one of the structure-aware methods.
>This is as good a break-point as any.
>For these reasons I would suggest keeping this sentence.

Liaison to ITU-T SG15

Liaison Statement

Submission 
   Date:      2006-09-13

From:         Loa Andersson (IETF Liaison to ITU-T, MPLS; IETF MPLS WG Chair; 
                 loa <at> pi.se)
              Scott Bradner  (IETF Liaison to ITU-T, sob <at> harvard.edu)
              Deborah Brungard  (IETF CCAMP WG Chair, dbrungard <at> att.com)
              Stewart Bryant (IETF PWE3 WG Chair, stbryant <at> cisco.com)
              Adrian Farrel (IETF Liaison to SG15, CCAMP WG Chair,    
                adrian <at> olddog.co.uk)
              Danny McPherson  (IETF PWE3 WG Chair, danny <at> arbor.net)
              George Swallow (IETF MPLS WG Chair, swallow <at> cisco.com)

To:           ITU-T Study Group 15; Greg Jones  (greg.jones <at> itu.int)

CC:           IESG  (iesg <at> ietf.org)
              IAB  (iab <at> ietf.org)
              Steve Trowbridge  (sjtrowbridge <at> lucent.com)
              Malcolm Betts  (betts01 <at> nortel.com)
              Yoichi Maeda  (maeda <at> ansl.ntt.co.jp)
              Ghani Abbas  (ghani.abbas <at> marconi.com)
              Houlin Zhao  (houlin.zhao <at> itu.int)
              CCAMP mailing list (ccamp <at> ops.ietf.org)
              MPLS mailing list (mpls <at> lists.ietf.org)
              PWE3 mailing list (pwe3 <at> ietf.org)

Re:           T-MPLS use of the MPLS Ethertypes

Response  
    Contact:  George Swallow  

Technical 
    Contact:  George Swallow

Purpose:      For action

Deadline:     2006-10-13

     We would like to thank you for your response to our liaison.  We
     feel that through the liaison activity and the Ottawa meeting we
     have entered into a productive and useful dialogue.  We are
     particularly pleased by your positive reaction to most of our
     concerns.

     We do, however, once again, request documentation of the problem
     that T-MPLS solves.  We feel that this documentation is
     fundamental to a proper review of the T-MPLS architecture,
     protocol requirements, and any future solutions, and we advise
     the ITU-T not to present any T-MPLS Recommendations for consent
     until work on a T-MPLS problem statement is well
     advanced. Further, a full reference diagram of the interfaces and
     services of the T-MPLS network would be most useful.  We
     understand that the direct adaptation of an IP/MPLS client over a
     T-MPLS server is still at a very preliminary stage.  However,
     some understanding of the client/server relationship is necessary
     in order to adequately evaluate architectural decisions currently
     being made in G.8110.1.

     The most immediate concern is the proposed use of the MPLS
     Ethertypes.  In your liaison to the MFA Forum dated 19-23 June
     2006 you say,

     First we would like to call your attention to the fact that we
     are in the process of modifying the semantics of the two
     Ethertypes used by MPLS.  Currently their designations are "MPLS
     Unicast" (8847) and "MPLS Multicast" (8848).  The new semantics
     will be "Downstream Assigned" (8847) and "Upstream Assigned"
     (8848)".  On a practical level, they will still be used for
     Unicast and Multicast respectively, however the change has been
     made to clarify which Label Switch Router (LSR) controls each
     label space.

     Each of these label spaces is shared by all MPLS applications.
     Each space is managed by a label-manager which is responsible for
     label allocation and reclamation.  When a packet is received at
     the downstream LSR with Ethertype 8847 it is looked up in a table
     managed by the downstream router.  Conversely when a packet is
     received at the downstream LSR with Ethertype 8848 it is looked
     up in a table managed by the upstream router.

     In your liaison to the MFA Forum dated 19-23 June 2006 you say,

        T-MPLS is intended to be a separate layer network with respect
        to MPLS. However, T- MPLS will use the same data-link protocol
        ID (e.g. EtherType), frame format and forwarding semantics for
        as those defined for MPLS frames.  T-MPLS and MPLS cannot
        coexist on the same "interface" (for example they could not
        coexist on a single Ethernet VLAN, however they could be
        multiplexed on to a common Ethernet PHY using separate VLANs).

     On the face of it, this statement implies that MPLS and T-MPLS
     are two different things, but that you wish to identify them both
     using the same Ethertype.  The Ethertype is the primary means for
     multiplexing and distinguishing protocols over Ethernet.  The
     Ethertype identifies the protocol entity that will receive a
     packet at the layer above.  VLANs on the other hand are primarily
     intended as a service level interface, allowing multiple virtual
     LANs over a single bridged domain.  .

     If T-MPLS cannot co-exist with MPLS over Ethernet, and T-MPLS is
     in fact a separate layer network, then it should be identified by
     its own Ethertype(s), Clear and unambiguous identification is in
     the best interest of all involved.  In particular, if T- MPLS is
     being architected in such a way that would prevent it from
     acquiring labels by interacting with a shared label manager, then
     separate Ethertypes would guarantee that there is no confusion as
     to which label spaces belong to T-MPLS.

     Note further that if T-MPLS is being architected in such a way
     that it can (or could) interact with a shared label manager and
     could co-exist over the same interface sharing the MPLS label
     spaces with other MPLS applications, then we would welcome use of
     the MPLS Ethertypes.

     We believe that a decision to use the MPLS Ethertypes to point to
     a label space other than as defined by the MPLS RFCs to be
     architecturally unsound and ultimately will prove to be limiting
     to the deployment options available in networks which employ both
     MPLS and T-MPLS.

     Sincerely,

        Loa Andersson 
        Scott Bradner
        Deborah Brungard
        Stewart Bryant
        Adrian Farrel 
        Danny McPherson
        George Swallow

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

Updated Liaison to ITU-T SG15

All -

There is a type-o in the liaison sent yesterday.  The second sentence of
the third paragraph should have been deleted.  An updated copy is
attached.

...George

========================================================================

Liaison Statement

Submission 
   Date:      2006-09-13

From:         Loa Andersson (IETF Liaison to ITU-T, MPLS; IETF MPLS WG Chair; 
                 loa <at> pi.se)
              Scott Bradner  (IETF Liaison to ITU-T, sob <at> harvard.edu)
              Deborah Brungard  (IETF CCAMP WG Chair, dbrungard <at> att.com)
              Stewart Bryant (IETF PWE3 WG Chair, stbryant <at> cisco.com)
              Adrian Farrel (IETF Liaison to SG15, CCAMP WG Chair,    
                adrian <at> olddog.co.uk)
              Danny McPherson  (IETF PWE3 WG Chair, danny <at> arbor.net)
              George Swallow (IETF MPLS WG Chair, swallow <at> cisco.com)

To:           ITU-T Study Group 15; Greg Jones  (greg.jones <at> itu.int)

CC:           IESG  (iesg <at> ietf.org)
              IAB  (iab <at> ietf.org)
              Steve Trowbridge  (sjtrowbridge <at> lucent.com)
              Malcolm Betts  (betts01 <at> nortel.com)
              Yoichi Maeda  (maeda <at> ansl.ntt.co.jp)
              Ghani Abbas  (ghani.abbas <at> marconi.com)
              Houlin Zhao  (houlin.zhao <at> itu.int)
              CCAMP mailing list (ccamp <at> ops.ietf.org)
              MPLS mailing list (mpls <at> lists.ietf.org)
              PWE3 mailing list (pwe3 <at> ietf.org)

Re:           T-MPLS use of the MPLS Ethertypes

Response  
    Contact:  George Swallow  

Technical 
    Contact:  George Swallow

Purpose:      For action

Deadline:     2006-10-13

     We would like to thank you for your response to our liaison.  We
     feel that through the liaison activity and the Ottawa meeting we
     have entered into a productive and useful dialogue.  We are
     particularly pleased by your positive reaction to most of our
     concerns.

     We do, however, once again, request documentation of the problem
     that T-MPLS solves.  We feel that this documentation is
     fundamental to a proper review of the T-MPLS architecture,
     protocol requirements, and any future solutions, and we advise
     the ITU-T not to present any T-MPLS Recommendations for consent
     until work on a T-MPLS problem statement is well
     advanced. Further, a full reference diagram of the interfaces and
     services of the T-MPLS network would be most useful.  We
     understand that the direct adaptation of an IP/MPLS client over a
     T-MPLS server is still at a very preliminary stage.  However,
     some understanding of the client/server relationship is necessary
     in order to adequately evaluate architectural decisions currently
     being made in G.8110.1.

     The most immediate concern is the proposed use of the MPLS
     Ethertypes.  

     First we would like to call your attention to the fact that we
     are in the process of modifying the semantics of the two
     Ethertypes used by MPLS.  Currently their designations are "MPLS
     Unicast" (8847) and "MPLS Multicast" (8848).  The new semantics
     will be "Downstream Assigned" (8847) and "Upstream Assigned"
     (8848)".  On a practical level, they will still be used for
     Unicast and Multicast respectively, however the change has been
     made to clarify which Label Switch Router (LSR) controls each
     label space.

     Each of these label spaces is shared by all MPLS applications.
     Each space is managed by a label-manager which is responsible for
     label allocation and reclamation.  When a packet is received at
     the downstream LSR with Ethertype 8847 it is looked up in a table
     managed by the downstream router.  Conversely when a packet is
     received at the downstream LSR with Ethertype 8848 it is looked
     up in a table managed by the upstream router.

     In your liaison to the MFA Forum dated 19-23 June 2006 you say,

        T-MPLS is intended to be a separate layer network with respect
        to MPLS. However, T- MPLS will use the same data-link protocol
        ID (e.g. EtherType), frame format and forwarding semantics for
        as those defined for MPLS frames.  T-MPLS and MPLS cannot
        coexist on the same "interface" (for example they could not
        coexist on a single Ethernet VLAN, however they could be
        multiplexed on to a common Ethernet PHY using separate VLANs).

     On the face of it, this statement implies that MPLS and T-MPLS
     are two different things, but that you wish to identify them both
     using the same Ethertype.  The Ethertype is the primary means for
     multiplexing and distinguishing protocols over Ethernet.  The
     Ethertype identifies the protocol entity that will receive a
     packet at the layer above.  VLANs on the other hand are primarily
     intended as a service level interface, allowing multiple virtual
     LANs over a single bridged domain.  .

     If T-MPLS cannot co-exist with MPLS over Ethernet, and T-MPLS is
     in fact a separate layer network, then it should be identified by
     its own Ethertype(s), Clear and unambiguous identification is in
     the best interest of all involved.  In particular, if T- MPLS is
     being architected in such a way that would prevent it from
     acquiring labels by interacting with a shared label manager, then
     separate Ethertypes would guarantee that there is no confusion as
     to which label spaces belong to T-MPLS.

     Note further that if T-MPLS is being architected in such a way
     that it can (or could) interact with a shared label manager and
     could co-exist over the same interface sharing the MPLS label
     spaces with other MPLS applications, then we would welcome use of
     the MPLS Ethertypes.

     We believe that a decision to use the MPLS Ethertypes to point to
     a label space other than as defined by the MPLS RFCs to be
     architecturally unsound and ultimately will prove to be limiting
     to the deployment options available in networks which employ both
     MPLS and T-MPLS.

     Sincerely,

        Loa Andersson 
        Scott Bradner
        Deborah Brungard
        Stewart Bryant
        Adrian Farrel 
        Danny McPherson
        George Swallow

request for comments : Pre-Congestion Notification BOF

MPLS2006 International Conference - Call For Participation

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

request information about PW-TDM-MIB (draft)

Hi all,
I'm trying to configure by SNMP interface the Service Layer for managing 
TDM pseudo wire over Ethernet network (as descibed on TDM over IP
                     methods on draft-ietf-pwe3-tdmoip-05.txt).
In  [PW-MIB] I found the general parameters to set-up manually the PW 
(pwType, pwOwnwe).
In  [PW-TDM-MIB] I found other specific parameter (pwTDMCfgPayloadSize, 
pwTDMCfgRtpHdrUsed, pwTDMCfgTimesStampMode,), but others parameters are 
missing like:
- TDM clock recovery method (local, loop-back timing, adaptive, common 
clock)
-  PW labels of the two directions
-  Ethernet destination addresses

Can you help me to configure this parameters ?

best regards, Daniela Spreafico