Subject: Re: [mpls-tp] comments on draft-ietf-mpls-tp-oam-framework-05

From: Curtis Villamizar <[email-masked]>
Date: Thu, 01 Apr 2010 03:53:37 -0400

In message <[email-masked]>
Greg Mirsky writes:
>  
>  
> Dear Curtis,
> I think I disagree with characterization of Link Bundling in the first
> paragraph of your proposed section 4.6:
> +4.6  Fate sharing considerations for multipath
> +
> +   Multipath techniques are in use today and are expected to continue
> +   to be used in future deployments.  These techniques include
> +   Ethernet Link Aggregations [IEEE 802.1AX], the use of Link Bundling
> +   for MPLS [RFC4201] where the option to spead traffic over component
> +   links is supported and enabled, and the use of ECMP.  Other
> +   techniques may emerge in the future.  These techniques share in
> +   common the characteristic that an LSP may be spread over a set of
> +   component links and therefore be reordered but no flow within the
> +   LSP is reordered (except when very infrequent and minimally
> +   disruptive load rebalancing occurs).
>  
> As I understand, the RFC 4201 prevents from setting LSP that is bigger than
> Maximum LSP B/W among component links for given priority. If that is
> correct, then there would not be situation where LSP is spread over a set of
> component links (obviously, if consider a set of just single component link,
> then your statement is always true). And I'm not sure how ECMP is applicable
> to MPLS-TP (not MPLS in general, but MPLS-TP in particular) and can be
> exercised by it.

Greg,

The exact wording above includes "the use of Link Bundling for MPLS
[RFC4201] where the option to spead traffic over component links is
supported and enabled".

If this capability is supported and enabled, max LSP is set to the
size of the bundle.  All LSP are spread across the bundle.
Implementations that do this treat the bundle the same way they would
tread a LAG.  This allows LAG functionality on non-Ethernet
interfaces, only without the coordination provided by the link
aggregation control protocol in LAG.  The RRO returns the all ones
value of the component used.

You may be right on ECMP.  In practice of two links are exposed to the
IGP as separate an LSP takes one or the other.

> I think that the fact that a particular technology or method are outside of
> MPLS-TP does not exclude them from MPLS deployments (as you've pointed and
> stressed). And I think that if we know that then discussion of such issues
> is outside of scope of this particular document.

In this case it impacts OAM functionality.  Current practice impacts
this new work.  That is the reason to mention it.

Are you simply objecting to the use of link bundle, and ECMP as
examples of multipath?  Or are you objecting to any reference to
multipath including LAG?

> Regards,
> Greg

Curtis

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 1 Apr 2010 11:40:51 -0700

Dear Curtis,
please find my comments in-line highlighted in blue and tagged GIM.

Regards,
Greg

On Thu, Apr 1, 2010 at 12:53 AM, Curtis Villamizar <[email-masked]> wrote:

> size of the bundle.

GIM>>  Section 3.10 of RFC 4201 states that the Maximum LSP Bandwidth
replaces Maximum Bandwidth and "The Maximum LSP Bandwidth of a bundled link
at priority p is defined to be the maximum of the Maximum LSP Bandwidth at
priority p of all of its component links." An LSP, I understand the RFC,
cannot exceed the Maximum LSP Bandwidth and thus will not be spread across
component links. Though Link Bundle per RFC 4201 addresses multipath
(multiple TE links between two nodes, it excludes signaling LSP bigger than
Maximum LSP Bandwidth at given priority p.

>  All LSP are spread across the bundle.
> aggregation control protocol in LAG.

GIM>> I don't see this scenario being allowed by RFC 4201.

> The RRO returns the all ones
GIM>> I recall that Alexander Vainshtein have asked questions regarding
relation between LAG and MPLS-TP but I cannot recall if we have reached any
conclusion. The Link Bundle, from my point, is part of MPLS-TP. ECMP? If we
decide that LAG, in all its applications, is part of MPLS-TP, then I don't
see good reason to keep ECMP out. We'll need to come up with TE aspects of
ECMP bundle and its component links then.

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 11 Apr 2010 01:47:12 -0400

> please find my comments in-line highlighted in blue and tagged GIM.

See inline.

> replaces Maximum Bandwidth and "The Maximum LSP Bandwidth of a bundled
> link at priority p is defined to be the maximum of the Maximum LSP
> Bandwidth at priority p of all of its component links." An LSP, I
> understand the RFC, cannot exceed the Maximum LSP Bandwidth and thus
> will not be spread across component links. Though Link Bundle per RFC
> 4201 addresses multipath (multiple TE links between two nodes, it
> excludes signaling LSP bigger than Maximum LSP Bandwidth at given
> priority p.

The use of the all ones interface requires bending this.  I'm
describing practice.  If Maximum LSP Bandwidth is set to the bandwdith
of the bundle, which *is* allowed in some implementations, then
ingress will signal LSP that are larger then a component.  Providers
that want to take advantage of this can do so.

> GIM>> I don't see this scenario being allowed by RFC 4201.

I'm not sure it matters if its allowed.  This argument went on in 2000
and the all ones interface was put in but the practice of setting
Maximum LSP Bandwidth wasn't put in.

> GIM>> I recall that Alexander Vainshtein have asked questions
> regarding relation between LAG and MPLS-TP but I cannot recall if we
> have reached any conclusion. The Link Bundle, from my point, is part
> of MPLS-TP. ECMP? If we decide that LAG, in all its applications, is
> part of MPLS-TP, then I don't see good reason to keep ECMP out. We'll
> need to come up with TE aspects of ECMP bundle and its component links
> then.

I think you are right that there was no conclusion in that thread.

But you didn't answer my question.  Are you objecting to any mention
of multipath?  Most core IP networks simply cannot be run without
multipath (currently as ECMP and LAG, with link bundle being the LAG
of the non-ethernet link).  I don't think MPLS-TP should completely
excludes a feature that is critical to all large IP providers.  It
would be better to disable the feature by default and document any
"bad things" that would happen were it to be turned on.

> > > Regards, Greg > > > > Curtis

Curtis

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 11 Apr 2010 01:04:56 -0700

Hi Curtis,
my notes in-lined and tagged GIM.

Regards,
Greg

> > > In message <
> [email-masked]>
> > > Greg Mirsky writes:
> > > >
> > > >
> > > > Dear Curtis,
> > > > As I understand, the RFC 4201 prevents from setting LSP that is
> bigger
> > > than
> > > > correct, then there would not be situation where LSP is spread over a
> set
> > > of
> > > > component links (obviously, if consider a set of just single
> component
> > > link,

GIM>> IMO, these "some implementations" need to find way into our documents
along with explanation of ramifications including to DiffServ (that what we
discuss on the other thread). Such practice might be part of MPLS-TP as
packet network, though not necessarily to be part of the packet transport.

> > > > I think that the fact that a particular technology or method are
> outside
> > > of
> > > > MPLS-TP does not exclude them from MPLS deployments (as you've
> pointed
> > > and

GIM>> MPLS-TP does not include IP/MPLS (that is not the statement but my
understanding and it might be not correct).  I don't object to mention of
multipath in MPLS-TP - that would be unreasonable and impractical. Multipath
in MPLS-TP would have specific characteristics, different from IP networks,
perhaps more strict, controlled. And everything that is not in MPLS-TP,
these are not "bad things", will still be in MPLS.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Apr 2010 01:38:51 -0400

Greg,

I appologize for trimming but this was getting long and badly
formated.

Curtis

> GIM>> MPLS-TP does not include IP/MPLS (that is not the statement but
> my understanding and it might be not correct).  I don't object to
> mention of multipath in MPLS-TP - that would be unreasonable and
> impractical. Multipath in MPLS-TP would have specific characteristics,
> different from IP networks, perhaps more strict, controlled. And
> everything that is not in MPLS-TP, these are not "bad things", will
> still be in MPLS.

You might want to check into draft-ietf-mpls-tp-framework-11.txt and
find "3.4.3.4.  IP Transport Service":

  3.4.3.4.  IP Transport Service

   In this example the MPLS-TP network is providing a point-to-point IP
   transport service between CE1, CE2, and CE3, as follows.  One point-
   to-point transport service instance delivers IPv4 packets between CE1
   and CE2, and another instance delivers IPv6 packets between CE1 and
   CE3.

   The processing steps in this case for an IP packet received from CE1
   are:

   A1.  No link-layer-specific processing is performed.

   A2.  The IP packet is extracted from the link-layer frame and
   associated with a Service LSP based on the source MAC address (CE1)
   and the IP protocol version.

   A3.  A transport service encapsulation, consisting of the Service LSP
   label, is associated with the packet.

   A4.  The resulting packet is mapped to a tunnel LSP, the tunnel LSP
   label is pushed, and the packet is transmitted over the outbound
   interface associated with the LSP.

   The steps in the reverse direction, for packets received over a
   tunnel LSP carrying the Service LSP label, are analogous.

That looks to me like IP/MPLS-TP is included in MPLS-TP.