[email protected]
[Top] [All Lists]

RE: Composite Link Requirements as WG document

Subject: RE: Composite Link Requirements as WG document
From: "PAPADIMITRIOU Dimitri"
Date: Mon, 7 Dec 2009 20:51:22 +0100
 
Hi, 

See inline:
> -----Original Message-----
> From: Yong Lucy [mailto:[email protected]] 
> Sent: Monday, December 07, 2009 3:21 AM
> To: PAPADIMITRIOU Dimitri; 'John G. Scudder'; [email protected]
> Cc: [email protected]; ZININ Alex
> Subject: RE: Composite Link Requirements as WG document
> 
> Hi Dimitri,
> 
> See inline.
> 
> Regards,
> Lucy
> 
> > -----Original Message-----
> > From: [email protected] 
> [mailto:[email protected]] On Behalf Of
> > PAPADIMITRIOU Dimitri
> > Sent: Sunday, December 06, 2009 4:11 AM
> > To: John G. Scudder; [email protected]
> > Cc: [email protected]; ZININ Alex
> > Subject: RE: Composite Link Requirements as WG document
> > 
> > Hi,
> > 
> > Two comments on this document:
> > 
> > "Unlike a link bundle [RFC4201], the component links in a
> > composite link can have different properties such as cost
> > or capacity."
> > 
> > Component link "capacity" heterogeneity is "allowed" in 4201 I can
> > understand the potential limitation of identical TE metrics 
> (for each
> > component) unfortunately limited explanation are given to 
> sustain why it
> > should be addressed.
> [LY] Carriers want to bundle component links that do not have the same
> capacities (may even have different delays) together as one 
> IGP link in MPLS
> network. They have several such applications.
> > 
> > "This document describes a framework for managing aggregated
> > traffic over a composite link."
> > [...]
> > "To achieve the better component link utilization and avoid
> > component link congestion, the document describes some new
> > aspects on the traffic flow assignment to component links."
> > 
> > The document is specifically dealing to TE control but does 
> not explain
> > why "measuring" component link capacity is assumed 
> impossible (cf. 4201
> > Section 4) ?
> [LY] Measuring component link as whole does not give detail 
> information when
> need to move traffic flow from one component link to another 
> in the case
> that one component link fails or higher priority flow arrives. 

Operation listed in that 4201 section refers to "component links".
Preemption is probably something that can be documented but not sure how
the mechanisms would differ from "link ressource allocation" as
documented elsewhere.

> > Bottom-line: not clear if this document is intended to improve
> > applicability of bundling TE control in IP/MPLS or if the current
> > bundling approach is not fulfilling expected functionality (and this
> > document would outline the why/what). The issue is that the document
> > describes "modeling" but does not provide an answer to this 
> question.
> 
> [LY] I don't see much different between two cases you are 
> giving.

See it as follows: I would have preferred to see a "problem statement"
document/discussion on the list more than a framework that links to a
CTG requirement document which blurs the landscape.

> RFC4201 can't apply to the situation carrier wants, i.e. 
> bundling component links
> that do not have the same capacities (may even have different delays)

This statement is not correct actually. i) component links do not have
to be identical in terms of capacity per 4201; and ii) the TE metric per
component should be identical (per 4201) but it does not mean that the
"delay" of each component has to be identical.

> together as one IGP link in MPLS network. In fact, RFC4201 
> only applies to
> IGP TE link and RSVP-TE, carriers also need such link bundle 
> as a IGP link
> that supports LDP signaled LSPs as well.

Concerning the relationship to other protocols: LMP (link property
correlation) provides the possibility to bundle component links without
"imposing" any routing protocol. RFC 4220 can also be used to set such
bundle links. The question is more what is usage of the information,
i.e., if not included as part of "TE routing" information how "bundle
information" will be made available to TE control ? One seem to question
the use of "IGP TE" but what is the alternative to disseminate this
information as part of the TE routing instance ?

Your remark concerning the relationship to signaling is not clear to me,
in the MPLS context which signaling protocol outside RSVP supports TE
capability ? If there a need to incorporate TE capabilities as part of
other signaling protocols ?

> [LY] once it becomes WG document, we can further work on the 
> text to make it
> clear. We do not make the drafts as a solution drafts. It 
> just describes the
> basic composite link framework and requirements.

See my questioning as follows: the "bundled link" concept and "TE link"
concepts play a central role in TE control one must capture both
motivations and consequences before revisiting them (as we don't start
from a blank sheet here and consequence falls well beyond this specific
document). 

Thanks,
-dimitri.
 
> > Thanks,
> > -dimitri.
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]]
> > > On Behalf Of John G. Scudder
> > > Sent: Tuesday, November 10, 2009 10:08 AM
> > > To: [email protected]
> > > Cc: [email protected]; ZININ Alex
> > > Subject: Composite Link Requirements as WG document
> > >
> > > Folks,
> > >
> > > At today's meeting we received a request to adopt 
> draft-so-yong-mpls-
> > > ctg-requirement-00 as a working group document.  There was
> > > reasonably
> > > strong support in the room for doing so.  Please respond to the
> > > mailing list with your discussion, support or opposition 
> (please do
> > > this even if you did so in person).  The deadline for comments is
> > > November 30.
> > >
> > > Note that accepting the document simply means that the 
> working group
> > > would begin working on requirements.  It does not imply blanket
> > > acceptance of the document as it now stands.
> > >
> > > Thanks,
> > >
> > > --John
> > > _______________________________________________
> > > rtgwg mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/rtgwg
> > >
> > _______________________________________________
> > rtgwg mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/rtgwg
> 
> 
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

<Prev in Thread] Current Thread [Next in Thread>