Subject: retry: interest in composite links

From: Alia Atlas <[email-masked]>
Date: Wed, 10 Nov 2010 00:23:14 -0500

I would like to better understand the interest and enthusiasm for the
composite links work.

Do you:
    a) Agree/disagree that the problem exists and is interesting?
    b) Look to it to solve existing known issues in your networks (or
those of your customers)?
    c) Plan to actively contribute by doing timely reviewing and
commenting on drafts?
    d) Intend to submit related solutions architecture drafts to meet
the requirements?
    e) I'm just watching - do you have more popcorn?

What timeframe do you want to see this work move along in?
   i) Yesterday would have been good...
  ii) Can we reach consensus on an implementable solution in the next year?
 iii) It'll take years - and that's ok.
 iv) It's supposed to complete sometime?

There has been very little discussion on the mailing list.  More is
the best way of helping progress
to occur between meetings.

Thanks,
Alia

P.S.  Sorry for the missend.

---

From: Tony Li <[email-masked]>
Date: Wed, 10 Nov 2010 13:31:12 +0800

>    a) Agree/disagree that the problem exists and is interesting?

Agree.

> those of your customers)?

Yes.  We are coming to an interesting point where our usual economics for link upgrades no longer apply.  Parallelism will reign.  Simple link bundling will NOT suffice in the long term.

>    c) Plan to actively contribute by doing timely reviewing and

Yes.

>    d) Intend to submit related solutions architecture drafts to meet

Some, but I'm hoping not to do everything myself.

>    e) I'm just watching - do you have more popcorn?

I'm in Beijing, so moon cakes or chasu bao, please.  ;-)

> iv) It's supposed to complete sometime?

i) There are numerous implementation changes to be made.

Tony

---

From: "Mcdysan, David E" <[email-masked]>
Date: Wed, 10 Nov 2010 01:16:20 -0500

As a co-author, my response may be biased, but here it is. :)

Thanks,

Dave

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Alia Atlas [[email-masked]]
Sent: Wednesday, November 10, 2010 12:23 AM
To: [email-masked]
Subject: retry: interest in composite links

Do you:
    a) Agree/disagree that the problem exists and is interesting?
YES
    b) Look to it to solve existing known issues in your networks (or
those of your customers)?
YES
    c) Plan to actively contribute by doing timely reviewing and
commenting on drafts?
YES
    d) Intend to submit related solutions architecture drafts to meet
the requirements?
YES. Composite link framework.
Some solution drafts are already emerging, ones which cite this requirements draft are:
- http://tools.ietf.org/id/draft-wang-ccamp-latency-te-metric-01.txt
- 

Other drafts are emerging that may meet some of the requirements, and I suggest that people interested in this topic take a look at them and comment:
- http://tools.ietf.org/id/draft-zhang-ccamp-srlg-fa-configuration-01.txt
- http://tools.ietf.org/id/draft-polk-tsvwg-intserv-multiple-tspec-05.txt
- http://tools.ietf.org/id/draft-kompella-mpls-entropy-label-01.txt
- http://tools.ietf.org/id/draft-kompella-mpls-rsvp-ecmp-00.txt

YES.
I hope so.
Unfortunately, that is increasingly becoming the IETF way. :(

Thanks,
Alia

P.S.  Sorry for the missend.
_______________________________________________
rtgwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: "Mcdysan, David E" <[email-masked]>
Date: Wed, 10 Nov 2010 01:43:54 -0500

I forgot to include another draft that is also a potential solution to some composite link requirements:

http://tools.ietf.org/id/draft-yong-pwe3-lfc-fat-pw-01.txt

Thanks,

Dave

________________________________________
From: Mcdysan, David E
Sent: Wednesday, November 10, 2010 1:16 AM
To: Alia Atlas; [email-masked]
Subject: RE: retry: interest in composite links

Thanks,

Dave

Do you:

Thanks,
Alia

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Wed, 10 Nov 2010 17:42:15 +1100

>    a) Agree/disagree that the problem exists and is interesting?

't

> those of your customers)?

't

>    c) Plan to actively contribute by doing timely reviewing and

't 

>    d) Intend to submit related solutions architecture drafts to meet

't

>  ii) Can we reach consensus on an implementable solution in the next year?

't

> P.S.  Sorry for the missend.

---
李柯睿
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc

---

From: Yong Lucy <[email-masked]>
Date: Wed, 10 Nov 2010 07:41:51 -0600

Alia,

Thank you for posting these questions. My reply is inline.

Lucy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alia Atlas
> Sent: Tuesday, November 09, 2010 11:23 PM
> To: [email-masked]
[LY] agree.
>     c) Plan to actively contribute by doing timely reviewing and
[LY] Yes.
>     d) Intend to submit related solutions architecture drafts to meet
[LY] Co-author for framework draft.
>   ii) Can we reach consensus on an implementable solution in the next
year?
[LY] Yes, if the group seriously works on it.
>  iv) It's supposed to complete sometime?

[LY] Lucy

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 10 Nov 2010 22:30:56 -0500

Alia,

Did you want to mention "interest in composite links" as described in
draft-ietf-rtgwg-cl-requirement-02?  Or was this interest in CL but
not necessarily as defined in this draft?  I think the former.

>     a) Agree/disagree that the problem exists and is interesting?

Yes.  But there are two problems while you state "problem" singular.
One is enforcing end-to-end delay bounds and the other is the capacity
issue that is driving multipath.  The WG problem is that we have mixed
the two and not been clear and concise enough in stating either one.
We've argued a few fine points to the point that it has lowered the
S/N ratio on this list and that may not have helped.

> those of your customers)?

A customer (singular) has indicated that this is important.

>     c) Plan to actively contribute by doing timely reviewing and

I'm an author and I do plan to continue to contribute.  Work has got
in the way of IETF activity for me in the last few months.  Sorry I
didn't make this meeting.

>     d) Intend to submit related solutions architecture drafts to meet

I think that
http://datatracker.ietf.org/doc/draft-villamizar-mpls-tp-multipath/ is
relevant to one of the two problems in this work, the capacity
problem.  There have been no comments on that draft in MPLS or
MPLS-TP.

There is work in CCAMP to support delay as a metric.

>     e) I'm just watching - do you have more popcorn?

A little of that lately.

>  iv) It's supposed to complete sometime?

draft-villamizar-mpls-tp-multipath reflects considerations in our
current work (on next gen product).  Not sure what we need to do for
the delay bounds but the CSPF mods to support a delay bounds for SLA
purpose is not difficult to do.

Another part of the WG problem is that a particular solution was at
one point being pushed with no clear requirements.  We have attempted
at least to separate defining the requirements from specifying the
solution.  The next step is framework and we can try to determine what
signaling bits need to do to support a solution, leaving placement of
the protocol bits and other such detail to after the framework.

> to occur between meetings.

I agree that there is way too little discussion on the list.  So much
so that it is not certain that anyone cares about this work outside of
the small number of authors.  That to me is a bad sign.

It hard to judge concensus over this thunderous yawn.  Is it really
greate and no complaint (I personnaly doubt it) or do the majority of
people on this list think it is unimportant enough to ignore it?

It is also hard to judge the quality of this document based on so
little input from the list (none really since this last one came out).

Thanks for asking.

Curtis

---

From: Alia Atlas <[email-masked]>
Date: Thu, 11 Nov 2010 23:43:17 -0500

Curtis,

I agree that we are looking at at least 2 problems whose requirements
are mingled.
The issue is to get them specified clearly enough to see the
appropriate interactions.
I've put out this poll to attempt to judge consensus and interest.
The silence is noticeable.

The drafts that you and Dave have mentioned are relevant - but had not
been brought up
on the mailing list before.  If it is hard to track the activity and
where it is happening, we
will lose the interest of more people.

I would be happy to see, after this IETF, a posting of pointers, the
abstract, and perhaps
an outstanding issue or point to start conversations.

I agree that we're not ready for protocol solution bits - but I do
think it is time to discuss
various solution frameworks so that they can be compared and contrasted.

Thanks :-)
Alia

---

From: "So, Ning" <[email-masked]>
Date: Tue, 16 Nov 2010 20:15:09 +0000

Best regrads,
 
Ning So
Network Evolution Planning
Verizon, Inc.
(office) 972-729-7905
(Cell) 972-955-0914
Lucy,

Tony gave a convincing argument in the meeting on not aggregating the
component links in IS-IS.  You mentioned that it might not be the case
under some other circumstances.  Could you please shed some light on
that so we can make the decision on the Requirement draft and move it
forward?  Thanks.

Ning

---

From: Yong Lucy <[email-masked]>
Date: Tue, 16 Nov 2010 14:37:55 -0600

Link bundle [RFC4201] is used to bundle homogenous component links and
advertise them as a single logical link. The motivation of the link bundle
is to reduce LSAs, simplify route computation, and make routing protocol
scalable. Each component link may have different loads. There is no need to
advertise each component link available BW as long as the largest allowed
LSP BW is advertised in the link bundle.

Without component link announcement aggregation, route announcement and
computation may raise scalability concern.

Lucy

> From: So, Ning [mailto:[email-masked]]
> Sent: Tuesday, November 16, 2010 2:15 PM
> To: Yong Lucy
> Cc: [email-masked]
> Subject: Question on component link announcement aggregation
> 
> 
> 
> 
> Best regrads,
> 
> Ning So

---

From: Yong Lucy <[email-masked]>
Date: Tue, 16 Nov 2010 16:56:38 -0600

Ning,

Given an example to show the concern in routing:
if there are routers A, B, C, and D, and 20 component links  (route
adjacencies) between A-B, B-C, and C-D, respectively. Without announcement
aggregation, each router has to maintain a large number of link state table,
each router will receive SLAs from each component link since LSA is flooded;
further more, this will cause much more process in route computing. From A
to D, there are 20*20*20 possible paths.

Regards,
Lucy

> From: Yong Lucy [mailto:[email-masked]]
> Sent: Tuesday, November 16, 2010 2:38 PM
> To: 'So, Ning'
> Cc: [email-masked]'
> Subject: RE: Question on component link announcement aggregation
> 
> scalable. Each component link may have different loads. There is no need
> to advertise each component link available BW as long as the largest
> allowed LSP BW is advertised in the link bundle.
>

---

From: Tony Li <[email-masked]>
Date: Wed, 17 Nov 2010 09:42:05 +0900

Hi Lucy,

> computation may raise scalability concern.

The situation is not analogous because we are intentionally trying to support bundling of heterogeneous, not homogenous links.  Because component links have different properties (BW, delay, delay variation) and we will explicitly need to compute paths with multiple requirements among this vector, we will need detailed information.

To again present an extreme example, suppose that we have a composite link that has a T1 in parallel with a high bandwidth satellite link.  The T1 has a BW of 1.5Mb/s and a delay of 20ms.  The satellite link has a BW of 100Mb/s and a delay of 2s.  If we aggregate this, we can only present one number for BW and one number for delay.  No matter which way we do this, we will end up misrepresenting the situation and end up making incorrect path computations.  For example, if we abstract the link as (100Mb/s, 20ms) and we need a 10Mb/s path with 20ms delay, we would incorrectly compute the path.  This forces us into crankback.

> to D, there are 20*20*20 possible paths.

We can either explore those paths with the router's CPU using local memory, or we can do so with crankback at signaling time.  There are 8,000 possible paths in those three hops.  Path exploration with the CPU will take 10s of microseconds per path.  With crankback and signaling, it will take 10s of milliseconds per path.  

Which do you prefer?

IMHO, CPU and memory are cheap and well worth it to make good use of much more expensive physical links.  This still scales _reasonably_ well, because the service provider controls the complexity of the network and the amount of CPU and memory available.  I would _NOT_ recommend this approach if we were talking about inter-domain routing.

Tony

---

From: "So, Ning" <[email-masked]>
Date: Wed, 17 Nov 2010 14:23:55 +0000

Tony and Lucy,

I see applications in both of your points.  

On one hand, what Lucy mentioned is a very practical limitation in the
current network.  For example, the adjacency limitation on our current
MPLS backbone that can use CL capability immediately has adjacency
limitation far less than 100 per router, often far less than 50 (I can
tell you the specific CISCO numbers in private).  It is an existing
limitation that has already negatively impacted our network design and
traffic engineering capability and efficiency.  Advertising large
quantity of component links without aggregation will not scale in this
case.  Please also keep in mind that CPU and memory improvement often
requires major hardware upgrade, which all major carrier would prefer
not to do if possible.  In addition, the capacity growth on the backbone
may very well out pace the hardware improvement.

On the other hand, what you have stated is also a very valid case in
many applications.

What I propose is to change the current language in the Requirement and
make aggregated announcement optional, so that the carriers can use
either based on the actual application in the filed.  Would that be
acceptable?  

Best regrads,
 
Ning So

-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
Sent: Tuesday, November 16, 2010 6:42 PM
To: Yong Lucy
Cc: So, Ning; [email-masked]
Subject: Re: Question on component link announcement aggregation

Hi Lucy,

> computation may raise scalability concern.

The situation is not analogous because we are intentionally trying to
support bundling of heterogeneous, not homogenous links.  Because
component links have different properties (BW, delay, delay variation)
and we will explicitly need to compute paths with multiple requirements
among this vector, we will need detailed information.

To again present an extreme example, suppose that we have a composite
link that has a T1 in parallel with a high bandwidth satellite link.
The T1 has a BW of 1.5Mb/s and a delay of 20ms.  The satellite link has
a BW of 100Mb/s and a delay of 2s.  If we aggregate this, we can only
present one number for BW and one number for delay.  No matter which way
we do this, we will end up misrepresenting the situation and end up
making incorrect path computations.  For example, if we abstract the
link as (100Mb/s, 20ms) and we need a 10Mb/s path with 20ms delay, we
would incorrectly compute the path.  This forces us into crankback.

> to D, there are 20*20*20 possible paths.

We can either explore those paths with the router's CPU using local
memory, or we can do so with crankback at signaling time.  There are
8,000 possible paths in those three hops.  Path exploration with the CPU
will take 10s of microseconds per path.  With crankback and signaling,
it will take 10s of milliseconds per path.  

Which do you prefer?

IMHO, CPU and memory are cheap and well worth it to make good use of
much more expensive physical links.  This still scales _reasonably_
well, because the service provider controls the complexity of the
network and the amount of CPU and memory available.  I would _NOT_
recommend this approach if we were talking about inter-domain routing.

Tony

---

From: John E Drake <[email-masked]>
Date: Wed, 17 Nov 2010 06:35:15 -0800

Ning,

What I think I am hearing is that aggregation should only be performed when the aggregated links are nearly homogeneous, which seems pretty sensible for the reasons Tony cited.  Maybe you should indicate this in the requirements along with the reasons why?

Thanks,

John 

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of So, Ning
> Sent: Wednesday, November 17, 2010 6:24 AM
> To: Tony Li; Yong Lucy
> Cc: [email-masked]

---

From: "So, Ning" <[email-masked]>
Date: Wed, 17 Nov 2010 14:41:49 +0000

John and all,

I think the aggregation should be performed in at least two major cases:

1.  When the aggregated links are nearly homogeneous.  Do we need to
explain what we mean "nearly" and give it a definitive range?  

2.  When the quantity of component links are very large, and the
adjacency (individual component link is adjacency if not aggregated) is
a concern.

If all agree to this, I can certainly update the doc accordingly.   

Best regrads,
 
Ning So

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Wednesday, November 17, 2010 8:35 AM
To: So, Ning; Tony Li; Yong Lucy
Cc: [email-masked]
Subject: RE: Question on component link announcement aggregation

Ning,

What I think I am hearing is that aggregation should only be performed
when the aggregated links are nearly homogeneous, which seems pretty
sensible for the reasons Tony cited.  Maybe you should indicate this in
the requirements along with the reasons why?

Thanks,

John 

Sent from my iPhone

> > aggregation, each router has to maintain a large number of link
state
> table,

---

From: Yong Lucy <[email-masked]>
Date: Wed, 17 Nov 2010 10:08:47 -0600

Hi Tony,

> component links have different properties (BW, delay, delay variation) and
> we will explicitly need to compute paths with multiple requirements among
> this vector, we will need detailed information.
[LY] When bundling heterogeneous links, available BW in each component link
may be different. 
> 
> To again present an extreme example, suppose that we have a composite link
> that has a T1 in parallel with a high bandwidth satellite link.  The T1
> has a BW of 1.5Mb/s and a delay of 20ms.  The satellite link has a BW of
> 100Mb/s and a delay of 2s.  If we aggregate this, we can only present one
> number for BW and one number for delay.  No matter which way we do this,
> we will end up misrepresenting the situation and end up making incorrect
> path computations.  For example, if we abstract the link as (100Mb/s,
20ms)
> and we need a 10Mb/s path with 20ms delay, we would incorrectly compute
> the path.  This forces us into crankback.
[LY] This is an engineering issue. When it makes sense to use composite link
and when is not, operator can decide. As the example you give, IMHO, it does
not make sense to configure a composite link under this situation. Here we
just develop technical solution to support composite link. Maybe good to
give some useful cases in using composite link in the network.
> We can either explore those paths with the router's CPU using local
memory,
> or we can do so with crankback at signaling time.  There are 8,000
> possible paths in those three hops.  Path exploration with the CPU will
> take 10s of microseconds per path.  With crankback and signaling, it will
> take 10s of milliseconds per path.
[LY] We can investigate crankback condition and minimize the condition. Do
you think if we can introduce a "temporary" suspending state for composite
link? i.e. when component link fails, composite link can send a temporary
suspending state in IGP, in which routers in PSN do not consider composite
link in route computing for a short time.   

Regards,
Lucy
> 
> Which do you prefer?
> 
> IMHO, CPU and memory are cheap and well worth it to make good use of much
> more expensive physical links.  This still scales _reasonably_ well,
> because the service provider controls the complexity of the network and
> the amount of CPU and memory available.  I would _NOT_ recommend this
> approach if we were talking about inter-domain routing.
> 
> Tony

---

From: John E Drake <[email-masked]>
Date: Wed, 17 Nov 2010 08:16:57 -0800

Fine with me.

Sent from my iPhone

> Sent: Wednesday, November 17, 2010 6:42 AM
> To: John E Drake; Tony Li; Yong Lucy
> Cc: [email-masked]

---

From: Yong Lucy <[email-masked]>
Date: Wed, 17 Nov 2010 10:34:41 -0600

If we allow the component links with different capacities but the similar
delay and delay various to be bundled together, will this simplify the
problem? 
Lucy 

> Sent: Wednesday, November 17, 2010 8:42 AM

---

From: "So, Ning" <[email-masked]>
Date: Wed, 17 Nov 2010 16:50:40 +0000

Lucy,

The question is to aggregate or not.  If both cases are allowed, then
how to aggregate is up to individual solution, in my humble opinion.

Best regrads,
 
Ning So

-----Original Message-----
From: Yong Lucy [mailto:[email-masked]] 
Sent: Wednesday, November 17, 2010 10:35 AM
To: So, Ning; 'John E Drake'; 'Tony Li'
Cc: [email-masked]
Subject: RE: Question on component link announcement aggregation

If we allow the component links with different capacities but the
similar
delay and delay various to be bundled together, will this simplify the
problem? 
Lucy 

> > > advertise them as a single logical link. The motivation of the
link
> > bundle
> > > scalable. Each component link may have different loads. There is
no
> > need to
> > > Without component link announcement aggregation, route
announcement
> > and
> > > each router will receive SLAs from each component link since LSA
is
> > flooded;
> > > further more, this will cause much more process in route
computing.
> > From A

---

From: Tony Li <[email-masked]>
Date: Thu, 18 Nov 2010 07:13:58 +0900

Ning,

That's fine by me.  The requirements can be whatever you want them to be.  My preferences are that we are crystal clear and as precise as possible about them.  Requirements constrain the solution.  We should be careful to avoid writing requirements that have unintended implications.

Tony