Subject: Re: Revised text on Component Link Requirement draft

From: "Mcdysan, David E" <[email-masked]>
Date: Mon, 10 Jan 2011 10:02:52 -0500

Hi,

I revised the draft to version 03 and submitted it today.

As discussed in the Beijing meeting, we are requesting a last call.

Thanks,

Dave

On 12/13/10 10:16 AM, "Mcdysan, David E" <[email-masked]>
wrote:

>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 
>
>
>
>
>On 12/7/10 3:17 PM, "So, Ning" <[email-masked]> wrote:
>
>>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
>>Network Evolution Planning
>>Verizon, Inc.
>>(office) 972-729-7905
>>(Cell) 972-955-0914
>> 
>>-----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.
>>
>>> 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.
>>
>>
>>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.'
>>
>>
>>> 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.
>>
>>
>>My bad, I was looking at the -01 text.
>>
>>Tony
>>
>>_______________________________________________
>>rtgwg mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/rtgwg
>

---

From: "So, Ning" <[email-masked]>
Date: Mon, 17 Jan 2011 18:36:21 +0000

RTGWG Chairs,

It has been a week since the last call of the draft has been requested.
Could you please make the last call announcement?  

Best regrads,
 
Ning So
 
-----Original Message-----
From: Mcdysan, David E [mailto:[email-masked]] 
Sent: Monday, January 10, 2011 9:03 AM
To: So, Ning; [email-masked]
Subject: Re: Revised text on Component Link Requirement draft

Hi,

Thanks,

Dave

link
to