Subject: WGLC completed on draft-ietf-rtgwg-cl-requirement-03

From: Alia Atlas <[email-masked]>
Date: Tue, 22 Feb 2011 13:42:46 -0500

The WG last call on draft-ietf-rtgwg-cl-requirement-03 is successfully
completed.
There were a few comments that should be rolled into a new version - and we'll
send that updated draft to the IESG.

Alia

---

From: "Mcdysan, David E" <[email-masked]>
Date: Wed, 23 Feb 2011 08:56:07 -0500

Hi,

According to my records, the following changes resulted from the last call
discussion:

Thread titled "Designated Component link, final proposed text from Tony Li
1/28/11

"The solution MUST support an optional means for LSP signaling to bind an
LSP to a particular component link within a composite link.  If this
option is applied to a bidirectional LSP, both directions of the LSP are
bound to the component.  If this option is not exercised, then an LSP that
is bound to a composite link may be bound to any component link matching
all other signaled requirements, and different directions of a
bidirectional LSP can be bound to different component links."

------

There was a separate thread started by Sringagesh Kini titled "Regarding
definition of component and composite link," which continued in an off
list discussion. The result of that discussion was to add the specific use
case clarifications and associated text proposed by Sri to the framework
draft and not modify the requirements draft.

If I missed something from the last call discussion, please respond to
this Email so that I can roll these comments into a new version as Alia
has requested.

Thanks,

Dave

On 2/22/11 1:42 PM, "Alia Atlas" <[email-masked]> wrote:

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

---

From: Lucy yong <[email-masked]>
Date: Wed, 23 Feb 2011 15:31:22 +0000

> LSP to a particular component link within a composite link. 

[LY] The network already supports this solution today, i.e. announce each (component) link as an IGP and/or IGP-TE link. Head-end node can use ERO to inform the nodes to bind LSP to the (component) link. 

[LY] IMO: when the router of a composite link does not explicitly announce all of its component links, the solution should also allow singling a bidirectional LSP w/ an indication whether it has to be placed on the same component link in both direction or not. 

Lucy  

 If this

---

From: Tony Li <[email-masked]>
Date: Wed, 23 Feb 2011 08:18:24 -0800

Hi Lucy,

> [LY] The network already supports this solution today, i.e. announce each (component) link as an IGP and/or IGP-TE link. Head-end node can use ERO to inform the nodes to bind LSP to the (component)…

A solution can take that approach to fulfill that requirement, but having each component be an individual IGP adjacency works against the scalability requirements.

Solutions that make use of IGP aggregation to achieve scalability will want to add mechanisms to provide for binding to individual components.

Tony

---

From: Lucy yong <[email-masked]>
Date: Wed, 23 Feb 2011 16:55:42 +0000

> > [LY] The network already supports this solution today, i.e. announce
> each (component) link as an IGP and/or IGP-TE link. Head-end node can use
> ERO to inform the nodes to bind LSP to the (component) link.
> 
> 
> A solution can take that approach to fulfill that requirement, but having
> each component be an individual IGP adjacency works against the
> scalability requirements.

[LY] Yes. Composite link ability to hide some individual component link provides the scalability in IGP.

> 
> Solutions that make use of IGP aggregation to achieve scalability will
> want to add mechanisms to provide for binding to individual components.
[LY] If individual component link needs to be advertised, it is not clear to me how to achieve the scalability.

---

From: Tony Li <[email-masked]>
Date: Wed, 23 Feb 2011 09:59:59 -0800

> [LY] If individual component link needs to be advertised, it is not clear to me how to achieve the scalability.

Well, there's a tradeoff involved.  One possible compromise, as I outlined in Beijing, would be to create IGP adjacencies only for the composite links and then to enumerate the relevant link attributes of the components as subTLVs of the composite link.

This reduces the number of IGP adjacencies, reduces the number of L3 visible links for SPF purposes, and reduces the LSDB overhead (as a component is less data than a full link).

This is not a panacea. In advertising the component attributes (as required), additional state is required.  TANSTAAFL.

If anyone has discovered a way to break the Shannon limit and transmit more information without more signal, please step forward now.  ;-)

Regards,
Tony

---

From: [email-masked]
Date: Thu, 24 Feb 2011 02:18:55 +0800

Hi Tony,

I noticed that there is a change of FR#1 between two version draft.
"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."
I think we may catch the solution from rfc4201 and 
draft-ietf-mpls-explicit-resource-control-bundle-08 for bandwidth.
For latency, thert is a description about it in 
draft-wang-ccamp-latency-te-metric-02. There may be two choice .
1. "When the composite link is advertised into IGP, the latency of 
composite link should be the range (e.g., at least minimum and maximum) 
latency value of all component links." - comment from Dave
2. " When the composite link is advertised into IGP, the latency of 
composite link should be the maximum latency value of all component 
links."

Xihua Fu

Tony Li <[email-masked]> 
发件人:  [email-masked]
2011-02-24 上午 12:18

收件人
Lucy yong <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03

Hi Lucy,

Tony

---

From: Lucy yong <[email-masked]>
Date: Wed, 23 Feb 2011 18:20:36 +0000

> Well, there's a tradeoff involved.  One possible compromise, as I outlined
> in Beijing, would be to create IGP adjacencies only for the composite
> links and then to enumerate the relevant link attributes of the components
> as subTLVs of the composite link.
> 
[LY] This saves some bits/bytes in SLA, but does not save the amount of the updates for individual component link state.

> This reduces the number of IGP adjacencies, reduces the number of L3
> visible links for SPF purposes, and reduces the LSDB overhead (as a
> component is less data than a full link).
> 
> This is not a panacea. In advertising the component attributes (as
> required), additional state is required.  TANSTAAFL.
[LY] Yeah. The node scalability is not addressed here.
> 
> If anyone has discovered a way to break the Shannon limit and transmit
> more information without more signal, please step forward now.  ;-)
[LY] If we only advertise a composite link in IGP, each node does not keep the state for individual component links. Can it be the solution?

---

From: Tony Li <[email-masked]>
Date: Wed, 23 Feb 2011 10:40:04 -0800

> [LY] This saves some bits/bytes in SLA, but does not save the amount of the updates for individual component link state.

TANSTAAFL.

> [LY] Yeah. The node scalability is not addressed here.

Again, TANSTAAFL.  If you have a better idea, please put it on the table.

> [LY] If we only advertise a composite link in IGP, each node does not keep the state for individual component links. Can it be the solution? 

It can, but at a very high cost.  If the IGP doesn't carry full information, then you end up being unable to compute successful paths, even in a stable topology.  You end up using crankback for path computation.  We discussed this in Anaheim and Beijing.

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 23 Feb 2011 11:11:14 -0800

Hi Xihua,

> I think we may catch the solution from rfc4201 and draft-ietf-mpls-explicit-resource-control-bundle-08 for bandwidth. 
> For latency, thert is a description about it in draft-wang-ccamp-latency-te-metric-02. There may be two choice . 
> 1. "When the composite link is advertised into IGP, the latency of composite link should be the range (e.g., at least minimum and maximum) latency value of all component links." - comment from Dave 
> 2. " When the composite link is advertised into IGP, the latency of composite link should be the maximum latency value of all component links." 

Yes, these possible solutions fall into the variations where you transmit only partial information in the IGP.  In these cases, the head-end has insufficient information to determine whether a particular path can support its bandwidth, delay, and jitter requirements.  Again, this leads to crankback.

Tony

---

From: [email-masked]
Date: Thu, 24 Feb 2011 04:34:04 +0800

Hi Tony,

You can carry some information which is used for the component selection 
during the signaling.

Xihua Fu

2011-02-24 上午 03:11

收件人
[email-masked]
抄送
Lucy yong <[email-masked]>, "[email-masked]" <[email-masked]>, 
[email-masked]
主题
Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03

Hi Xihua,

Yes, these possible solutions fall into the variations where you transmit 
only partial information in the IGP.  In these cases, the head-end has 
insufficient information to determine whether a particular path can 
support its bandwidth, delay, and jitter requirements.  Again, this leads 
to crankback.

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 23 Feb 2011 12:42:15 -0800

On Feb 23, 2011, at 12:34 PM, [email-masked] wrote:

> You can carry some information which is used for the component selection during the signaling. 

Hi Xihua,

Yes, you can.  However, there is the significant possibility that there is no appropriate component that has the requisite bandwidth, latency, and jitter.  In which case, you get rejected  at signaling time.  You can then hunt around for a path as part of signaling, or you can have the head-end recompute, effectively doing a depth-first search on the topology.  Neither of these are as effective as having full information at the head-end to start with.

It should be noted that we had very similar choices when we did TE in the first place.  We chose to advertise link information, including bandwidth and policy in the IGP to address this.

Regards,
Tony

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 23 Feb 2011 18:47:05 -0500

In message <[email-masked]>
Lucy yong writes:
>  
> [LY] IMO: when the router of a composite link does not explicitly
> announce all of its component links, the solution should also allow
> singling a bidirectional LSP w/ an indication whether it has to be
> placed on the same component link in both direction or not.

Lucy,

Catching up on email.

mpls-tp-multipath (which expired end of Dec but will be reneewed
shortly) points this out in the context of MPLS-TP LSP.  If MPLS-TP
LSP (or CL LSP with the same requirement) is carried in an MPLS LSP
that due to its capacity must use a hash based (or equiv) multipath
technique, then there also needs to be signaling to indicate that the
hash for the containing LSP must be limited to two labels.  More
generally any LSP limited to N label hash depth limits the containing
LSP to N+1 label hash depth.

For example, a 1Tb/s MPLS LSP and a 50Gb/s MPLS-TP LSP can be carried
on the same 11 x 100G multipath as long as the hash depth determined
after the label lookup.

If a corouted bidirectional LSP must take the same component in both
directions or a link bundle, not just the same link bundle (aka same
multipath) then it should request a specific component.  This is
slightly different from indicating that it can take any single
component (the MPLS-TP requirement needed for LM OAM and other OAM
fate sharing), but doesn't care which one.  CL adds the constraint
that it must take any compoennt matching some additional criteria
(such as a delay criteria).

The criteria that any component can be selected as long as it is the
same component in both directions also pins the LSP, just as
specifying a specific component would pin the LSP today.

We really should sort all of this out in the framework draft.  These
are really more detailed requirements than the requirements thatmade
it to cl-requirements but it is better that cl-requirements is moving
forward and documenting what we do already agree on.

Curtis

---

From: Lucy yong <[email-masked]>
Date: Wed, 23 Feb 2011 23:48:35 +0000

> It can, but at a very high cost.  If the IGP doesn't carry full
> information, then you end up being unable to compute successful paths,
> even in a stable topology.  You end up using crankback for path
> computation.  We discussed this in Anaheim and Beijing.

[LY] When one of component links fails, the compositel link can announce its available capacity to be zero while performing local recovery. When it finishes the recovery process, it can announce its available capabity again to reflect the true available capacity. Will this can prevent crankback issue?

Lucy

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 23 Feb 2011 18:53:48 -0500

> more information without more signal, please step forward now.  ;-)

Outlawing microsoft applications would improve the S/N ration as
measured in information per bit but less so (still somewhat) in
information per distraction (spurious font changes, font size changes,
color changes, placement, etc).  Then there is this sort of noise -
nonsensical remarks.

So it depends which sort of S/N you want optimized.  Or did you mean
IGP S/N, not mailing list S/N?  :-)

Curtis

---

From: Tony Li <[email-masked]>
Date: Wed, 23 Feb 2011 15:58:16 -0800

Hi Lucy,

No.  To prevent crankback, remote systems need to know the available capacity and properties for a component.

Again as an example, imagine that you have a 100Gb link, but it has a latency of 300ms.  Another component has a capacity of 1Gb, but with a latency of 1ms.

The composite link now might be advertised with a capacity of 101Gb, and a latency range of 1-300ms.

What do you do with a path that requires 10Gb and a latency of 10ms?  To the head end, this composite link looks useable.

Tony

---

From: Lucy yong <[email-masked]>
Date: Thu, 24 Feb 2011 00:05:00 +0000

> Again as an example, imagine that you have a 100Gb link, but it has a
> latency of 300ms.  Another component has a capacity of 1Gb, but with a
> latency of 1ms.
> 
> What do you do with a path that requires 10Gb and a latency of 10ms?  To
> the head end, this composite link looks useable.
> 
[LY] Composite link should not advertise in this way. Furthermore, I don't know if this is a useful case for operator.

Lucy

---

From: Lucy yong <[email-masked]>
Date: Thu, 24 Feb 2011 00:29:36 +0000

Curtis,

I agree. The framework draft can state this more clearly. The requirement draft need to move forward.

Lucy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Curtis Villamizar
> Sent: Wednesday, February 23, 2011 5:47 PM
> To: Lucy yong
> Cc: [email-masked]
> Subject: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03
> 
>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 23 Feb 2011 18:55:34 -0600

> more information without more signal, please step forward now.  ;-)

Oddly, this effect can be achieved, using a similar aggregation technique as discussed in this thread. Over a given RF channel. It's called MIMO (multiple in multiple out). You can easily exceed the Shannon limit in b/s/Hz, for that RF channel, by exploiting the multiple propagation paths. Most effective in a rayleigh channel (RF propagation channel where there are no dominant paths). A basic criterion of MIMO is that the total transmitted power can be no greater than if you used a single transmit antenna.

Perhaps a cabled analogy would be to exploit the different dispersion modes in a multimode fiber. Transmit different information on each one, then have clever processing at the receiver that decorrelates each of the separate transmissions. Another similarity being, the effect becomes range-limited in practice, both for radio and in fiber.

Bert

---

From: Alia Atlas <[email-masked]>
Date: Wed, 23 Feb 2011 20:03:50 -0500

> forward and documenting what we do already agree on.

I would certainly welcome more detail and consideration of issues in
the framework draft.

Alia

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 24 Feb 2011 18:24:53 -0500

In message <[email-masked]>
Tony Li writes:
> > [LY] When one of component links fails, the compositel link can
>   announce its available capacity to be zero while performing local
>   recovery. When it finishes the recovery process, it can announce its
>   available capabity again to reflect the true available
>   capacity. Will this can prevent crankback issue?
>  
>  
> Hi Lucy,
>  
> What do you do with a path that requires 10Gb and a latency of 10ms?
> To the head end, this composite link looks useable.
>  
> Tony

Tony,

If there are a large number of components with identical properties,
then the IGP needs to indicate that how many components exist with a
given set of properties.  In some cases, it may not be necessary to
enumberate each component.

I suggest that we go down a path which allows the following options:

  1.  list existing min-bw, max-bw summary with attached extended
      attributes per aggregate, with no other information.

  2.  add to #1, for all or a subset of components a sub-aggregation
      that is characterized by min-bw, max-bw and attached extended
      attributes,

  3.  add to #1 or #1 plus #2, advertisements for individual
      components.

#1 is just extended attributes added to link bundle.  #2 and #3 are
 sub-tlvs added to the link bundle.

... assuming we extend link bundle, for example.

Curtis

---

From: Tony Li <[email-masked]>
Date: Thu, 24 Feb 2011 15:30:37 -0800

> enumberate each component.

Hi Curtis,

I'm perfectly happy with any encoding tricks that folks may propose that will allow further aggregation in the cases where doing do does not lose significant information.

I look forward to concrete proposals.

Regards,
Tony

---

From: Lucy yong <[email-masked]>
Date: Fri, 25 Feb 2011 00:34:22 +0000

Hi Curtis,

>       attributes per aggregate, with no other information.
[LY] Does "min-bw" mean the largest LSP that composite link can take? If yes, I agree this is the right direction.
>       that is characterized by min-bw, max-bw and attached extended
[LY] Yes, we had this in mind. In addition, it is valuable to allow a composite link containing some component links that just use recovery purpose so their BW does not need to be advertised. A good example is that when a composite link contains a 10G component link with 30ms transmission delay and 1G component link with 500ms transmission delay. The composite link can just advertise 10BW with 30ms. 1G link can be used for recovery purpose. This gives operator flexibility to use the composite link. This does not require protocol changes, just need to describe the usage.
  
>  sub-tlvs added to the link bundle.
[LY] Agree. 

Lucy