Document Action: 'Multiprotocol Label Switching Transport Profile Survivability Framework' to Informational RFC

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

 



The IESG has approved the following document:

- 'Multiprotocol Label Switching Transport Profile Survivability 
   Framework '
   <draft-ietf-mpls-tp-survive-fwk-06.txt> as an Informational RFC


This document is the product of the Multiprotocol Label Switching Working Group. 

The IESG contact persons are Stewart Bryant and Adrian Farrel.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-fwk-06.txt

Technical Summary

  This document specifies the taxonomy for MPLS-TP survivability,
  the surviability architecture and key components need to meet
  survivability requiremetns. Network survivability is the network's
  ability to recover traffic delivery following the failure or
  degradation of traffic caused by a network fault or a denial
  of service attacks. Survivability isa critical characteristic of
  reliable services in transport networks.

  The MPLS transport profiles are designed to be consistent with
  existing transport network operations and management models.

  Some of the MPLS transport profile recovery mechanisms do not
  depend on a control plane but use OAM mechanisms or management
  actions to trigger recovery actions.

  MPLS and GMPLS protection mechanisms are applicable in for the
  MPLS transport profiles. It is also be possible to provision and
  manage the related protection entities and functions defined in MPLS
  and GMPLS using the management plane. Regardless of whether
  an OAM, management, or control plane initiation mechanism is used,
  the protection-switching operation is a data-plane operation.


Working Group Summary

  Since the document is an output from the MPLS-TP project it is the
  joint output of several IETF working groups and Qustion 9, 10, 12 and
  14 of ITU-T SG15.

Document Quality

The document is well reviewed in all the groups mentioned above.

Personnel

Loa Andersson is Document Shepherd for this document.
Stewart Bryant is the Responsible Area Director.

RFC Editor Note

===========
1) Section 1.2: r/in[RFC4427]/in [RFC4427]

2) Section 2: I a verb is missing:

 The terms "defect" and "failure" are used interchangeably to
 indicate any defect or failure in the sense that they defined in
                                                      ^ are
 [G.806].

3) Section 4.1: r/OAM mechanisms ,/OAM mechanisms,

4) Section 4.1.3: Add period: [MPLS-TP-OAM-Framework].
                                                     ^

5) Section 4.4.2: Add period: (1:n or m:n).
                                          ^

6) Section 4.4.3: Add period: service degradation.
                                                 ^

7) Section 4.7: Missing ): (see Section
   4.5 associated with the protection function. 

8) Section 4.7.6: Extra "1"?:

 Additionally, note that the shared-protection resources could be used
 1 to carry extra traffic,  for example, in Figure 4, an LSP JPQRK
 ^ ?

9) Section 6.1.1: Missing period: etc.).
                                       ^

10) Section 6.1.2: Missing periods (X2): recovery entity.
                                                       ^

11) Section 6.4: r/(Maintenance Group Intermediate Points (MIPs)/MIPs
(Maintenance Group Intermediate Points)

12) Section 6.5: r/t1he/the

===========


Add a new last para to section 4.3.2

In an MPLS-TP network, the degree to which a resource is shared 
between LSPs is a policy issue. This policy may be applied to the
resource or to the LSPs, and may be pre-configured, configured 
per LSP and installed during LSP establishment, or may be 
dynamically configured.

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

In Section 4.7.4

Old
An in-band, data-plane protocol for use in MPLS-TP networks will 
be documented in [MPLS-TP-Linear-Protection] for this purpose.

New 
An in-band, data-plane protocol for use in MPLS-TP networks will 
be documented in [MPLS-TP-Linear-Protection] for linear protection
(ring protection is discussed in Section 4.8 of this document).

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

In Section 1.4. Scope of this Framework

Please change all instances of the word "level" to "grade"

In Section 4 Functional Architecture (main section)

Please change the word "level" to "grade"

In Section 4.1.1.  Operator Control

Please change the word "level" to "grade"

In Section 4.3 Level of Recovery (main section)

Please change the word "level" to "grade"

In Section 4.3.2 Shared protection

Please change the word "level" to "grade"

In Section 4.4.1 Link-Level Protection

OLD
   Link-level protection offers the following levels of protection:
NEW
   Link-level protection offers the following grades of protection:
END

In Section 4.4.2.  Alternate Paths and Segments

OLD
   Different levels of protection may be provided:
NEW
   Different grades of protection may be provided:
END

In Section 4.4.3.  Protection Tunnels

OLD
   Different levels of protection may be provided:
NEW
   Different grades of protection may be provided:
END

In Section 4.6.  Protection in Different Topologies

OLD
concatenation of recovery domains, each providing some level of
recovery in part of the network.
NEW
concatenation of recovery domains, each providing some grade of
recovery in part of the network.
END

In Section 4.9.  Recovery in Layered Networks
Please change all instances of the word "level" to "grade". 
However please DO NOT change "Layered" in the title of this section.

In Section 7.  Pseudowire Recovery Considerations

OLD
The pseudowire may, itself, require a level of protection, in order
to meet the service-level guarantees of its SLA.  
NEW
The pseudowire may, itself, require protection, in order
to meet the service-level guarantees of its SLA.  
END

===============================
Change title of section

OLD
4.2.  Elements of Recovery
NEW
4.2.  Recovery Scope
END

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

In Section 4.2.1.  Span Recovery

OLD
   Moving the protected LSP to another TE link between the same pair of
   neighbors is a form of segment recovery and is described in Section
   4.2.2.
NEW
   Moving the protected LSP to another TE link between the same pair of
   neighbors is a form of segment recovery and not a form of span
recovery.
   Segment Recovery is described in Section 4.2.2.
END

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

In Section 4.3.  Levels of Recovery

New last paragraph

The selection of the recovery grade and schemes to satisfy the 
service grades for an LSP using available network resources is 
subject to network and local policy and may be pre-designated 
through network planning or may be dynamically determined 
by the network.

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

In Section 4.4.3.  Protection Tunnels

OLD
   A protection tunnel is a hierarchical LSP that is pre-provisioned in
   order to protect against a failure condition along a sequence of
   spans in the network. 
NEW
   A protection tunnel is pre-provisioned in
   order to protect against a failure condition along a sequence of
   spans in the network. This may be achieved using LSP heirarchy. 
END

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

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux