Subject: Revised text on Component Link Requirement draft

From: "So, Ning" <[email-masked]>
Date: Thu, 02 Dec 2010 17:26:37 +0000

All,

It has been a couple of weeks since the last conversation on the mail
list, and no additional comments were received, so I assume that
everyone agreed with the approach Tony, John, Lucy, and I agreed.  Here
is my proposed revised Req #1.  I will upload the revised draft if no
comments are received within a week.

Old text: FR#1  The solution SHALL provide a means to summarize routing
advertisements regarding the characteristics of a composite link such
that the routing protocol converges within the timeframe needed to meet
the network performance objective.

New text: FR#1  The solution SHALL provide a means to summarize some
routing advertisements regarding the characteristics of a composite link
such that the routing protocol converges within the timeframe needed to
meet the network performance objective.  Composite link CAN announce
each individual component link's bandwidth and latency parameters.  The
composite link SHALL behave as a single IGP adjacency. 

Since the current draft has already specified component link as
point-to-point physical or logical link, I do not see any needs to
further clarify that matter although we have discussed that on the mail
list.  

Existing text:       
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.

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

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 04 Dec 2010 19:48:47 -0500

Ning,

Thanks for the summary.  See inline (just agreeing with some
comments and one suggestion).

Curtis

> composite link SHALL behave as a single IGP adjacency. 

This is a good summary.  It continues to offer the option to summarize
routing information and offer the option not to summarize any of it.

It also clarifies that the composite link behaves like a single IGP
adjacency.

It might help to indicate that the capability to indicate a preferred
and backup component for the adjacency.  This would allow the IGP
adjacency processing to be moved to a line card CPU with a backup
component linkk (and therefore CPU) designated in advance of a
failure.  This would not remove the requirement to forward packets
from any component to the CPU that has been designated to process the
adjacency, but would provide a hint that could improve efficiency.

As to whether to bundle (but not to beat a dead horse), in many cases
the multiple component will be different waves on a DWDM and have near
identical delay characteristics and could potentially be very
numerous.  There are cases where summarization is appropriate and
cases where advertising only separate components is appropriate, and
there will be cases where limited summarization is appropriate.

> Ethernet VLAN, and MPLS-TP LSP.

Good point.

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

---

From: Tony Li <[email-masked]>
Date: Sat, 4 Dec 2010 21:52:15 -0800

Hi Ning,

Thanks for the changes.

> composite link SHALL behave as a single IGP adjacency. 

Looks good.  One editorial nit: the second sentence should probably read something like: 'A composite link CAN be announced in conjunction with detailed parameters about its component links, such as bandwidth and latency.'

> Ethernet VLAN, and MPLS-TP LSP.

My bad, I was looking at the -01 text.  

Tony

---

From: "So, Ning" <[email-masked]>
Date: Tue, 07 Dec 2010 20:17:23 +0000

All,

Here is the updated text based on Tony's input.

New text: FR#1  The solution SHALL provide a means to summarize some
routing advertisements regarding the characteristics of a composite link
such that the routing protocol converges within the timeframe needed to
meet the network performance objective. A composite link CAN be
announced in conjunction with detailed parameters about its component
links, such as bandwidth and latency. The composite link SHALL behave as
a single IGP adjacency.

Regarding Curtis' suggestion about preferred and backup component for
the adjacency, can we leave it for the solutions' draft?

Best regrads,
 
Ning So
 
-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
Sent: Saturday, December 04, 2010 11:52 PM
To: So, Ning
Cc: [email-masked]
Subject: Re: Revised text on Component Link Requirement draft

Hi Ning,

Thanks for the changes.

> composite link SHALL behave as a single IGP adjacency. 

Looks good.  One editorial nit: the second sentence should probably read
something like: 'A composite link CAN be announced in conjunction with
detailed parameters about its component links, such as bandwidth and
latency.'

Tony

---

From: "Mcdysan, David E" <[email-masked]>
Date: Mon, 13 Dec 2010 10:16:20 -0500

I recommend that we make two other relatively minor changes to the I-D
with reference to DR#6 and the paragraph following it:

" DR#6  The Solution SHALL support composite link IGP advertisement
         that results in convergence time better than that of
         advertising the individual component links.  The solution SHALL
         be designed so that it represents the range of capabilities of
         the individual component links such that functional
         requirements are met, and also minimizes the frequency of
         advertisement updates which may cause IGP convergence to occur.

         One solution approach is to summarize the characteristics of
         the component links in IGP advertisements; however, the intent

         of the above requirement is not to specify the form of a
         solution.  Examples of advertisement update triggering events
         to be considered include: LSP establishment/release, changes in
         component link characteristics (e.g., latency, up/down state),
         and/or bandwidth utilization."

First, I recommend replacing SHALL with SHOULD in the requirement. It is
desirable for the convergence to be better than what is provided today,
but if FR#1 is met then SHALL is not appropriate. Also, a solution (e.g.,
like the one Tony described in Beijing) may not result in (markedly)
faster convergence time.

Second, I recommend deleting the first sentence of the paragraph following
DR#6 

         "One solution approach is to summarize the characteristics of
         the component links in IGP advertisements; however, the intent
         of the above requirement is not to specify the form of a
         solution. "

Since requirements are not to describe solutions, this sentence is out of
scope.

Thanks,

Dave

---

From: "So, Ning" <[email-masked]>
Date: Mon, 13 Dec 2010 15:18:24 +0000

Dave,

I agree with the changes suggested.

Best regrads,
 
Ning So

-----Original Message-----
From: Mcdysan, David E [mailto:[email-masked]] 
Sent: Monday, December 13, 2010 9:16 AM
To: So, Ning; [email-masked]
Subject: Re: Revised text on Component Link Requirement draft

First, I recommend replacing SHALL with SHOULD in the requirement. It is
desirable for the convergence to be better than what is provided today,
but if FR#1 is met then SHALL is not appropriate. Also, a solution
(e.g.,
like the one Tony described in Beijing) may not result in (markedly)
faster convergence time.

Second, I recommend deleting the first sentence of the paragraph
following
DR#6 

Since requirements are not to describe solutions, this sentence is out
of
scope.

Thanks,

Dave

---

From: Tony Li <[email-masked]>
Date: Mon, 13 Dec 2010 10:12:02 -0800

I'm fine with these changes.

T