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

[Curtis Villamizar <[e-mail]>]

Maybe the term LAG is confusing.  Link aggregation in practice is not
done just using Ethernet.  It is a common trick to advertise (into the
IGP) only the sum of a bundle of OC192 as well as 10GbE and with ISIS
in particular this isn't much of a change to what is advertised.

Avici had a protocol similar to LACP for POS back when Ethernet was
stuck at 1GbE with easy way to quickly detect a link fault and
therefore unusable by ISP.  I'm not sure of the details of how C&J
handle the non-Ethernet link aggregation.

It is therefore common to hear the term LAG used for both Ethernet and
non-Ethernet link aggregation.  Also providers use BFD or MEF OAM over
each member rather than rely on IEEE multiple second timers in LACP.
Once the fault is detected by BFD or MEF OAN, LACP can be used to
negociate the reduced LAG membership.

Curtis


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

--===============1058375631==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_52981DB05D3C5247A12D0AEE309F3CC2F73E0558EAINOAVREX11pti_"

--_000_52981DB05D3C5247A12D0AEE309F3CC2F73E0558EAINOAVREX11pti_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

"In the ideal case the detection time of the aggregate link going down at t=
he Ethernet Layer should be faster than that in the MPLS-TP layer. In such =
a case when a link goes down, it would probably just a change in properties=
 of the link (bandwidth etc) and no link down event to MPLS-TP"

[Rui] By "LAG" we don't then mean 802.3 c43 / 802.3ad LACP (timers multiple=
 of 1s) but just the aggregation/distribution algorithms "PHY alarm trigger=
ed", right? (Protocol and hence Key/aggregatability_check being ruled out)

From: Vishwas Manral [mailto:[e-mail]]
Sent: sexta-feira, 26 de Fevereiro de 2010 18:39
To: Peng He
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 Peng,

This is what should happen.

In the ideal case the detection time of the aggregate link going down at th=
e Ethernet Layer should be faster than that in the MPLS-TP layer. In such a=
 case when a link goes down, it would probably just a change in properties =
of the link (bandwidth etc) and no link down event to MPLS-TP.


However if the detection at the higher layer MPLS-TP is faster it will trea=
t the whole virtual link down and then UP with new properties when the lowe=
r layer detection happens.

Thanks,
Vishwas
On Fri, Feb 26, 2010 at 10:00 AM, Peng He <[e-mail]<mailto:pe=
[e-mail]>> wrote:
Hi Vishwas,

I agree that an Ethernet Link Aggregation group can be view as one
'virtual' interface to the MPLS-TP layer. Just a little confused here
that suppose a 4-link Ethernet AGG group, tnow one member/component
link is down then the traffic will be re-distributed to the remain 3
memner/component links of the AGG based on the AGG distribution
algorithm and the traffic can still  go through. At this moment,
should MPLS-TP view the (whole) 'virtual' interface down? or the
MPLS-TP views the 'virtual' interface as well as each individual
member/component link and consider it as a normal link down?


Regards,
Peng

On Fri, Feb 26, 2010 at 12:24 PM, Vishwas Manral <[e-mail]<ma=
ilto:[e-mail]>> wrote:
> Hi Rui,
>
> I have a slightly different view on this.
>
> 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 laye=
r.
> 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.
>
> Thanks,
> Vishwas
> On Fri, Feb 26, 2010 at 4:04 AM, Stewart Bryant <[e-mail]<mailt=
o:[e-mail]>> wrote:
>>
>> Rui Costa wrote:
>>>
>>> Greetings,
>>>
>>> Once this draft has some content related to ETH interfaces (carrying
>>> MPLS-TP packets), I'd like to put the question below.
>>>  If I understood correctly, ECMP is out of MPLS-TP. I suppose the reaso=
n
>>> is impredictability of BW distribution among LSPs while maintaining fra=
me
>>> ordering (distributors' algorithms need to maintain "each conversation'=
s
>>> frame order" and that implies hard BW distribution predictability and h=
ence
>>> provisioning).
>>>
>>
>> .. 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 ECM=
P
>>> (LSPs) and ETH aggregation (ETH interfaces; 802.3, c43) has the same
>>> implicition for ETH link aggregation and hence it won't be applicable t=
o
>>> MPLS-TP networks?
>>>
>>
>> I would think that if the operator wanted the bandwidth more than they
>> wanted 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
>
>
> _______________________________________________
> mpls-tp mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
>


--_000_52981DB05D3C5247A12D0AEE309F3CC2F73E0558EAINOAVREX11pti_
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:m=3D"http://schemas.microsoft.com/office/2004/12/omml" 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)">
<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;}
 /* 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.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.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle19
	{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=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>&#8220;</span><span lang=3DEN-US>In the ideal case the detec=
tion
time of the aggregate link going down at the Ethernet Layer should be faste=
r
than that in the MPLS-TP layer. In such a case when a link goes down, it wo=
uld probably
just a change in properties of the link (bandwidth etc) and no link down ev=
ent
to MPLS-TP</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"=
Calibri","sans-serif";
color:#1F497D'>&#8221;</span><span lang=3DEN-US style=3D'color:#1F497D'><o:=
p></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>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>[Rui] By &#8220;LAG&#8221; we don&#8217;t then mean 802.3 c4=
3 /
802.3ad LACP (timers multiple of 1s) but just the aggregation/distribution
algorithms &#8220;PHY alarm triggered&#8221;, right? (Protocol and hence
Key/aggregatability_check being ruled
out)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <o:p></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 18:39<br>
<b>To:</b> Peng He<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><o:p>&nbsp;</o:p></p>

<div>

<p class=3DMsoNormal>Hi Peng,<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>This is what should happen.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>In the ideal case the detection time of the aggregate =
link
going down at the Ethernet Layer should be faster than that in the MPLS-TP
layer. In such a case when a link goes down, it would probably just a chang=
e in
properties of the link (bandwidth etc) and no link down event to MPLS-TP.<o=
:p></o:p></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>

<div>

<p class=3DMsoNormal><span lang=3DEN-US>&nbsp;<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal>However if the detection at the higher layer MPLS-TP i=
s
faster it will treat the whole virtual link down and then UP with new
properties when the lower layer detection happens.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>Thanks,<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>Vishwas<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>On Fri, Feb 26, 2010 at 10:00 AM, Peng He &lt;<a
href=3D"mailto:[e-mail]">[e-mail]</a>&gt; wrote=
:<o:p></o:p></p>

<p class=3DMsoNormal>Hi Vishwas,<br>
<br>
I agree that an Ethernet Link Aggregation group can be view as one<br>
'virtual' interface to the MPLS-TP layer. Just a little confused here<br>
that suppose a 4-link Ethernet AGG group, tnow one member/component<br>
link is down then the traffic will be re-distributed to the remain 3<br>
memner/component links of the AGG based on the AGG distribution<br>
algorithm and the traffic can still &nbsp;go through. At this moment,<br>
should MPLS-TP view the (whole) 'virtual' interface down? or the<br>
MPLS-TP views the 'virtual' interface as well as each individual<br>
member/component link and consider it as a normal link down?<br>
<br>
<br>
Regards,<br>
<span style=3D'color:#888888'>Peng</span><o:p></o:p></p>

<div>

<div>

<p class=3DMsoNormal><br>
On Fri, Feb 26, 2010 at 12:24 PM, Vishwas Manral &lt;<a
href=3D"mailto:[e-mail]">[e-mail]</a>&gt; wrote=
:<br>
&gt; Hi Rui,<br>
&gt;<br>
&gt; I have a slightly different view on this.<br>
&gt;<br>
&gt; If Link aggregation is done in the Ethernet layer, MPLS-TP cannot dict=
ate<br>
&gt; how it is to be done, if it is shown as one interface to the MPLS-TP
layer.<br>
&gt; MPLS-TP OAM works at the MPLS level and so a fault at the Ethernet lin=
k<br>
&gt; level will be visible to MPLS-TP as a link down and not which of the<b=
r>
&gt; component links is down.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Vishwas<br>
&gt; On Fri, Feb 26, 2010 at 4:04 AM, Stewart Bryant &lt;<a
href=3D"mailto:[e-mail]">[e-mail]</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Rui Costa wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Greetings,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Once this draft has some content related to ETH interfaces
(carrying<br>
&gt;&gt;&gt; MPLS-TP packets), I'd like to put the question below.<br>
&gt;&gt;&gt; &nbsp;If I understood correctly, ECMP is out of MPLS-TP. I sup=
pose
the reason<br>
&gt;&gt;&gt; is impredictability of BW distribution among LSPs while
maintaining frame<br>
&gt;&gt;&gt; ordering (distributors' algorithms need to maintain &quot;each
conversation's<br>
&gt;&gt;&gt; frame order&quot; and that implies hard BW distribution
predictability and hence<br>
&gt;&gt;&gt; provisioning).<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; .. and the inability for the OAM to fate share with the LSP.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I imagine Ethernet link aggregation distributor algorithms to =
be
very<br>
&gt;&gt;&gt; alike to MPLS ECMP's. If so, can we say that the similarity
between ECMP<br>
&gt;&gt;&gt; (LSPs) and ETH aggregation (ETH interfaces; 802.3, c43) has th=
e same<br>
&gt;&gt;&gt; implicition for ETH link aggregation and hence it won't be
applicable to<br>
&gt;&gt;&gt; MPLS-TP networks?<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I would think that if the operator wanted the bandwidth more than =
they<br>
&gt;&gt; wanted the fate sharing, they will deploy the technology.<br>
&gt;&gt;<br>
&gt;&gt; - Stewart<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; mpls-tp mailing list<br>
&gt;&gt; <a href=3D"mailto:[e-mail]">[e-mail]</a><br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/mpls-tp" target=
=3D"_blank">https://www.ietf.org/mailman/listinfo/mpls-tp</a><br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; mpls-tp mailing list<br>
&gt; <a href=3D"mailto:[e-mail]">[e-mail]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/mpls-tp" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/mpls-tp</a><br>
&gt;<br>
&gt;<o:p></o:p></p>

</div>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

--_000_52981DB05D3C5247A12D0AEE309F3CC2F73E0558EAINOAVREX11pti_--

--===============1058375631==
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

--===============1058375631==--