Subject: draft-so-yong-rtgwg-cl-framework-04.txt

From: Curtis Villamizar <[email-masked]>
Date: Fri, 08 Jul 2011 14:56:53 -0400

The is regarding draft-so-yong-rtgwg-cl-framework-04.txt

As a co-author I am partly to blame for not speaking up before the
latest draft got published.  I appologize to other co-authors for
neglecting to provide comments in a timely manner.
#include "std.excuses"  // you've heard it all before

Some brief comments are below.  These are comments on the text that is
provided.  That said, I think the biggest problem with this draft is
the ommission of any mechanisms (not protocols specifics) that would
normally be expected of an architecture document, including both
mechanisms supported by existing protocols, and mechanisms that will
require protocol extensions.  I will send a separate email on details
of that sort that could be added.

Curtis

Old:

   Single link and LAG based link bundle have been widely used in
   today's MPLS networks.

New:

   In today's MPLS networks, single links are used, Ethernet Link
   Aggregation is used [IEEE 802.1AX-2010] and Link Bundling is used
   [RFC4201].

Old:

      Specific protocol solutions are outside the scope of this
      document.

Please delete prior one sentence paragraph.  Note that solutions are
what architecture docoments are all about.  The protocol specifics are
omiteed but the types of mechanisms are outlined.

Old:

   Component Link:  A point-to-point physical or logical link that
-  preserves ordering in the steady state.  A component link may have
   transient out of order events, but such events must not exceed the
   network's specific NPO.  Examples of a physical link are: Lambda,
   Ethernet PHY, and OTN.  Examples of a logical link are: MPLS LSP,
   Ethernet VLAN, and MPLS-TP LSP.

New:

   Component Link:  A point-to-point physical or logical link that
+  preserves ordering among flows in the steady state.
+  A component link may have
   transient out of order events, but such events must not exceed the
   network's specific NPO.  Examples of a physical link are: Lambda,
   Ethernet PHY, and OTN.  Examples of a logical link are: MPLS LSP,
   Ethernet VLAN, and MPLS-TP LSP.

Note that a component link preserves orders among flows, not order
among packets received.  A composite link may be a component link and
the server layer composite link (which is acting as a component link)
may not preserve order among LSP that don't need to have order
preserved.

Old:

   Flow identification:  The label stack and other information that
   uniquely identifies a flow.  Other information in flow
   identification may include an IP header, PW control word, Ethernet
   MAC address, etc.  Note that an LSP may contain one or more Flows or
   an LSP may be equivalent to a Flow.  Flow identification is used to
   locally select a component link, or a path through the network
   toward the destination.

New:

   Flow identification: A microflow is defined in RFC 2475 within the
   context of the Internet Protocol.  MPLS supports non_IP protocols
   as well as IP.  In many networks non-IP protocols are encapsulated
   within pseudowires using a pseudowire control word.  In such cases
   the flow identification may include a potential IP header
   [RFC4928].  The MPLS label stack may also be used to identify
   flows.

Old:

   Network Performance Objective (NPO):  Numerical values for
   performance measures, principally availability, latency, and delay
   variation.  See Appendix A for more details.

Note: there is no Appendix A.  There are no appendices at all.

Note: IGP-TE should be defined in the terminology section.  Some new
text could be:

   IGP-TE: OSPF and ISIS are both link state routing protocols used in
   the role traditionally known as an interior gateway protocol (IGP).
   Both OSPF and ISIS have extensions for traffic engineering which
   are known as OSPF-TE and ISIS-TE.  For cases where either OSPF-TE
   or ISIS-TE could be used, the abbreviation IGP-TE is used.

Old:

   In IGP-TE, a composite link is advertised as a single TE link
   between two connected routers. This is similar to a link bundle
   [RFC4201]. Link bundle applies to a set of homogenous component
   links. Composite link allows homogenous and non-homogenous component
   links. In order for route computing engine to calculate a proper
   path for a LSP, it is necessary for composite link to advertise the
   summarized available BW as well as the maximum BW for single LSP. If
   a composite link contains some non-homogeneous component links, the
   composite link also need to advertise the summarized BW and the
   maximum BW for single LSP per each homogeneous component link group.
   The protocol extension for composite link advertisement will be
   described in the separated draft.

Note: Since framework documents never specify protocol extensions, the
last sentence can be dropped.  These few sentences need to be
modified:

Old (excerpt from above):

   In order for route computing engine to calculate a proper
   path for a LSP, it is necessary for composite link to advertise the
   summarized available BW as well as the maximum BW for single LSP. If
   a composite link contains some non-homogeneous component links, the
   composite link also need to advertise the summarized BW and the
   maximum BW for single LSP per each homogeneous component link
   group.

New:

   To support route computation with homogenous component links,
   bandwidth charterizations such as Available Bandwidth and Maximum
   LSP Bandwidth [RFC4201] are advertised for a link bundle.  To
   support route computation with non-homogenous component links, it
   is necessary to advertise provide bandwidth charterizations for
   each group of homogeneous component links.

Note: The terminology section should defined homogeneous component
links and non-homogeneous component links.  I think heterogeneous
might be a good replacement for non-homogeneous.  [Any english majors
want to weigh in on this?]

Old sentence:

   Signaling protocol does not allow signaling an aggregated LSP where
   its BW may be larger than the capacity of any component
   links. [ENTROPY]

Note: [ENTROPY] does not address the issue in link bundling that the
Maximum LSP bandwidth can be set only to the reflect the component
link with the most available bandwidth, or by stretching the spec a
bit beyond what has been defined, if the "all ones" compoent is always
used, then set the Maximum LSP bandwidth to the same value as the
"available bandwidth" for the entire link bundle.  In that sense,
[ENTROPY] does not address the issue mentioned in the sentence where
it is cited.

Old sentence:

   If two unidirectional LSPs are used to construct a component link,
   they MUST be co-routed.

New sentence:

   Co-routed bidirectional LSP must be supported.

LSP may be unidirectional, associated bidirectional (two
unidirectional LSP, or corouted bidirectional.  There is no such thing
as corouted unidirectional LSP.  There is no way to coordinate the
make-before-break reroute of two unidirectional LSP.

There is also no reason to constrain the LSPs on a composite link to
be corouted.  It is certainly an option that some providers will be
interested in, but not an architectural requirement.

Old sentences:

   The protocol extension for singling
   component link parameter is for further study. This capability is
   not supported in current protocol because a link bundle contains a
   set of homogenous links.

These can be dropped.

Old sentences:

   In an often case, a component link is configured to carry traffic
   under normal operation; under some situation, operator may want to
   configure a component link as a link for local recovery purpose, in
   which the composite link should not count the component link TE
   parameters into the composite link TE parameters for the
   advertisement. However, the composite link may send the traffic
   over the component link when a component link failure occurs.

This needs to be reworded.  It should also be at least a separate
paragraph.  It might be useful to create a separate subsection to
discuss protection scenarios and their applicability.  For example, in
a WDM system, if the entire CL fails all at once, it doesn't make much
sense to have a spare component (which also fails).  If a composite
link makes use of many components on two fibers, then some resilence
exists, but a single spare component would have little value.

This is also a new requirement.  New requirements are not supposed to
be introduced in the framework document.

There are existing techniques which handle this very well.  For
example, if capacity is reduced, then the lowest priority LSPs
(holding priority as defined in RFC3209) are preempted.  A more
friendly approach is to use soft preemption and make use of diffserv
based QoS during any interim congestion that may occur.

Old:

   When a component link is supported by lower layer network (third
   component link in figure 2), the control plane that the composite
   link resides is able to interoperate with the GMPLS or MPLS-TP
   control plane that lower layer network uses for component link
   addition and deletion.[CL-REQ]

Is this meaningless?  If the control plane in both cases *are* MPLS
based, then they should interoperate fine.  Is this yet another
requirement in the framework?  In any case, the meaning of the above
paragraph is unclear.

Old:

   It is possible for operator to configure one or multiple interface
   (s) over a composite link.

Again, please explain.  What is this supposed to mean?

   When a bi-directional LSP request is signaled over a composite
   link, if the request indicates that the LSP must be placed on the
   same component link, the routers of the composite link MUST place
   the LSP traffic in both directions on a same component link.

This constraint can be enforced only for a bidirectional co-routed LSP
set up using the non-all-ones component link in a link bundle.

Old:

   Individual component link may fail independently. Upon component
   link failure, a composite link needs to perform local recovery,
   i.e.  use some available capacity in other component link to carry
   impacted traffic. Composite link may use LDP or RSVP-TE signaling
   protocol to facilitate the recovery process between two routers
   that composite resides. To avoid looped crankback, during the local
   recovery process, the composite link should advertise its available
   BW as zero; after finishing the local recovery, it should update
   its proper available BW in IGP.

There is actually no need for this.  Components of link bundles have
failed for a decade now.  As I mentioned above, preemption is used if
the link bundle does not have adequate capacity to carry what it used
to be carrying.  If the available bandwidth truly is zero, then
preemption is needed.  If not, then details in the RRO change in
subsequent RESV messages.  Changing contents of the RESV is a normal
part of RSVP refresh.  For bidrectional LSP, the RRO in both the PATH
and RESV change.  For LSP using the all-ones component, no signaling
change is needed.

Old:

   A component link in a composite link may fail independently. The
   routers at a composite link MUST maintain each component link
   status. Two routers may use the control plane to sync up a
   component link state. When a component link fails, the routers of a
   composite link MUST re-assign impacted flows to other active
   component links in minimal disruptive manner. This is local
   function and do not incorporate with LSP head-end routers. When a
   composite link is not able to transport all flows, it preempts some
   flows based upon local management configuration and informs the
   control plane on these preempted flows. The composite link MUST
   support soft preemption [RFC5712]. This action ensures the
   remaining traffic is transported properly. Note: as mentioned in
   section 4, in order to prevent lopped crankback symptom, when
   composite link performs local recovery process, it should advertise
   its available BW as zero; when the local process completes, the
   composite link should update its link state with the proper
   available BW.

This paragraph is in the data plane section.  It specifies control
plane functionality which is described somewhat differently in the
control plance section.  Maybe a new section is needed to describe
protection mechanisms.  This for the most part is describing the
existing behavior for link bundles.

Old:

   Operator may want to perform an optimization function such as load
   balance or energy saving over a composite link, which may conduct
   some traffic moving from one component link to another.

Are these energy savings optimizations in any way related to the
MPLampS architecture [RFC3251]?  If not, then please explain.

---

From: "So, Ning" <[email-masked]>
Date: Fri, 08 Jul 2011 19:11:03 +0000

Curtis,

Glad to see they unlock you from the desk chain and let you do some
"fun" work once in a while :)  We will try to update the draft with your
input.  If we can get your other e-mail this weekend, we might  be able
to beat the Monday deadline.  

Best regards,
 
Ning So
Network Evolution Planning
Verizon, Inc.
(office) 972-729-7905
(Cell) 972-955-0914
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Curtis Villamizar
Sent: Friday, July 08, 2011 1:57 PM
To: [email-masked]
Subject: draft-so-yong-rtgwg-cl-framework-04.txt

Some brief comments are below.  These are comments on the text that is
provided.  That said, I think the biggest problem with this draft is the
ommission of any mechanisms (not protocols specifics) that would
normally be expected of an architecture document, including both
mechanisms supported by existing protocols, and mechanisms that will
require protocol extensions.  I will send a separate email on details of
that sort that could be added.

Curtis

Old:

New:

Old:

Old:

New:

Note that a component link preserves orders among flows, not order among
packets received.  A composite link may be a component link and the
server layer composite link (which is acting as a component link) may
not preserve order among LSP that don't need to have order preserved.

Old:

New:

Old:

Old:

New:

Note: The terminology section should defined homogeneous component links
and non-homogeneous component links.  I think heterogeneous might be a
good replacement for non-homogeneous.  [Any english majors want to weigh
in on this?]

Old sentence:

Note: [ENTROPY] does not address the issue in link bundling that the
Maximum LSP bandwidth can be set only to the reflect the component link
with the most available bandwidth, or by stretching the spec a bit
beyond what has been defined, if the "all ones" compoent is always used,
then set the Maximum LSP bandwidth to the same value as the "available
bandwidth" for the entire link bundle.  In that sense, [ENTROPY] does
not address the issue mentioned in the sentence where it is cited.

Old sentence:

New sentence:

LSP may be unidirectional, associated bidirectional (two unidirectional
LSP, or corouted bidirectional.  There is no such thing as corouted
unidirectional LSP.  There is no way to coordinate the make-before-break
reroute of two unidirectional LSP.

There is also no reason to constrain the LSPs on a composite link to be
corouted.  It is certainly an option that some providers will be
interested in, but not an architectural requirement.

Old sentences:

These can be dropped.

Old sentences:

This needs to be reworded.  It should also be at least a separate
paragraph.  It might be useful to create a separate subsection to
discuss protection scenarios and their applicability.  For example, in a
WDM system, if the entire CL fails all at once, it doesn't make much
sense to have a spare component (which also fails).  If a composite link
makes use of many components on two fibers, then some resilence exists,
but a single spare component would have little value.

This is also a new requirement.  New requirements are not supposed to be
introduced in the framework document.

There are existing techniques which handle this very well.  For example,
if capacity is reduced, then the lowest priority LSPs (holding priority
as defined in RFC3209) are preempted.  A more friendly approach is to
use soft preemption and make use of diffserv based QoS during any
interim congestion that may occur.

Old:

Old:

Old:

There is actually no need for this.  Components of link bundles have
failed for a decade now.  As I mentioned above, preemption is used if
the link bundle does not have adequate capacity to carry what it used to
be carrying.  If the available bandwidth truly is zero, then preemption
is needed.  If not, then details in the RRO change in subsequent RESV
messages.  Changing contents of the RESV is a normal part of RSVP
refresh.  For bidrectional LSP, the RRO in both the PATH and RESV
change.  For LSP using the all-ones component, no signaling change is
needed.

Old:

This paragraph is in the data plane section.  It specifies control plane
functionality which is described somewhat differently in the control
plance section.  Maybe a new section is needed to describe protection
mechanisms.  This for the most part is describing the existing behavior
for link bundles.

Old:

Are these energy savings optimizations in any way related to the MPLampS
architecture [RFC3251]?  If not, then please explain.

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

---

From: Alia Atlas <[email-masked]>
Date: Fri, 8 Jul 2011 15:32:21 -0400

Curtis,

Yes, my problem with the draft is that it still doesn't propose any
mechanisms for implementing the requirements.  This version has more
content - but not as much as I'd like to see, particularly considering
how long work on composite-links has been happening.

I look forward to a new version.

Alia

---

From: Lucy yong <[email-masked]>
Date: Fri, 08 Jul 2011 20:01:12 +0000

Alia and Curtis,

This is indeed a long work. In very early work, some mechanisms were proposed and were considered as local implementation that should not be standardized.

With this encourage now, I am fine to include some mechanisms.

Regards,
Lucy

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alia Atlas
> Sent: Friday, July 08, 2011 2:32 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: draft-so-yong-rtgwg-cl-framework-04.txt
> 
> Curtis,
>

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 09 Jul 2011 14:23:05 -0400

In message <[email-masked]>
Lucy yong writes:
>  
> Alia and Curtis,
>  
> This is indeed a long work. In very early work, some mechanisms were
> proposed and were considered as local implementation that should not
> be standardized.
>  

Lucy,

Just to be clear about this.

What was proposed in the distant past was protocol extensions with no
clear requirements and inadequately stated semantics.  It was not
clear what those extensions were trying to accomplish and it was not
clear what mechanisms were being proposed.  We definitely don't want a
repeat of that.

A framework document should propose general mechanisms for
accommodating the requirements outlined in a requirements document.
Where there is consensus on a single mechanism, the framework document
can list only one mechanism or list mechanisms that were considered
and rejected as well as the mechanism chosen.  For brevity, were there
was no controversy, it is best to provide only the mechansim selected.

In rare cases where it proves exceedingly difficult to acheive
concensus on a single mechanism, it is OK to list more than one with
the selection deferred until the insights of more implementation or
deployment experience is available.  This should be avoided if at all
possible.

A framework document should not propose protocol extensions.  It may
however indicate protocols on which extension will be built, and
indicate the general nature of the extensions and which requirements
will be addressed by specific types of extensions.

Note that consensus as alway means working group and IETF consensus.
It is up to the work group chairs to determine if lack of comment
indicates lack of objection and implies consensus or if lack of
comment indicates a lack of interest among vendors and providers.

Curtis