Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP => ~ETH aggregation?

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Rui Costa writes:

>  
> Thanks for answering,
>  
>  
>  
> I'm not sure i understood the "higher priority LSP". If we are essentially =
> transporting/selling BW, do you mean priorities different for someone askin=
> g for 10G and someone asking for 100Mbps? Or, another way to put it: what i=
> f all customers have the same priority and pay for protection? This isn't t=
> he "Titanic's life boats" principle, is it? Do you mean "extra traffic" (i.=
> e., customers that don't pay for protection)?


See "Setup Priority" and "Holding Priority" in RFC 3209.

Or in the terms you've used "if [...] transporting/selling BW", it is
the customer paying extra to be the highest priority.  It may be the
US DoD, emergency services, or it could be anyone.


> As David wrote, "a dilation factor is required": the planning reasoning 2x1=
> 0G=3D20G is not true.
>  
> We could also run several distribution algorithms, simultaneously to the on=
> e in operation, and switch to the best one each time one of the links is re=
> aching its top. Complex, there is always a no-use case, and each switch wou=
> ld potentiate frame misordering, being a violation to the only distributor =
> requirement in 802.3 c43.

How IP src/dst hash works is getting a bit off topic and has been
explained already, though somewhat briefly.

> Regards,
>  
> Rui

Curtis



> From: Vishwas Manral [mailto:[e-mail]]
> Sent: sexta-feira, 26 de Fevereiro de 2010 23:04
> To: David Allan I
> Cc: [e-mail]; Rui Costa; [e-mail]
> Subject: Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP =
> =3D> ~ETH aggregation?
>  
> Hi David,
> On Fri, Feb 26, 2010 at 12:07 PM, David Allan I <[e-mail]=
> <mailto:[e-mail]>> wrote:
> The one complication being that for CAC'd traffic, the aggregate capacity o=
> f the LAG in failure scenarios can drop below the level of the bandwidth co=
> mmittments associated with the paths that transit the LAG. In which case yo=
> u want to move or protection switch SOME of the traffic.
> Isn't this similar to the case where a higher priority LSP needs to preempt=
>  the lower piority one because the bandwidth on a link is exhausted?
>  
>  
> The other complication is due to flow based assignment, the individual link=
> s in the LAG may not be being uniformly loaded...a dilation factor is requi=
> red. And moving the traffic off the LAG as a response to partial failure re=
> duces the statistical sample size for load spreading :-(....
> That is correct. Thats a known limitation of LAGged interfaces with out wit=
> hout MPLS-TP.
>  
> Thanks,
> Vishwas
>  
> I do not have solutions to this, I merely note the problems...
>  
> cheers
> D
>  
>  
>  
> ________________________________
> From: [e-mail]<mailto:[e-mail]> [mailto:mpl=
> [e-mail]<mailto:[e-mail]>] On Behalf Of Vishwa=
> s Manral
> Sent: Friday, February 26, 2010 12:24 PM
> To: [e-mail]<mailto:[e-mail]>
> Cc: Rui Costa; [e-mail]<mailto:[e-mail]>
> Subject: Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP =
> =3D> ~ETH aggregation?
> Hi Rui,
>  
> I have a slightly different view on this.
>  
> If Link aggregation is done in the Ethernet layer, MPLS-TP cannot dictate h=
> ow it is to be done, if it is shown as one interface to the MPLS-TP layer. =
> MPLS-TP OAM works at the MPLS level and so a fault at the Ethernet link lev=
> el will be visible to MPLS-TP as a link down and not which of the component=
>  links is down.
>  
> Thanks,
> Vishwas
> On Fri, Feb 26, 2010 at 4:04 AM, Stewart Bryant <[e-mail]<mailto:=
> [e-mail]>> wrote:
> Rui Costa wrote:
> Greetings,
>  
> Once this draft has some content related to ETH interfaces (carrying MPLS-T=
> P packets), I'd like to put the question below.
>  If I understood correctly, ECMP is out of MPLS-TP. I suppose the reason is=
>  impredictability of BW distribution among LSPs while maintaining frame ord=
> ering (distributors' algorithms need to maintain "each conversation's frame=
>  order" and that implies hard BW distribution predictability and hence prov=
> isioning).
>  
> .. and the inability for the OAM to fate share with the LSP.
> I imagine Ethernet link aggregation distributor algorithms to be very alike=
>  to MPLS ECMP's. If so, can we say that the similarity between ECMP (LSPs) =
> and ETH aggregation (ETH interfaces; 802.3, c43) has the same implicition f=
> or ETH link aggregation and hence it won't be applicable to MPLS-TP network=
> s?
>  
> I would think that if the operator wanted the bandwidth more than they want=
> ed the fate sharing, they will deploy the technology.
>  
> - Stewart
>  
>  
>  
>  
> _______________________________________________
> mpls-tp mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls-tp
>  
>  
>  
> --_000_52981DB05D3C5247A12D0AEE309F3CC2F73E0558E8INOAVREX11pti_
> Content-Type: text/html; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>  
> <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
> osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
> xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
> icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
> :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
> uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
> t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
> m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
> t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
> :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
> soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
> xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
> icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
> schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
> point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
> /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
> =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
> schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
> .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
> /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
> ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
> repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
>  xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
> schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
> /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
> ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
> p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
> /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
> mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
> crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
> s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
> ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
> om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
> ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
> partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
> 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
> 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
> deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
> Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
> st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
>  
> <head>
> <meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
> <!--[if !mso]>
> <style>
> v\:* {behavior:url(#default#VML);}
> o\:* {behavior:url(#default#VML);}
> w\:* {behavior:url(#default#VML);}
> .shape {behavior:url(#default#VML);}
> </style>
> <![endif]-->
> <style>
> <!--
>  /* Font Definitions */
>  @font-face
> 	{font-family:Calibri;
> 	panose-1:2 15 5 2 2 2 4 3 2 4;}
> @font-face
> 	{font-family:Tahoma;
> 	panose-1:2 11 6 4 3 5 4 4 2 4;}
> @font-face
> 	{font-family:Consolas;
> 	panose-1:2 11 6 9 2 2 4 3 2 4;}
>  /* Style Definitions */
>  p.MsoNormal, li.MsoNormal, div.MsoNormal
> 	{margin:0cm;
> 	margin-bottom:.0001pt;
> 	font-size:12.0pt;
> 	font-family:"Times New Roman","serif";}
> a:link, span.MsoHyperlink
> 	{mso-style-priority:99;
> 	color:blue;
> 	text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> 	{mso-style-priority:99;
> 	color:purple;
> 	text-decoration:underline;}
> p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
> 	{mso-style-priority:99;
> 	mso-style-link:"Plain Text Char";
> 	margin:0cm;
> 	margin-bottom:.0001pt;
> 	font-size:10.5pt;
> 	font-family:Consolas;}
> p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
> 	{mso-style-priority:99;
> 	mso-style-link:"Balloon Text Char";
> 	margin:0cm;
> 	margin-bottom:.0001pt;
> 	font-size:8.0pt;
> 	font-family:"Tahoma","sans-serif";}
> span.PlainTextChar
> 	{mso-style-name:"Plain Text Char";
> 	mso-style-priority:99;
> 	mso-style-link:"Plain Text";
> 	font-family:Consolas;}
> span.BalloonTextChar
> 	{mso-style-name:"Balloon Text Char";
> 	mso-style-priority:99;
> 	mso-style-link:"Balloon Text";
> 	font-family:"Tahoma","sans-serif";}
> span.EmailStyle21
> 	{mso-style-type:personal-reply;
> 	font-family:"Calibri","sans-serif";
> 	color:#1F497D;}
> .MsoChpDefault
> 	{mso-style-type:export-only;
> 	font-size:10.0pt;}
> @page Section1
> 	{size:612.0pt 792.0pt;
> 	margin:70.85pt 3.0cm 70.85pt 3.0cm;}
> div.Section1
> 	{page:Section1;}
> -->
> </style>
> <!--[if gte mso 9]><xml>
>  <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
> </xml><![endif]--><!--[if gte mso 9]><xml>
>  <o:shapelayout v:ext=3D"edit">
>   <o:idmap v:ext=3D"edit" data=3D"1" />
>  </o:shapelayout></xml><![endif]-->
> </head>
>  
> <body lang=3DPT link=3Dblue vlink=3Dpurple>
>  
> <div class=3DSection1>
>  
> <p class=3DMsoPlainText><span lang=3DEN-US>Thanks for answering,&nbsp;&nbsp=
> ; <o:p></o:p></span></p>
>  
> <p class=3DMsoPlainText><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>
>  
> <p class=3DMsoPlainText><span lang=3DEN-US>I&#8217;m not sure i understood =
> the
> &quot;higher priority LSP&quot;. If we are essentially transporting/selling=
>  BW,
> do you mean priorities different for someone asking for 10G and someone ask=
> ing for
> 100Mbps? Or, another way to put it: what if all customers have the same
> priority and pay for protection? This isn't the &quot;Titanic's life
> boats&quot; principle, is it? Do you mean &quot;extra traffic&quot; (i.e.,
> customers that don&#8217;t pay for protection)?&nbsp;&nbsp; <o:p></o:p></sp=
> an></p>
>  
> <p class=3DMsoPlainText><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>
>  
> <p class=3DMsoPlainText><span lang=3DEN-US>As David wrote, &quot;a dilation=
>  factor
> is required&quot;: the planning reasoning 2x10G=3D20G is not true. <o:p></o=
> :p></span></p>
>  
> <p class=3DMsoPlainText><span lang=3DEN-US>We could also run several distri=
> bution
> algorithms, simultaneously to the one in operation, and switch to the best =
> one
> each time one of the links is reaching its top. Complex, there is always a
> no-use case, and each switch would potentiate frame misordering, being a
> violation to the only distributor requirement in 802.3 c43.&nbsp;&nbsp;&nbs=
> p; <o:p></o:p></span></p>
>  
> <p class=3DMsoPlainText><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>
>  
> <p class=3DMsoPlainText><span lang=3DEN-US>Regards,&nbsp;&nbsp;&nbsp; <o:p>=
> </o:p></span></p>
>  
> <p class=3DMsoPlainText><span lang=3DEN-US>Rui<o:p></o:p></span></p>
>  
> <p class=3DMsoPlainText><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>
>  
> <p class=3DMsoPlainText><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>
>  
> <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
> ly:"Calibri","sans-serif";
> color:#1F497D'><o:p>&nbsp;</o:p></span></p>
>  
> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
> 0cm 0cm'>
>  
> <p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
> amily:
> "Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
> e:10.0pt;
> font-family:"Tahoma","sans-serif"'> Vishwas Manral
> [mailto:[e-mail]] <br>
> <b>Sent:</b> sexta-feira, 26 de Fevereiro de 2010 23:04<br>
> <b>To:</b> David Allan I<br>
> <b>Cc:</b> [e-mail]; Rui Costa; [e-mail]<br>
> <b>Subject:</b> Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00:
> ~ECMP =3D&gt; ~ETH aggregation?<o:p></o:p></span></p>
>  
> </div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>
>  
> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span lang=3DEN-US>Hi D=
> avid,<o:p></o:p></span></p>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>On Fri, Feb 26, 2010 at 12:07 PM, D=
> avid
> Allan I &lt;</span><a href=3D"mailto:[e-mail]"><span
> lang=3DEN-US>[e-mail]</span></a><span lang=3DEN-US>&gt; w=
> rote:<o:p></o:p></span></p>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt;font-fami=
> ly:"Arial","sans-serif";
> color:blue'>The one complication being that for CAC'd traffic, the aggregat=
> e
> capacity of the LAG in failure scenarios can drop below the level of the
> bandwidth committments&nbsp;associated with the paths that transit the LAG.=
>  In
> which case you want to move or protection switch SOME of the traffic.</span=
> ><span
> lang=3DEN-US><o:p></o:p></span></p>
>  
> </div>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>Isn't this similar to the case wher=
> e a
> higher priority LSP needs to preempt the lower piority one because the
> bandwidth on a link is exhausted?<o:p></o:p></span></p>
>  
> </div>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>&nbsp;<o:p></o:p></span></p>
>  
> </div>
>  
> <blockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=
> m 0cm 0cm 6.0pt;
> margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>&nbsp;<o:p></o:p></span></p>
>  
> <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt;font-fami=
> ly:"Arial","sans-serif";
> color:blue'>The other complication is due to flow based assignment, the
> individual links in the LAG&nbsp;may not be&nbsp;being uniformly loaded...a
> dilation factor is required. And moving the traffic off the LAG as a respon=
> se
> to partial failure reduces the statistical sample size for load spreading
> :-(....</span><span lang=3DEN-US><o:p></o:p></span></p>
>  
> </div>
>  
> </blockquote>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>That is correct. Thats a known limi=
> tation
> of LAGged interfaces with out without MPLS-TP.<o:p></o:p></span></p>
>  
> </div>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>&nbsp;<o:p></o:p></span></p>
>  
> </div>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>Thanks,<o:p></o:p></span></p>
>  
> </div>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>Vishwas<o:p></o:p></span></p>
>  
> </div>
>  
> <blockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=
> m 0cm 0cm 6.0pt;
> margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>&nbsp;<o:p></o:p></span></p>
>  
> <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt;font-fami=
> ly:"Arial","sans-serif";
> color:blue'>I do not have solutions to this, I merely note the problems...<=
> /span><span
> lang=3DEN-US><o:p></o:p></span></p>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>&nbsp;<o:p></o:p></span></p>
>  
> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
> ans-serif";
> color:blue'>cheers</span><o:p></o:p></p>
>  
> <p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
> ans-serif";
> color:blue'>D</span><o:p></o:p></p>
>  
> <p class=3DMsoNormal>&nbsp;<o:p></o:p></p>
>  
> <p class=3DMsoNormal>&nbsp;<o:p></o:p></p>
>  
> <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
>  
> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span lan=
> g=3DEN-US>
>  
> <hr size=3D2 width=3D"100%" align=3Dcenter>
>  
> </span></div>
>  
> <p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><span lang=3DEN-US
> style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></=
> b><span
> lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
> <a
> href=3D"mailto:[e-mail]" target=3D"_blank">mpls-tp-bounces@=
> ietf.org</a>
> [mailto:<a href=3D"mailto:[e-mail]" target=3D"_blank">mpls-=
> [e-mail]</a>]
> <b>On Behalf Of </b>Vishwas Manral<br>
> <b>Sent:</b> Friday, February 26, 2010 12:24 PM<br>
> <b>To:</b> <a href=3D"mailto:[e-mail]" target=3D"_blank">stbryant=
> @cisco.com</a><br>
> <b>Cc:</b> Rui Costa; <a href=3D"mailto:[e-mail]" target=3D"_blank"=
> >[e-mail]</a><br>
> <b>Subject:</b> Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00:
> ~ECMP =3D&gt; ~ETH aggregation?</span><span lang=3DEN-US><o:p></o:p></span>=
> </p>
>  
> <div>
>  
> <div>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>Hi Rui,<o:p></o:p></span></p>
>  
> </div>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>&nbsp;<o:p></o:p></span></p>
>  
> </div>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>I have a slightly different view on=
>  this.<o:p></o:p></span></p>
>  
> </div>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>&nbsp;<o:p></o:p></span></p>
>  
> </div>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>If Link aggregation is done in the =
> Ethernet
> layer, MPLS-TP cannot dictate how it is to be done, if it is shown as one
> interface to the MPLS-TP layer. MPLS-TP OAM works at the MPLS level and so =
> a
> fault at the Ethernet link level will be visible to MPLS-TP as a link down =
> and
> not which of the component links is down.<o:p></o:p></span></p>
>  
> </div>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>&nbsp;<o:p></o:p></span></p>
>  
> </div>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>Thanks,<o:p></o:p></span></p>
>  
> </div>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>Vishwas<o:p></o:p></span></p>
>  
> </div>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>On Fri, Feb 26, 2010 at 4:04 AM, St=
> ewart
> Bryant &lt;</span><a href=3D"mailto:[e-mail]" target=3D"_blank"><=
> span
> lang=3DEN-US>[e-mail]</span></a><span lang=3DEN-US>&gt; wrote:<o:=
> p></o:p></span></p>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>Rui Costa wrote:<o:p></o:p></span><=
> /p>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>Greetings, &nbsp; &nbsp; &nbsp;<br>
> <br>
> Once this draft has some content related to ETH interfaces (carrying MPLS-T=
> P
> packets), I'd like to put the question below. &nbsp; &nbsp; &nbsp;<br>
> &nbsp;If I understood correctly, ECMP is out of MPLS-TP. I suppose the reas=
> on
> is impredictability of BW distribution among LSPs while maintaining frame
> ordering (distributors' algorithms need to maintain &quot;each conversation=
> 's
> frame order&quot; and that implies hard BW distribution predictability and
> hence provisioning). &nbsp; <br>
> &nbsp;<o:p></o:p></span></p>
>  
> </div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>.. and the inability for the OAM to=
>  fate
> share with the LSP.<o:p></o:p></span></p>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>I imagine Ethernet link aggregation
> distributor algorithms to be very alike to MPLS ECMP's. If so, can we say t=
> hat
> the similarity between ECMP (LSPs) and ETH aggregation (ETH interfaces; 802=
> .3,
> c43) has the same implicition for ETH link aggregation and hence it won't b=
> e
> applicable to MPLS-TP networks? &nbsp;<br>
> &nbsp;<o:p></o:p></span></p>
>  
> <p class=3DMsoNormal><span lang=3DEN-US>I would think that if the operator =
> wanted
> the bandwidth more than they wanted the fate sharing, they will deploy the
> technology.<br>
> <span style=3D'color:#888888'><br>
> - Stewart</span> <o:p></o:p></span></p>
>  
> <div>
>  
> <div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US><br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> mpls-tp mailing list<br>
> </span><a href=3D"mailto:[e-mail]" target=3D"_blank"><span lang=3DE=
> N-US>[e-mail]</span></a><span
> lang=3DEN-US><br>
> </span><a href=3D"https://www.ietf.org/mailman/listinfo/mpls-tp" target=3D"=
> _blank"><span
> lang=3DEN-US>https://www.ietf.org/mailman/listinfo/mpls-tp</span></a><span
> lang=3DEN-US><o:p></o:p></span></p>
>  
> </div>
>  
> </div>
>  
> </div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>
>  
> </div>
>  
> </div>
>  
> </div>
>  
> </blockquote>
>  
> </div>
>  
> <p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>
>  
> </div>
>  
> </body>
>  
> </html>
>  
> --_000_52981DB05D3C5247A12D0AEE309F3CC2F73E0558E8INOAVREX11pti_--
>  
> --===============0757647195==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>  
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>  
> --===============0757647195==--
>