Subject: Re: [mpls] [PWE3] ELI as a reserved label

From: Curtis Villamizar <[email-masked]>
Date: Mon, 02 Aug 2010 10:17:31 -0400

In message <[email-masked]>
Shane Amante writes:
>  
> Hi Curtis,
>  
> I had some time to think about this some more on the plane ride home.
> See below.
>  
> On Jul 30, 2010, at 14:02 GMT+02:00, Curtis Villamizar wrote:
> > In message <[email-masked]>
> > Shane Amante writes:
> >> 
> >> Curtis,
> >> 
> >> On Jul 30, 2010, at 11:06 GMT+02:00, Curtis Villamizar wrote:
> >>> The Entropy Label Indicator (ELI) is called for in
> >>> draft-kompella-mpls-entropy-label-01.txt
> >>> 
> >>> After brief discussion with Stewart and with Kireeti and Lucy Yong,
> >>> there were three uses of ELI that would benefit from making the ELI a
> >>> reserved label.  It may be premature to make any such request and the
> >>> remaining reserved label number space is sparse, so this will be
> >>> floated as a separate draft, and put on hold awaiting advancement of
> >>> the drafts that depend on it.
> >>> 
> >>> The three benefits of making ELI a reserved label are in:
> >>> 
> >>> 1.  Extending any use of entropy-label to P2MP (where there are
> >>>     multiple egress and the possibility of each egress requiring a
> >>>     separate entropy label value is problematic for the ingress).
> >>> 
> >>> 2.  Extending any use of entropy-label to any arbitrary position in
> >>>     the label stack such that in an aggregation LSP with aggregates
> >>>     both MPLS-TP and MPLS LSP, load split on the MPLS LSPs is
> >>>     simplified and not impacted by limiting label stack depth for
> >>>     the MPLS-TP LSPs.  This is when label stack hash is limited to
> >>>     support MPLS-TP as proposed in
> >>>     draft-villamizar-mpls-tp-multipath-00.txt .
> >> 
> >> I agree there are benefits to a reserved label for the above two
> >> applications.  Most importantly, a receiving node would have pretty
> >> clearly semantics that what [immediately] follows a reserved ELI is
> >> the entropy-label, regardless of where the ELI is in the MPLS label
> >> stack and without needing to be in the signaling path to know what is
> >> the ELI value.
> > 
> > "Now don't be sad ... 'cause two out of three aint bad".  [meatloaf]
> > 
> > Its good to hear that you consider these to be useful.
> > 
> > Note that an ingress LSR still needs to determine that egress LSR
> > understands ELI to do anything.  To support MPLS-TP in MPLS the
> > ingress needs to veryify that all LSR on the path support MPLS in a
> > way that provides a compliant path for a contained TP LSP, but that is
> > out of scope of this discussion.
>  
> I need to revise my statements wrt entropy-labels and P2MP LSP's.
> After thinking about this some more, I no longer believe it makes
> sense to use a reserved ELI value for P2MP LSP's.  More specifically,
> for a given P2MP LSP, all receivers /MUST/ agree to receive entropy
> labels, because it would be silly to (for example) expect core LSR's
> to strip-off the ELI and an entropy-label mid-flight toward receivers
> that don't understand (or, can't receive) entropy-labels.  The
> ramifications of this are that if a head-end detects any receivers of
> a P2MP LSP that can't receive entropy-labels, then the head-end
> LER/LSR must either: a) re-signal the whole P2MP LSP toward all
> receivers so that the head-end will not send any entropy-labels at all
> on the P2MP LSP; or, b) signal 2 separate P2MP LSP's: one for
> entropy-label capable receivers and a second for non-entropy-label
> capable receivers.  I don't know that we want to mandate one of those
> two behaviors over the other, because SP's may make separate choices
> depending on whether they want to avoid extra replication in the
> network at the expense of not being able to do flow-based
> load-balancing, i.e.: Option (a), or don't mind the extra replication
> of (potentially) 2 parallel P2MP trees on the same links in order to
> attain some amount of flow-based load-balancing of the P2MP traffic.

The use of a reserved label doesn't remove the requirement to figure
out if the egress can support ELI.  It just removes the requirement to
put a separate ELI label on for each egress.

If some P2MP paths don't need to load balance (no multipath on that
leg) but other paths do, as long as all egress can support ELI, then
at worst it is 8 bytes of overhead that some paths don't need.

I don't see an alternative for P2MP in your paragraph above.  Are the
branch points assumed to selectively add a different ELI (or none) and
should branch point remove ELI and the entropy label if ELI is not
needed downstream or to the next branch point?  Would this be a lot
more complicated with different values of ELI per egress (and possibly
also per branch point)?

> So, in summary, I no longer see that draft-kompella-mpls-entropy-label
> has a requirement for reserved labels for either P2P or P2MP LSP's
> (scenario 1 in your original e-mail).  Furthermore, I still maintain
> that discussion of LFC and use of the MPLS TC field for indication of
> large vs. small flows is orthogonal to
> draft-kompella-mpls-entropy-label (scenario 3 in your original
> e-mail).  I haven't read draft-villamizar-mpls-tp-multipath-00
> (scenario 2 in your original e-mail) so I can't speak to whether or
> not there is a requirement for a reserved label there.

OK.

> Anyway, perhaps this will save you some time in that you don't need to
> write a whole new draft as you originally proposed and, instead, may
> only need to look at modifying your original draft.  :-)

For load balance to work with stack limited, then all midpoints would
need to know what ELI was being used.

This is a bit like each P2MP needing to know which ELI is needed
downstream of it, but not quite as bad.

OTOH, putting the ELI that is being used on a P2P LSP in the PATH or
RESV message for that P2P LSP would solve this for "Use of Multipath
with MPLS-TP and MPLS" aka draft-villamizar-mpls-tp-multipath-00.  I
could reference draft-kompella-mpls-entropy-label and make the request
that you put the ELI label in the PATH or RESV message somewhere.

> On a separate note, we intend to update
> draft-kompella-mpls-entropy-label shortly to cover P2MP LSP's (RSVP &
> mLDP), plus add details surrounding labelled BGP and RSVP P2P LSP's so
> that we have a more thorough treatment of all use cases to hopefully
> make all of this more clear.  (In fact, I got a good start on this
> text on this on the plane ride home :-).

OK.  Just try to get the ELI into the PATH or RESV so all LSR on the
PATH can see it.

BTW - There are some implications for facilities FRR.  On the
facilities backup path there is no per LSP PATH or RESV message to
look at to see what value of ELI is being used.  If the facilities
backup path is over multipath (ie: LAG, bundle, or RSVP ECMP), then
the value of ELI will not be known.  This might force detour style FRR
or use of GMPLS path protection (or segemenbt which is more
detour-like).  A fixed ELI would help here too (allowing bypass FRR).

> -shane

Maybe we should continue offline and then go back to the list.

Curtis

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 2 Aug 2010 09:12:40 -0700

Dear Curtis,
interestingly, I was thinking of possible implications of EL and multipath
in FRR Facility backup network.
You wrote:
BTW - There are some implications for facilities FRR.  On the
facilities backup path there is no per LSP PATH or RESV message to
look at to see what value of ELI is being used.  If the facilities
backup path is over multipath (ie: LAG, bundle, or RSVP ECMP), then
the value of ELI will not be known.  This might force detour style FRR
or use of GMPLS path protection (or segement which is more
detour-like).  A fixed ELI would help here too (allowing bypass FRR).

If the protected link is LAG or Link bundle, then I think it is more likly
that LSPs will get squeezed as BW shrinks. Thus it might be not a local
protection but restoration that will be playing in.
Another scenario, a singleton link protected by a path that has LAG or Link
Bundle in it. I think that it would be up to local policy of the particular
PLR to signal use of EL on the bypass tunnel regardless of whether EL been
used on any of protected LSPs.

Regards,
Greg

---

From: John E Drake <[email-masked]>
Date: Mon, 2 Aug 2010 13:58:32 -0700

Hi,

I think there is a misunderstanding.  EL support is loosely coupled  
between the ingress and egress and intermediate nodes have no  
knowledge of its usage.   Further, the ELI is normally *not* present.   
The normal mode of operation is for the egress to see a label for  
which it is expecting to see BOS set.  The fact that it isn't tells  
the egress that an EL is present.

ELI is for IPv4/6 forwarding where there is no label in which to check  
for BOS not being set.  Effectively, the ELI becomes that label.

This renders any transit router usage of an ELI with a reserved value  
moot since most of the time it won't be there.

Wrt p2mp, we cannot add either an EL or a reserved value ELI unless  
*all* receivers have indicated that they can receive it.

Thanks,

John

Sent from my iPhone

On Aug 2, 2010, at 10:18 AM, "Curtis Villamizar" <[email-masked]>  
wrote:

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

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 02 Aug 2010 20:03:40 -0400

In message <AANLkTi=[email-masked]>
Greg Mirsky writes:
>
>
> Dear Curtis,
>
> interestingly, I was thinking of possible implications of EL and
> multipath in FRR Facility backup network.
>
> You wrote:
>
>   the value of ELI will not be known.  This might force detour style
>   FRR or use of GMPLS path protection (or segement which is more
> If the protected link is LAG or Link bundle, then I think it is more
> likly that LSPs will get squeezed as BW shrinks. Thus it might be not
> a local protection but restoration that will be playing in.  Another
> scenario, a singleton link protected by a path that has LAG or Link
> Bundle in it. I think that it would be up to local policy of the
> particular PLR to signal use of EL on the bypass tunnel regardless of
> whether EL been used on any of protected LSPs.
>
> Regards,
> Greg

Greg,

I would imagine that in networks where LAG (or link bundle or ECMP) is
important, EL would be enabled anywhere that it could be supported
except in outer tiers where capacity was small enough that single
links only were needed.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 02 Aug 2010 20:24:25 -0400

> the egress that an EL is present.

John,

You are jumping in without understanding the context of the
discussion.

If stack depth used for hash is purposely limited for the purpose of
supporting a client MPLS-TP within an MPLS LSP, then the ELI and the
EL allow the label carrying entropy to be moved up the stack to where
it would be visible to the hash.

For example, if an MPLS LSP carried one MPLS-TP LSP and one very large
IP/MPLS LSP, the forwarding label could be followed by ELI and then
EL.  If the hash is limited to two, then MPLS-TP is unaffected.  If
the midpoint LSR do not know the value of ELI being used, they cannot
look past it at the third label in the stack.

This could also be solved by the ingress padding all LSP not using ELI
(by signaling an additional LSP that does nothing) but that is a very
ugly solution.

> for BOS not being set.  Effectively, the ELI becomes that label.

That was the original use, to avoid looking past BOS at the first
nibble.  Keeping that behaviour (looking past BOS) solves the
multipath with MPLS-TP case since the hash is not label stack based,
as long as MPLS-TP always uses a control word.  That is too limitiing
as MPLS-TP may also want to carry IP.

> *all* receivers have indicated that they can receive it.

Yes we all agree on that.

> John

btw- The length of messages that you send from a phone never ceases to
amaze me.

Curtis

---

From: John E Drake <[email-masked]>
Date: Mon, 2 Aug 2010 18:49:43 -0700

Curtis,

What you are doing is speculating that our EL solution could be  
morphed to solve a problem for which the requirements are ill-defined.

You refuse to understand that ELI is required in only a few cases and  
we do not want to make it mandatory.

Have you actually read the I-D or are you simply assuming that it  
mirrors your pre-conceived notions?

John

Sent from my iPhone

On Aug 2, 2010, at 8:39 PM, "Curtis Villamizar" <[email-masked]>  
wrote:

>>> FRR

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 03 Aug 2010 09:48:40 -0400

> morphed to solve a problem for which the requirements are ill-defined.

Yes.  morphing ELI was the context of the discussion.  I spoke to
Kireeti and Stewart at the IETF meeting and then sent an email to the
list.  As to ill defined this is from earlier in the thread:

Others thought the goal was well defined.  There was a third goal that
dropped off somewhere in the thread because it required modifying the
use of TC on the ELI label.

I look forward to your review of draft-villamizar-mpls-tp-multipath-00
at which point you can comment on whether the goals in that draft are
well enough defined.

> we do not want to make it mandatory.

I'm not refusing to understand what ELI was proposed for, just
pointing out that it could be more useful with some change.  That
should have been clear at the start of this thread.

At this point the only change that we (other participating in this
thread up until now) may have agreement on is putting the
(non-reserved label) ELI in the PATH or RESV message if ELI is used
for RSVP as well as LDP.  This is so that the midpoint LSR will see it
and can treat it appropriately.  Since ELI has to be passed egress to
ingress, this "request" may be a NOOP (it must be in the RESV in that
case or PATH and RESV for bidirectional LSP).

> mirrors your pre-conceived notions?

Yes.  I both attended the PWE3 meeting where it was presented and read
the draft.  The subject line is "ELI as a reserved label" and the
first message of this thread clearly indicates that I was proposing a
change to ELI and the reasons for the suggestion.

The entire RSVP signaling section is TBD and MPLS-TP is currently out
of scope.  Authors indicated that they do intend to fill in the RSVP
section and that if very minor modification could help accommodate
coexistance of MPLS-TP and MPLS it would be considered.

At this point the Shane has strongly indicated that a reserved label
is undesirable.  Stewart made the same comment at the PWE3 meeting,
but was willing to consider it if there was a high value add.  It may
be off the table at this point.

Curtis

---

From: John E Drake <[email-masked]>
Date: Tue, 3 Aug 2010 06:35:30 -0700

Curtis,

In the current proposal the EL is always at the bottom of the stack.   
A transit router has access to the entire stack and can use the EL for  
load balancing, so I don't see any purpose in moving the ELI/EL up the  
stack, nor do I see any explanation of how this could be accomplished.

If we wanted to bring MPLS-TP into the entropy label context, wouldn't  
it be simpler for the endpoints to always place the same value in the  
EL?

Thanks,

John

Sent from my iPhone

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 03 Aug 2010 13:45:38 -0400

> stack, nor do I see any explanation of how this could be accomplished.

I know what is in the current proposal.

This is the purpose to putting it higher (from N prior emails):

The mechanism is simple.  It was considered obvious enough not to need
to be explained, but here it is.

  1.  The LER for an LSP carrying other LSP computes a hash as if it
      were load balancing, even if it were a single link.

  2.  This LER pushes three labels, 1) the forwarding label, 2) an
      ELI, and 3) the result of the hash.

Now you know the purpose and the mechanism.

> it be simpler for the endpoints to always place the same value in the  

The point is to limit the depth of stack inspection in order to allow
MPLS-TP to take a single path.

In doing this we don't want to break MPLS load split.  There are two
ways to not break MPLS load split.

  1.  Continue to look past the label stack at the first nibble and
      hash based on IPv4 or IPv6 src/dst rather than label stack.
      This requires all PW to use CW and requires OAM under GAL to
      avoid a 4 or 6 in the first nibble and requires MPLS-TP to add
      an encapsulation to IP that avoids 4 or 6 in the first nibble.

  2.  Disable hash on payload for the MPLS LSP carrying some MPLS-TP
      and MPLS and add an entropy label (as I described above) to the
      MPLS (without the -TP) only, with no entropy label on MPLS.

      The midpoint LSR must know the ELI value for the given LSP (for
      that forwarding label).  This requires either:

          a.  another 20 bit value to look up at forwarding time, or
	  b.  a fixed value for ELI

The midpoint LSR in the example where a MPLS LSP was carrying some
MPLS-TP LSP would have hash depth limited to two labels.  Reserved
labels would be skipped (without adding them to the hash) and the next
label considered in the count.  This covers GAL that is not at BOS and
covers ELI that is not at BOS.  Both GAL and ELI not at BOS are
relaxations of what is now speicified (before you jump on that too).

This is covered in draft-villamizar-mpls-tp-multipath-00.txt and
(again) your review of that work would be appreciated.

> John

I hope this is more clear now.

Thanks for the feedback and for prompting an explanation of the
mechanism.  Its likely others will benefit from reading these
additional details that were not in the original email.

Curtis

---

From: Yong Lucy <[email-masked]>
Date: Tue, 03 Aug 2010 15:36:11 -0500

Shane,

I agree with you that ELI is hard in applying P2MP and did not think it
thoroughly in the meeting week. 

Because ELI is only used when there is no application label, it is better to
encode the large flow indication on EL.

Regards,
Lucy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shane Amante
> Sent: Saturday, July 31, 2010 9:38 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls] [PWE3] ELI as a reserved label
> 
> Hi Curtis,
> 
> I had some time to think about this some more on the plane ride home.  See
> below.
> 
> I need to revise my statements wrt entropy-labels and P2MP LSP's.  After
> thinking about this some more, I no longer believe it makes sense to use a
> reserved ELI value for P2MP LSP's.  More specifically, for a given P2MP
> LSP, all receivers /MUST/ agree to receive entropy labels, because it
> would be silly to (for example) expect core LSR's to strip-off the ELI and
> an entropy-label mid-flight toward receivers that don't understand (or,
> can't receive) entropy-labels.  The ramifications of this are that if a
> head-end detects any receivers of a P2MP LSP that can't receive entropy-
> labels, then the head-end LER/LSR must either: a) re-signal the whole P2MP
> LSP toward all receivers so that the head-end will not send any entropy-
> labels at all on the P2MP LSP; or, b) signal 2 separate P2MP LSP's: one
> for entropy-label capable receivers and a second for non-entropy-label
> capable receivers.  I don't know that we want to mandate one of those two
> behaviors over the other, because SP's may ma
>  ke separate choices depending on whether they want to avoid extra
> replication in the network at the expense of not being able to do flow-
> based load-balancing, i.e.: Option (a), or don't mind the extra
> replication of (potentially) 2 parallel P2MP trees on the same links in
> order to attain some amount of flow-based load-balancing of the P2MP
> traffic.
> 
> So, in summary, I no longer see that draft-kompella-mpls-entropy-label has
> a requirement for reserved labels for either P2P or P2MP LSP's (scenario 1
> in your original e-mail).  Furthermore, I still maintain that discussion
> of LFC and use of the MPLS TC field for indication of large vs. small
> flows is orthogonal to draft-kompella-mpls-entropy-label (scenario 3 in
> your original e-mail).  I haven't read draft-villamizar-mpls-tp-multipath-
> 00 (scenario 2 in your original e-mail) so I can't speak to whether or not
> there is a requirement for a reserved label there.
> 
> write a whole new draft as you originally proposed and, instead, may only
> need to look at modifying your original draft.  :-)
> 
> On a separate note, we intend to update draft-kompella-mpls-entropy-label
> shortly to cover P2MP LSP's (RSVP & mLDP), plus add details surrounding
> labelled BGP and RSVP P2P LSP's so that we have a more thorough treatment
> of all use cases to hopefully make all of this more clear.  (In fact, I
> got a good start on this text on this on the plane ride home :-).
> 
> -shane
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: David Allan I <[email-masked]>
Date: Wed, 4 Aug 2010 08:14:02 -0400

A clarification please...

I can understand the utility of an entropy label on a P2MP PW in a MS-PW case, as I can load spread the underlying unicast segments between the S-PEs...is that the practical use case?

Loadspreading a p2mp LSP such that it becomes an p2mp2mp seems rather fraught with peril...

In which case an entropy label only really applies to a p2p label..

Am I missing something?
D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yong Lucy
Sent: Tuesday, August 03, 2010 4:36 PM
To: 'Shane Amante'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] [PWE3] ELI as a reserved label

Shane,

I agree with you that ELI is hard in applying P2MP and did not think it thoroughly in the meeting week. 

Because ELI is only used when there is no application label, it is better to encode the large flow indication on EL.

Regards,
Lucy

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Shane Amante
> >>> After brief discussion with Stewart and with Kireeti and Lucy 
> >>> Yong, there were three uses of ELI that would benefit from making 
> >>> the ELI a reserved label.  It may be premature to make any such 
> >>> request and the remaining reserved label number space is sparse, 
> >>> so this will be floated as a separate draft, and put on hold 
> >>> awaiting advancement of the drafts that depend on it.
> >>>
> >> stack and without needing to be in the signaling path to know what 
> >> is the ELI value.
> >
> > way that provides a compliant path for a contained TP LSP, but that 
> > is out of scope of this discussion.
> 
> a P2MP LSP that can't receive entropy- labels, then the head-end 
> receivers so that the head-end will not send any entropy- labels at 
> all on the P2MP LSP; or, b) signal 2 separate P2MP LSP's: one for 
> two behaviors over the other, because SP's may ma  ke separate choices 
> network at the expense of not being able to do flow- based 
> e-mail).  I haven't read draft-villamizar-mpls-tp-multipath-
> 00 (scenario 2 in your original e-mail) so I can't speak to whether or 
> make all of this more clear.  (In fact, I got a good start on this text on this on the plane ride home :-).
> 
> -shane

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 04 Aug 2010 10:07:35 -0400

In message <[email-masked]>
David Allan I writes:
> I can understand the utility of an entropy label on a P2MP PW in a
> MS-PW case, as I can load spread the underlying unicast segments
> between the S-PEs...is that the practical use case?
>  

Dave,

A flow label is per draft-ietf-pwe3-fat-pw is applicable only to PW.

An entropy label (EL) is applicable to LSP as well as PW.  The entropy
label indicator (ELI) just marks where the EL is in the stack to
remove any ambiguity.  This is per draft-kompella-mpls-entropy-label.

A P2MP LSP could carry many traffic flows, such as many video
distribution streams, or many IP multicast groups (<s,G> groups as
P2MP is defined).  If so, an entropy label could be added, though a
hash on s,G would have the same effect.

If a P2MP LSP carrying IP multicast crosses a LAG today, it is split
based on s,G since s,G is the same as unicast source and destination,
with dst being in the range of multicast addresses.  Since that is the
case, P2MP LSP and ELI/EL could be applicable to link bundle (with all
ones component) and RSVP-TE ECMP (draft-kompella-mpls-rsvp-ecmp), both
of which branch but merge and deliver all traffic to the same node.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 04 Aug 2010 10:39:08 -0400

In message <[email-masked]>
David Allan I writes:
>  
> Thanks Curtis, that clarifies it for me...we are still only spreading
> over a P2P span...
>  
> Cheers
> D 

Yes.  If you consider a ECMP LSP as per draft-kompella-mpls-rsvp-ecmp
to be a P2P span, which it certainly is in the "client layer" sense
(to borrow from ITU-speak, but apply it to MPLS without the TP).

I agree with you (and Shane, and even John Drake :) that applying this
to P2MP more generally where it does not re-merge is not viable.

Curtis

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, August 04, 2010 10:08 AM
> To: David Allan I
> Cc: Yong Lucy; 'Shane Amante'; [email-masked]; [email-masked]; [email-masked]
> Subject: ELI and EL in P2MP (Re: [mpls] [PWE3] ELI as a reserved label)
>  
>  
> An entropy label (EL) is applicable to LSP as well as PW.  The entropy label indicator (ELI) just marks where the EL is in the stack to remove any ambiguity.  This is per draft-kompella-mpls-entropy-label.
>  
> A P2MP LSP could carry many traffic flows, such as many video distribution streams, or many IP multicast groups (<s,G> groups as P2MP is defined).  If so, an entropy label could be added, though a hash on s,G would have the same effect.
>  
> If a P2MP LSP carrying IP multicast crosses a LAG today, it is split based on s,G since s,G is the same as unicast source and destination, with dst being in the range of multicast addresses.  Since that is the case, P2MP LSP and ELI/EL could be applicable to link bundle (with all ones component) and RSVP-TE ECMP (draft-kompella-mpls-rsvp-ecmp), both of which branch but merge and deliver all traffic to the same node.
>  
> Curtis

---

From: David Allan I <[email-masked]>
Date: Wed, 4 Aug 2010 10:12:13 -0400

Thanks Curtis, that clarifies it for me...we are still only spreading over a P2P span...

Cheers
D 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 04, 2010 10:08 AM
To: David Allan I
Cc: Yong Lucy; 'Shane Amante'; [email-masked]; [email-masked]; [email-masked]
Subject: ELI and EL in P2MP (Re: [mpls] [PWE3] ELI as a reserved label)

Dave,

Curtis

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 5 Aug 2010 06:33:37 -0700

> btw- The length of messages that you send from a phone never ceases to

It's not a phone, it's a pocket-sized computer that's occasionally (with varying degrees of success) used for (TDM) phone calls.

:-)

What _is_ amazing is the volumes one can type with a miniscule keyboard.

Kireeti.

sent on a laptop sans numeric keypad