Subject: Re: [mpls-tp] Description of Extra Traffic in Survivability Framework

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 May 2010 19:15:05 -0400

Adrian,

A little slow to respond ... but see inline.

Curtis

In message <D51DC9938A704F26B494A4FDD235E694@your029b8cecfe>
"Adrian Farrel" writes:
>  
> Hi,
>  
> Yes, I have some sympathy with this point.
>  
> I guess the different between per-packet pre-emption and per-flow 
> pre-emption is worth consideration.
>  
> What you describe is per-packet pre-emption. It is a good mechanism to 
> support "over-subscription" which provides an excellent way to distinguish 
> guaranteed and best-effort traffic.
>  
> The difference, as I see it (and as described in the Survivability 
> Framework) is that the entire extra traffic flow (that is, an LSP) is 
> notified and fully pre-empted in the event of the backup path needing to be 
> used to carry protected (i.e. higher priority) traffic.

That is what soft-preemption is for.  During the interim congestion
some low priority traffic is dropped.  When the preempted LSP moves,
the congestion goes away.  At no time is high priority traffic lost.

> It may be that the question we should ask is...
>  
> How much do we want this to look like the transport networks that the 
> operators are familiar with, and how much do we want to integrate with 
> normal packet behaviors?
>  
> My answer (FWIW) is "both". That is, we should support best-effort (which is 
> already part of MPLS) and we should support extra traffic (which is already 
> part of the management plane, OAM, and the GMPLS control plane). In other 
> words, I don't think there is substantial cost to supporting both 
> mechanisms, but we can offer operators a significant amount of flexibility 
> of function and operation of their networks.
>  
> Cheers,
> Adrian
> ----- Original Message ----- 
> From: "Maarten Vissers" <[email-masked]>
> To: "'Zhi-Wei Lin'" <[email-masked]>; "'Adrian Farrel'" 
> <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Monday, April 19, 2010 9:23 AM
> Subject: RE: [mpls-tp] Description of Extra Traffic in Survivability 
> Framework
>  
>  
> > Rationale to not support extra traffic in packet transport networks is 
> > that
> > connections with preemtable traffic are already supported in packet
> > transport networks; i.e. connections with drop eligible traffic and/or low
> > priority traffic that may be pushed away when high priority, non-drop
> > eligible traffic is applied at the input port of a link. The advantage of
> > this latter traffic is that it does not have to start/end at the location 
> > of
> > the protection switch end points.
> >
> > Regards,
> > Maarten
> >
> >  _____
> >
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Zhi-Wei Lin
> > Sent: zondag 18 april 2010 22:47
> > To: Adrian Farrel
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [mpls-tp] Description of Extra Traffic in Survivability
> > Framework
> >
> >
> > Hi Adrian, Nurit,
> >
> > As I stated in my previous email, I believe there are some differences
> > between a TDM network and a packet network. In packet network, much 
> > traffic
> > is best effort - and even most higher priority traffic are bursty in 
> > nature
> > (except the TDM PWE stuff). I believe extra traffic feature fits nicely 
> > with
> > transport of best effort type traffic in a packet network that MPLS-TP is
> > targeting.
> >
> > However, if extra traffic is not supported, then having the ability to 
> > allow
> > for oversubscription would in my view accomplish the same thing, with
> > support for (1:1)^n.
> >
> > Thanks
> > Zhi
> >
> >
> >
> > On Sun, Apr 18, 2010 at 9:30 AM, Adrian Farrel <[email-masked]> 
> > wrote:
> >
> >
> > Hi MPLS-TP list,
> >
> > Nurit and I are working on the Survivability Framework and the review from
> > the ITU-T.
> >
> > Section 4.3.3 is about "extra traffic". It is based on RFC 5654 section
> > 2.5.1.1 which says....
> >
> > Support for extra traffic (as defined in [RFC4427]) is not
> > required in MPLS-TP and MAY be omitted from the MPLS-TP
> > specifications.
> >
> > It is our understanding that this means that extra traffic is within scope
> > of MPLS-TP, but that there is no requirement for a specification to be
> > produced, and that implementations are not required to support extra
> > traffic.
> >
> > We also believe that the Survivability Framework should include a
> > description of extra traffic to give an overview of how it fits into the
> > general survivability model in case anyone wishes to work on extra traffic
> > in the future.
> >
> > In the liaison from the ITU-T
> > (https://datatracker.ietf.org/documents/LIAISON/file984.pdf) there is a
> > proposed major deletion of text from section 4.3.3. No explanation of this
> > deletion is provided, but we are assuming that it is because the ITU-T 
> > feels
> > that there is no requirement to support extra traffic.
> >
> > Nurit and I would like to hear the views of the MPLS-TP community on this
> > issue.
> >
> > Thanks,
> > Adrian and Nurit
> > _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> >
> >
> >
> > 
>  
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 6 May 2010 17:10:27 -0700

Hi Curtis,
there a couple notes I'd like to add in regard to applicability of the Soft
LSP preemtion (RFC 5712) to MPLS-TP:

   - my understanding is that LSP preemption is MPLS, not GMPLS mechanism.
   We might have issues (possible gap to address in CCAMP) with bi-directional
   LSPs in MPLS-TP
   - LSP preemprion recommended for non-DiffServ-enabled domains. In
   DiffServ domains the marking of packets should take care of ensuring
   preference of higher priority traffic
   - it might be that with broad use of proactive CV/CC role of LSP
   preemtion will change. As lower priority flow/service gets squeezed,
   corresponding CV/CC session will trigger alarms and recovery action(s) as
   provisioned by an operator.

Regards,
Greg

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 May 2010 23:08:33 -0400

>    provisioned by an operator.

GMPLS is a superset of MPLS.  Soft preempt only applies to packets,
because only in packets does it make sense to allow congestion to
occur, therefore it is MPLS and not GMPLS.

It is a useful technique for MPLS and *may* be used for MPLS-TP.  Or
just support hard preempt - it is up to the implementor.  Again it is
something that is optional (but quite useful).

Curtis

> --00c09f8e5955f0a6220485f5e2e7
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>  
> Hi Curtis,<br>there a couple notes I&#39;d like to add in regard to applica=
> bility of the Soft LSP preemtion (RFC 5712) to MPLS-TP:<br><ul><li>my under=
> standing is that LSP preemption is MPLS, not GMPLS mechanism. We might have=
>  issues (possible gap to address in CCAMP) with bi-directional LSPs in MPLS=
> -TP<br>
> </li><li>LSP preemprion recommended for non-DiffServ-enabled domains. In Di=
> ffServ domains the marking of packets should take care of ensuring preferen=
> ce of higher priority traffic</li><li>it might be that with broad use of pr=
> oactive CV/CC role of LSP preemtion will change. As lower priority flow/ser=
> vice gets squeezed, corresponding CV/CC session will trigger alarms and rec=
> overy action(s) as provisioned by an operator.</li>
> </ul>Regards,<br>Greg<br><br><div class=3D"gmail_quote">On Thu, May 6, 2010=
>  at 4:15 PM, Curtis Villamizar <span dir=3D"ltr">&lt;<a href=3D"mailto:curt=
> [email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=
> =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid=
>  rgb(204, 204, 204); padding-left: 1ex;">
> <br>
> Adrian,<br>
> <br>
> A little slow to respond ... but see inline.<br>
> <br>
> Curtis<br>
> <br>
> <br>
> In message &lt;D51DC9938A704F26B494A4FDD235E694@your029b8cecfe&gt;<br>
> <div class=3D"im">&quot;Adrian Farrel&quot; writes:<br>
> &gt;<br>
> &gt; Hi,<br>
> &gt;<br>
> &gt; Yes, I have some sympathy with this point.<br>
> &gt;<br>
> &gt; I guess the different between per-packet pre-emption and per-flow<br>
> &gt; pre-emption is worth consideration.<br>
> &gt;<br>
> &gt; What you describe is per-packet pre-emption. It is a good mechanism to=
> <br>
> &gt; support &quot;over-subscription&quot; which provides an excellent way =
> to distinguish<br>
> &gt; guaranteed and best-effort traffic.<br>
> &gt;<br>
> &gt; The difference, as I see it (and as described in the Survivability<br>
> &gt; Framework) is that the entire extra traffic flow (that is, an LSP) is<=
> br>
> &gt; notified and fully pre-empted in the event of the backup path needing =
> to be<br>
> &gt; used to carry protected (i.e. higher priority) traffic.<br>
> <br>
> <br>
> </div>That is what soft-preemption is for. =A0During the interim congestion=
> <br>
> some low priority traffic is dropped. =A0When the preempted LSP moves,<br>
> the congestion goes away. =A0At no time is high priority traffic lost.<br>
> <div><div></div><div class=3D"h5"><br>
> <br>
> &gt; It may be that the question we should ask is...<br>
> &gt;<br>
> &gt; How much do we want this to look like the transport networks that the<=
> br>
> &gt; operators are familiar with, and how much do we want to integrate with=
> <br>
> &gt; normal packet behaviors?<br>
> &gt;<br>
> &gt; My answer (FWIW) is &quot;both&quot;. That is, we should support best-=
> effort (which is<br>
> &gt; already part of MPLS) and we should support extra traffic (which is al=
> ready<br>
> &gt; part of the management plane, OAM, and the GMPLS control plane). In ot=
> her<br>
> &gt; words, I don&#39;t think there is substantial cost to supporting both<=
> br>
> &gt; mechanisms, but we can offer operators a significant amount of flexibi=
> lity<br>
> &gt; of function and operation of their networks.<br>
> &gt;<br>
> &gt; Cheers,<br>
> &gt; Adrian<br>
> &gt; ----- Original Message -----<br>
> &gt; From: &quot;Maarten Vissers&quot; &lt;<a href=3D"mailto:maarten.visser=
> [email-masked]">[email-masked]</a>&gt;<br>
> &gt; To: &quot;&#39;Zhi-Wei Lin&#39;&quot; &lt;<a href=3D"mailto:zhiwlin@gm=
> ail.com">[email-masked]</a>&gt;; &quot;&#39;Adrian Farrel&#39;&quot;<br>
> &gt; &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;=
> <br>
> &gt; Cc: &lt;<a href=3D"mailto:[email-masked]">[email-masked]=
> .int</a>&gt;; &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&=
> gt;<br>
> &gt; Sent: Monday, April 19, 2010 9:23 AM<br>
> &gt; Subject: RE: [mpls-tp] Description of Extra Traffic in Survivability<b=
> r>
> &gt; Framework<br>
> &gt;<br>
> &gt;<br>
> &gt; &gt; Rationale to not support extra traffic in packet transport networ=
> ks is<br>
> &gt; &gt; that<br>
> &gt; &gt; connections with preemtable traffic are already supported in pack=
> et<br>
> &gt; &gt; transport networks; i.e. connections with drop eligible traffic a=
> nd/or low<br>
> &gt; &gt; priority traffic that may be pushed away when high priority, non-=
> drop<br>
> &gt; &gt; eligible traffic is applied at the input port of a link. The adva=
> ntage of<br>
> &gt; &gt; this latter traffic is that it does not have to start/end at the =
> location<br>
> &gt; &gt; of<br>
> &gt; &gt; the protection switch end points.<br>
> &gt; &gt;<br>
> &gt; &gt; Regards,<br>
> &gt; &gt; Maarten<br>
> &gt; &gt;<br>
> &gt; &gt; =A0_____<br>
> &gt; &gt;<br>
> &gt; &gt; From: <a href=3D"mailto:[email-masked]">mpls-tp-bounces=
> @ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]">mpls-tp-b=
> [email-masked]</a>] On Behalf<br>
> &gt; &gt; Of Zhi-Wei Lin<br>
> &gt; &gt; Sent: zondag 18 april 2010 22:47<br>
> &gt; &gt; To: Adrian Farrel<br>
> &gt; &gt; Cc: <a href=3D"mailto:[email-masked]">[email-masked]=
> u.int</a>; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> &gt; &gt; Subject: Re: [mpls-tp] Description of Extra Traffic in Survivabil=
> ity<br>
> &gt; &gt; Framework<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; Hi Adrian, Nurit,<br>
> &gt; &gt;<br>
> &gt; &gt; As I stated in my previous email, I believe there are some differ=
> ences<br>
> &gt; &gt; between a TDM network and a packet network. In packet network, mu=
> ch<br>
> &gt; &gt; traffic<br>
> &gt; &gt; is best effort - and even most higher priority traffic are bursty=
>  in<br>
> &gt; &gt; nature<br>
> &gt; &gt; (except the TDM PWE stuff). I believe extra traffic feature fits =
> nicely<br>
> &gt; &gt; with<br>
> &gt; &gt; transport of best effort type traffic in a packet network that MP=
> LS-TP is<br>
> &gt; &gt; targeting.<br>
> &gt; &gt;<br>
> &gt; &gt; However, if extra traffic is not supported, then having the abili=
> ty to<br>
> &gt; &gt; allow<br>
> &gt; &gt; for oversubscription would in my view accomplish the same thing, =
> with<br>
> &gt; &gt; support for (1:1)^n.<br>
> &gt; &gt;<br>
> &gt; &gt; Thanks<br>
> &gt; &gt; Zhi<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; On Sun, Apr 18, 2010 at 9:30 AM, Adrian Farrel &lt;<a href=3D"mai=
> lto:[email-masked]">[email-masked]</a>&gt;<br>
> &gt; &gt; wrote:<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; Hi MPLS-TP list,<br>
> &gt; &gt;<br>
> &gt; &gt; Nurit and I are working on the Survivability Framework and the re=
> view from<br>
> &gt; &gt; the ITU-T.<br>
> &gt; &gt;<br>
> &gt; &gt; Section 4.3.3 is about &quot;extra traffic&quot;. It is based on =
> RFC 5654 section<br>
> &gt; &gt; 2.5.1.1 which says....<br>
> &gt; &gt;<br>
> &gt; &gt; Support for extra traffic (as defined in [RFC4427]) is not<br>
> &gt; &gt; required in MPLS-TP and MAY be omitted from the MPLS-TP<br>
> &gt; &gt; specifications.<br>
> &gt; &gt;<br>
> &gt; &gt; It is our understanding that this means that extra traffic is wit=
> hin scope<br>
> &gt; &gt; of MPLS-TP, but that there is no requirement for a specification =
> to be<br>
> &gt; &gt; produced, and that implementations are not required to support ex=
> tra<br>
> &gt; &gt; traffic.<br>
> &gt; &gt;<br>
> &gt; &gt; We also believe that the Survivability Framework should include a=
> <br>
> &gt; &gt; description of extra traffic to give an overview of how it fits i=
> nto the<br>
> &gt; &gt; general survivability model in case anyone wishes to work on extr=
> a traffic<br>
> &gt; &gt; in the future.<br>
> &gt; &gt;<br>
> &gt; &gt; In the liaison from the ITU-T<br>
> &gt; &gt; (<a href=3D"https://datatracker.ietf.org/documents/LIAISON/file98=
> 4.pdf" target=3D"_blank">https://datatracker.ietf.org/documents/LIAISON/fil=
> e984.pdf</a>) there is a<br>
> &gt; &gt; proposed major deletion of text from section 4.3.3. No explanatio=
> n of this<br>
> &gt; &gt; deletion is provided, but we are assuming that it is because the =
> ITU-T<br>
> &gt; &gt; feels<br>
> &gt; &gt; that there is no requirement to support extra traffic.<br>
> &gt; &gt;<br>
> &gt; &gt; Nurit and I would like to hear the views of the MPLS-TP community=
>  on this<br>
> &gt; &gt; issue.<br>
> &gt; &gt;<br>
> &gt; &gt; Thanks,<br>
> &gt; &gt; Adrian and Nurit<br>
> &gt; &gt; _______________________________________________<br>
> &gt; &gt; mpls-tp mailing list<br>
> &gt; &gt; <a href=3D"mailto:[email-masked]">[email-masked]</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; &gt;<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt;<br>
> &gt; _______________________________________________<br>
> &gt; mpls-tp mailing list<br>
> &gt; <a href=3D"mailto:[email-masked]">[email-masked]</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>
> _______________________________________________<br>
> mpls-tp mailing list<br>
> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls-tp" target=3D"_blank"=
> >https://www.ietf.org/mailman/listinfo/mpls-tp</a><br>
> </div></div></blockquote></div><br>
>  
> --00c09f8e5955f0a6220485f5e2e7--

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 7 May 2010 23:03:36 +0100

Curtis,

You're right, we should mention soft-preemption in the survivability 
framework.

Cheers,
Adrian
----- Original Message ----- 
From: "Curtis Villamizar" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: "Maarten Vissers" <[email-masked]>; "'Zhi-Wei Lin'" 
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, May 07, 2010 12:15 AM
Subject: Re: [mpls-tp] Description of Extra Traffic in Survivability 
Framework