RTGWG,
Below are diffs mostly to address comments about IP & LDP coverage
being in two places and a little redundant. I think those comments
came a while ago from Lucy (in private email) but I refiled the email
and left a comment in the XML and an editor window open to remind
myself. Text on IP&LDP was moved around and consolidated.
In private email a while ago Lucy reminded me that Entropy Label was
changed back to using a reserved label. This is addressed in the very
last diff chunk.
Diff chunk @@ -420,16 +420,16 @@ just reads better IMO. I also snuck
in the deletion of an old comment that explained why a chunk of text
was deleted a long time ago.
BTW- I think we are at the point (long past the point) where most or
all correspondence among co-authors about this set of drafts should Cc
the RTGWG mailing list.
Curtis
Index: draft-so-yong-rtgwg-cl-framework.xml
===================================================================
RCS file:
/home/cvs/CVS-occnc/customers/ietf/rtg-cl/draft-so-yong-rtgwg-cl-framework.xml,v
retrieving revision 1.12
diff -u -w -r1.12 draft-so-yong-rtgwg-cl-framework.xml
--- draft-so-yong-rtgwg-cl-framework.xml 14 Jun 2012 21:39:20 -0000
1.12
+++ draft-so-yong-rtgwg-cl-framework.xml 15 Jun 2012 18:12:21 -0000
@@ -61,7 +61,7 @@
<?rfc inline="yes" ?>
<rfc category="info" ipr="trust200902"
- docName="draft-so-yong-rtgwg-cl-framework-06-preview1">
+ docName="draft-so-yong-rtgwg-cl-framework-06-preview2">
<front>
<title abbrev="Composite Link Framework">
@@ -420,16 +420,16 @@
</t>
<t>
a pseudowire (PW) <xref target="RFC3985" /> identified
- by an MPLS label,
+ by an MPLS PW label,
</t>
<t>
a flow or group of flows within a pseudowire (PW)
- <xref target="RFC6391" /> identified by an MPLS label,
+ <xref target="RFC6391" /> identified by an MPLS flow label,
</t>
<t>
- an entropy flow in an LSP
+ a flow or flow group in an LSP
<xref target="I-D.ietf-mpls-entropy-label" />
- identified by an MPLS label,
+ identified by an MPLS entropy label,
</t>
<t>
all traffic between a pair of IP hosts, identified by an
@@ -632,37 +632,15 @@
When an LSP is signaled using RSVP-TE, the LSP MUST be
placed on the component link that meets the LSP criteria
indicated in the signaling message.
- <!-- deleting - obvious restatement of requirements -
- Since the composite link brings some unique
- characteristics, some signaling protocol extensions are
- expected to facilitate the composite link to place LSP to
- a proper component link. Several cases may be considered
- as below. Signaling extension for configuring such LSP is
- for further study.
- -->
</t>
<t>
When an LSP is signaled using LDP, the LSP MUST be placed on
the component link that meets the LSP criteria, if such a
- component link is available. LDP follows the IGP, therefore
- failure to forward on the IGP path will often result in loss
- of connectivity if the IGP adjacency is not withdrawn when
- an LDP FEC is refused. This is a pathologic case that can
- occur if LDP is carried natively and there is a high volume
- of LDP traffic. This situation can be avoided by carrying
- LDP within RSVP-TE LSP.
- </t>
-
- <t>
- <!-- the following needs to be considered by the WG -->
- LDP traffic engineering is specifically disallowed by <xref
- target="RFC3468" />. It may be possible to support
- multi-topology IGP extensions to accommodate more than one
- set of criteria. If so, the additional IGP could be bound
- to the forwarding criteria, and the LDP FEC bound to a
- specific IGP instance, inheriting the forwarding criteria.
- {Note: WG needs to discuss this.]
+ component link is available. LDP does not support traffic
+ engineering capabilities, imposing restrictions on LDP use
+ of Composite Link. See <xref target="sect.ldp-limitations"
+ /> for further details.
</t>
<t>
@@ -671,12 +649,12 @@
links. The route computing engine may select one group of
component links for a LSP. The routing protocol MUST make
this grouping available in the TE-LSDB. The route
- computation MUST be extended to include only the capacity of
- groups within a composite link which meet LSP criteria. The
- signaling protocol MUST be able to indicate either the
- criteria, or which groups may be used. A composite link
- MUST place the LSP on a component link or group which meets
- or exceeds the LSP criteria.
+ computation used in RSVP-TE MUST be extended to include only
+ the capacity of groups within a composite link which meet
+ LSP criteria. The signaling protocol MUST be able to
+ indicate either the criteria, or which groups may be used.
+ A composite link MUST place the LSP on a component link or
+ group which meets or exceeds the LSP criteria.
</t>
<t>
@@ -1561,7 +1539,7 @@
<t>
<xref target="I-D.ietf-rtgwg-cl-requirement" /> requires
that native IP and native LDP be accommodated. In some
- network, a subset of services may be carried as native IP
+ networks, a subset of services may be carried as native IP
or carried as native LDP. Today this may be accommodated
by the network operator estimating the contribution of IP
and LDP and configuring a lower set of available bandwidth
@@ -1595,6 +1573,11 @@
is a subset).
</t>
+ </section>
+
+ <section anchor="sect.ldp-limitations"
+ title="IP and LDP Limitations">
+
<t>
IP does not offer traffic engineering. LDP cannot be
extended to offer traffic engineering <xref
@@ -1602,11 +1585,35 @@
engineered fallback to an alternate path for IP and LDP
traffic if resources are not adequate for the IP and/or
LDP traffic alone on a given link in the primary path.
- The only option available to LDP is to fail to forward a
- FEC if conditions are not met for that FEC. In either LDP
- DOD mode or DU mode, another path will be used if
- available in a manner similar to a link which is present
- in the IGP but does not have LDP enabled.
+ The only option for IP and LDP would be to declare the
+ link down. Declaring a link down due to resource
+ exhaustion would reduce traffic to zero and eliminate the
+ resource exhaustion. This would cause oscillations and is
+ therefore not a viable solution.
+ </t>
+
+ <t>
+ Congestion caused by IP or LDP traffic loads is a
+ pathologic case that can occur if IP and/or LDP are
+ carried natively and there is a high volume of IP or LDP
+ traffic. This situation can be avoided by carrying IP and
+ LDP within RSVP-TE LSP.
+ </t>
+
+ <t>
+ <!-- the following needs to be considered by the WG -->
+ It is also not possible to route LDP traffic differently
+ for different FEC. LDP traffic engineering is
+ specifically disallowed by <xref target="RFC3468" />. It
+ may be possible to support multi-topology IGP extensions
+ to accommodate more than one set of criteria. If so, the
+ additional IGP could be bound to the forwarding criteria,
+ and the LDP FEC bound to a specific IGP instance,
+ inheriting the forwarding criteria. Alternately, one IGP
+ instance can be used and the LDP SPF can make use of the
+ constraints, such as delay and jitter, for a given LDP
+ FEC. [Note: WG needs to discuss this and decide first
+ whether to solve this at all and then if so, how.]
</t>
</section>
@@ -1905,19 +1912,18 @@
<xref target="I-D.ietf-mpls-entropy-label" />
provides a means for a LER to put an additional label known
as an entropy label on the MPLS label stack. As defined,
- only the LER can add the entropy label and this label must
- be at the bottom of stack.
+ only the LER can add the entropy label.
</t>
<t>
- If the bottom of stack restriction on entropy labels were to
- be relaxed, then core LSR could add entropy labels based on
- deep packet inspection and place the entropy label just
- below the label being acted on. This would be helpful in
- situations where the label stack depth to which load
- distribution can operate is limited by implementation or is
- limited for other reasons such as carrying both MPLS-TP and
- MPLS with entropy labels within the same hierarchical LSP.
+ Core LSR acting as LER for aggregated LSP can add entropy
+ labels based on deep packet inspection and place an entropy
+ label indicator (ELI) and entropy label (EL) just below the
+ label being acted on. This would be helpful in situations
+ where the label stack depth to which load distribution can
+ operate is limited by implementation or is limited for other
+ reasons such as carrying both MPLS-TP and MPLS with entropy
+ labels within the same hierarchical LSP.
</t>
</section>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
