Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw

From: "Giles Heron" <[email-masked]>
Date: Mon, 3 Dec 2007 17:59:00 +0000

OK, so speaking as yet another operator....

there's a clear need to support fat PWEs, but I'm yet to be convinced that
this draft is the correct solution to the problem.

The intro to the draft talks about the application being to interconnect IP
routers. If that's the case then why not use an IP pseudowire?  If you do
that then there will just be one label, but (AFAIK) many routers will spot
the 0x4 (or 0x6) in the first nibble of the payload and do a hash on the IP
header - giving optimum traffic distribution and also preserving the order
of each flow.

If the payload is not IP then I think we have a problem at any rate, as we
don't necessarily know how to identify a "flow".  Sure, you could do a MAC
hash for an Ethernet pseudowire, but in many cases you see precisely one
pair of MAC addresses on the PWE.

Giles

On Nov 28, 2007 2:47 PM, Shane Amante <[email-masked]> wrote:

> Hi Yaakov,
>
> Yaakov Stein wrote:
> > Stewart and other authors
> >
> > I just finished reading the FAT-PW draft, and have a few
> comments/questions.
> >
> > 1. The draft says "Operators have requested the ability..."
> >     Since I have never heard this request from any of the operators with
> > which we work,
> >     can this be changed to "Some operators have requested ..." ?
> >     Since there is one operator on the author list, I guess we can guess
> > which operator has requested
> >     this feature !
>
> Speaking as /another/ operator, I can say there is an absolutely strong
> need to solve this problem, (and, has been for quite a long time,
> actually).  Consider the fact that 10 GbE has become (is becoming?) a
> pretty common access circuit to Backbones and that within most SP
> networks the dominant Backbone link size are 10G.  As you're likely well
> aware, the IEEE HSSG is working on both 40 GbE and 100 GbE.  Once 40 GbE
> is available, (and assuming its used for WAN connectivity, perhaps
> similar to 10 GbE LAN PHY), then OC-768c Backbone links will suffer the
> same problem.  100 GbE will, eventually, be used as both core and access
> links.  In short, this problem is not going away.  We need to solve it.
>
>
>
> > 2. The example given is for Ethernet PWs. Is this draft limited to this
> > case?
> >     There is discussion of whether it is limited to IP over Ethernet,
> >     but this more basic question is not addressed.
> >     For example, could this load balancing to be performed for ATM PWs
> >     based on the AAL5 flows?
>
>  From my perspective, Ethernet is far and away the biggest "problem
> child" out there today, due to the size of access to Backbone links,
> (see above).  While it may be admirable to look at making this draft
> "generic" for a variety of PW types, I wouldn't lose any sleep if this
> draft remained focused on just Ethernet.
>
>
>
> > 3. PWs are an emulation of the native service.
> >    Why is this emulation being called upon to deliver a feature NOT
> > present in the native service ?
> >    Doesn't this break the model a bit?
> >
> > 4. A native service processing function is required for differentiating
> > between different flows
> >    at ingress. If this draft is indeed limited to Ethernet PWs, such a
> > processing function
> >    already exists in the native service. 802.3 clause 43 (LAG) defines
> > conversations
> >    for exactly this purpose (commonly implemented by hashing IP
> > addresses and port numbers),
> >    and even mentions the use of load balancing in the distribution of
> > conversations over links.
> >    I think this function should be at least referenced.
> >
> > 5. My greatest problem is with the prefered mode of section 1.1,
> >     which builds a PW label stack under the MPLS label stack.
> >     The proposal is for 2 PW labels (once again, somewhat breaking
> RFC3985).
> >     Figure 2 is not completely clear about the label structure.
> >     There are two possibilities:
> >      1) both load balancing label and PW label have stack bit set. (I
> > hope not !)
> >      2) the load balancing label has S=1, and the PW label has S=0.
> >          So formally, the PW label seems to be an MPLS label.
> >     Both possibilities break the standard model.
> >
> >    I would certainly like to see more justification of the problem
> >    before breaking the model in this way.
> >    Perhaps a short requirements document is in order?
>
> When I read the draft, this is the part I also had the most concern
> with.  In particular, I like the "simplicity" of the LB Label approach
> (i.e.: savings on FIB space, no need to signal first and last labels for
> each PW, etc.); however, I am concerned about the implications of, or
> potential need to, define a 'generic' MPLS PW label.
>
> My primary concern is future extensibility.  Specifically, in case there
> are /other/ applications, which may or may not have been brought to the
> surface, yet, that may have similar needs/desire for a 2nd PW label.  If
> that ultimately means we gain consensus to amend the PWE3 Architecture,
> I'm OK with that, but certainly we would need to have more discussion to
> see whether or not it is a good approach and, more importantly, what are
> the other implications that go along with it?
>
>
>
> > 6. The draft recommends generating a load balancing label in such
> fashion
> >     that the entropy is high. This assumes that the precise form of the
> > label
> >     is used to determine the load balancing path (possibly a hash of
> > some sort).
> >     Could this mechanism, even if beyond the scope of the document, be
> > explained a bit more ?
>
> Load-balancing over LAG and ECMP paths, using some number of MPLS labels
> as input to a load-balancing hash algorithm, is common across all
> vendors.  However, such algorithms are 'proprietary' to each vendor.
> I'm not sure how much more can be said other than the fact that, one
> would strongly prefer that the output of a LAG or ECMP hashing algorithm
> is spread out among the largest number of hash buckets, (as is
> practical), to get the most even distribution of flows across a set of N
> links in a LAG or ECMP path.  And, I think the draft already makes this
> point, in Section 3:
> ---snip---
>    It is recommended that the method chosen to
>    generate the load balancing labels introduces a high degree of
>    entropy in their values, to maximise the entropy presented to the
>    ECMP path selection mechanism in the LSRs in the PSN, and hence
>    distribute the flows as evenly as possible over the available PSN
>    ECMP paths.
> ---snip---
>
> Is there something else you had in mind?
>
> -shane
>
>
> > 7. With the optional mode of section 1.2 several PW labels are mapped to
> > a single AC.
> >     I have no problem with this approach. In fact, I feel that it is
> >     somewhat similar to the solutions being proposed for PW protection.
> >     For PW protection two labels mapped to the AC or end-user
> application,
> >     where one label belongs to the active PW, and the other to the
> > backup PW (not being used).
> >     For load balancing two or more PWs, all in active state, are mapped
> > to the same AC.
> >     Would it be possible to integrate the two features into one
> mechanism
> >     for mapping multiple PW labels in either active or backup state to
> > one AC or end-user identifier?
> >
> > 8. The term VC as opposed to PW is used in various places in the
> document.
> >     I am not sure what is meant here. Is the intent that a "VC" is one
> > of the paths of the
> >     load-balanced "PW" ?
> >
> > The first paragraph of section 4 seems to imply that the authors are
> > willing to settle
> > on either of the modes rather than both. I would support the PW label
> mode.
> > If some entropy-rich information needs to be placed in the packet,
> > perhaps the flags in the CW could be used (if 16 paths is sufficient).
> >
> > Y(J)S
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
>
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 4 Dec 2007 00:13:40 +0200

I am not sure what you mean by "IP PW".
 
Do you mean simply IP over MPLS ?
In that case, yes the CW first nibble is designed to help with load
balancing.
 
As I understand this draft, the question is load balancing of PW
traffic,
not IP over MPLS.
 
Not being an operator, I am not sure how important this is.
 
Y(J)S

________________________________

From: Giles Heron [mailto:[email-masked]] 
Sent: Monday, December 03, 2007 7:59 PM
To: Shane Amante
Cc: Yaakov Stein; [email-masked]
Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw

there's a clear need to support fat PWEs, but I'm yet to be convinced
that this draft is the correct solution to the problem.

The intro to the draft talks about the application being to interconnect
IP routers. If that's the case then why not use an IP pseudowire?  If
you do that then there will just be one label, but (AFAIK) many routers
will spot the 0x4 (or 0x6) in the first nibble of the payload and do a
hash on the IP header - giving optimum traffic distribution and also
preserving the order of each flow. 

If the payload is not IP then I think we have a problem at any rate, as
we don't necessarily know how to identify a "flow".  Sure, you could do
a MAC hash for an Ethernet pseudowire, but in many cases you see
precisely one pair of MAC addresses on the PWE. 

Giles

	Hi Yaakov,

comments/questions.
	> which operator has requested

	Speaking as /another/ operator, I can say there is an absolutely
strong
	need to solve this problem, (and, has been for quite a long
time,
	actually).  Consider the fact that 10 GbE has become (is
becoming?) a
	pretty common access circuit to Backbones and that within most
SP
	networks the dominant Backbone link size are 10G.  As you're
likely well
	aware, the IEEE HSSG is working on both 40 GbE and 100 GbE.
Once 40 GbE
	is available, (and assuming its used for WAN connectivity,
perhaps
	similar to 10 GbE LAN PHY), then OC-768c Backbone links will
suffer the
	same problem.  100 GbE will, eventually, be used as both core
and access
	links.  In short, this problem is not going away.  We need to
solve it.

	>     For example, could this load balancing to be performed for
ATM PWs 

	 From my perspective, Ethernet is far and away the biggest
"problem
	child" out there today, due to the size of access to Backbone
links,
	(see above).  While it may be admirable to look at making this
draft 
	"generic" for a variety of PW types, I wouldn't lose any sleep
if this
	draft remained focused on just Ethernet.

	>     The proposal is for 2 PW labels (once again, somewhat
breaking RFC3985). 
	>    Perhaps a short requirements document is in order?

	When I read the draft, this is the part I also had the most
concern
	with.  In particular, I like the "simplicity" of the LB Label
approach 
	(i.e.: savings on FIB space, no need to signal first and last
labels for
	each PW, etc.); however, I am concerned about the implications
of, or
	potential need to, define a 'generic' MPLS PW label.
	
	My primary concern is future extensibility.  Specifically, in
case there
	are /other/ applications, which may or may not have been brought
to the
	surface, yet, that may have similar needs/desire for a 2nd PW
label.  If 
	that ultimately means we gain consensus to amend the PWE3
Architecture,
	I'm OK with that, but certainly we would need to have more
discussion to
	see whether or not it is a good approach and, more importantly,
what are 
	the other implications that go along with it?

	> 6. The draft recommends generating a load balancing label in
such fashion
	>     Could this mechanism, even if beyond the scope of the
document, be

	Load-balancing over LAG and ECMP paths, using some number of
MPLS labels
	as input to a load-balancing hash algorithm, is common across
all
	vendors.  However, such algorithms are 'proprietary' to each
vendor. 
	I'm not sure how much more can be said other than the fact that,
one
	would strongly prefer that the output of a LAG or ECMP hashing
algorithm
	is spread out among the largest number of hash buckets, (as is
	practical), to get the most even distribution of flows across a
set of N
	links in a LAG or ECMP path.  And, I think the draft already
makes this
	point, in Section 3:
	---snip---
	   It is recommended that the method chosen to 
	   generate the load balancing labels introduces a high degree
of
	   entropy in their values, to maximise the entropy presented to
the
	   ECMP path selection mechanism in the LSRs in the PSN, and
hence
	   distribute the flows as evenly as possible over the available
PSN 
	   ECMP paths.
	---snip---

	-shane

application, 
	>     Would it be possible to integrate the two features into
one mechanism 
	> 8. The term VC as opposed to PW is used in various places in
the document.
	> on either of the modes rather than both. I would support the
PW label mode.

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 3 Dec 2007 17:20:17 -0500

> there's a clear need to support fat PWEs, but I'm yet to be  
> convinced that this draft is the correct solution to the problem.
>
> The intro to the draft talks about the application being to  
> interconnect IP routers. If that's the case then why not use an IP  
> pseudowire?  If you do that then there will just be one label, but  
> (AFAIK) many routers will spot the 0x4 (or 0x6) in the first nibble  
> of the payload and do a hash on the IP header - giving optimum  
> traffic distribution and also preserving the order of each flow.
>
> If the payload is not IP then I think we have a problem at any rate,  
> as we don't necessarily know how to identify a "flow".  Sure, you  
> could do a MAC hash for an Ethernet pseudowire, but in many cases  
> you see precisely one pair of MAC addresses on the PWE.
>
> Giles
>
> > I just finished reading the FAT-PW draft, and have a few comments/ 
> questions.
> >

	Agreed.  Speaking as another operator, I too am concerned that we solve
this problem, but I do not like the approaches described in this draft.

> potential need to, define a 'generic' MPLS PW label.

	In addition to this, I suggest that the requirements first be  
investigated
before we go ahead with this solution. Speaking as someone who needs  
to make
different boxes interoperate in a network, I would prefer a SINGLE  
solution to this problem.
When we have different protocols, it is generally ok to have different  
approaches, but having
different approaches in this case seems to make things exponentially  
harder.

	--Tom

> > on either of the modes rather than both. I would support the PW  
> label mode.

---

From: "Giles Heron" <[email-masked]>
Date: Mon, 3 Dec 2007 23:14:11 +0000

Try section 4.1 of RFC4447 ;-)

and hey - don't let being a vendor stop you having opinions on how networks
should be operated.  None of the other vendors ever hold back...

On Dec 3, 2007 10:13 PM, Yaakov Stein <[email-masked]> wrote:

> As I understand this draft, the question is load balancing of PW traffic,
> not IP over MPLS.
>
>  ------------------------------
> *From:* Giles Heron [mailto:[email-masked]]
> *Sent:* Monday, December 03, 2007 7:59 PM
> *To:* Shane Amante
> *Cc:* Yaakov Stein; [email-masked]
> *Subject:* Re: [PWE3] draft-bryant-filsfils-fat-pw
>
> IP routers. If that's the case then why not use an IP pseudowire?  If you do

---

From: Luca Martini <[email-masked]>
Date: Tue, 11 Dec 2007 14:23:52 -0700

Tom/Shane,

Let me see if I can attempt to clarify the requirements.
First let's assume that we want preserve the order of the PW packets, 
then I see the following situations:

1) PW is of comparable size to some MPLS  trunk link in a link bundle. 
(let's say at least  10% of the size of the link).
2) PW is larger then some individual trunk link in some bundle.
3) PW can use network ECMP. ( no local link bundles are present along 
the PW path )

We also have the following sub cases.
a) PW contains IP traffic , and can be identified at ingress.
b) PW does not contain IP traffic/traffic cannot be ID/IP traffic is a 
single huge flow.

Any combinations of the above are possible. So I think this draft makes 
an attempt at solving 3a , and 1a.
However I think that the most common problem is 1b. Applications that 
generate large single amount of pw traffic tend to be enterprise 
applications.
Like database syncing , backups, encrypted 10GE links etc.

It seems to me , that the multiple receiving labels per PW solution is 
simple, does not change the pwe3 architecture, and does not overly 
complicates the hardware design of the PE. Since this can clearly be 
used on an exception basis it should be adequate to mitigate problem 1a/3a.

I do not believe that problem 2 is solvable while keeping the packets in 
order. However maybe that is not a requirement.

In the case of problems in the category "1b", we can solve them by 
implementation without requiring a new protocols.
So what is the most pressing problem to solve ?

Luca

Thomas Nadeau wrote:
>> could do a MAC hash for an Ethernet pseudowire, but in many cases you 
>> see precisely one pair of MAC addresses on the PWE.
>>
>> Giles
>>
>> On Nov 28, 2007 2:47 PM, Shane Amante <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     Hi Yaakov,
>>
>>     Yaakov Stein wrote:
>>     > [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 11 Dec 2007 22:17:14 +0000

> 3) PW can use network ECMP. ( no local link bundles are present along 
What is the difference between 1 and 3 from the point of view of the LB 
solution since
you have to do something to cause the load to spread out over the multiple
connections?
> b) PW does not contain IP traffic/traffic cannot be ID/IP traffic is a 
It could also be Ethernet with SA DA VLAN being suitable as a
discriminator.
>
> Any combinations of the above are possible. So I think this draft 
> makes an attempt at solving 3a , and 1a.
What is the evidence from the SP traffic traces?
> I do not believe that problem 2 is solvable while keeping the packets 
> in order. However maybe that is not a requirement.
Depends on whether there is sufficient, accessable, granularity in the flow
> So what is the most pressing problem to solve ?
Indeed we should base the choice on the requirements.

Stewart

---

From: Luca Martini <[email-masked]>
Date: Tue, 11 Dec 2007 16:25:33 -0700

Stewart Bryant wrote:
>> 1) PW is of comparable size to some MPLS  trunk link in a link 
>> bundle. (let's say at least  10% of the size of the link).
> What is the difference between 1 and 3 from the point of view of the 
> LB solution since
In 3 you make a decision on the T-PE, and not necessarily in the middle 
of the network. While in 1 , the T-PE  thinks that there is only one path.

>> b) PW does not contain IP traffic/traffic cannot be ID/IP traffic is 
>> a single huge flow.
Not a very useful one. if the traffic is IP , it will resolve to a 
single router. Additionally If the traffic is encrypted , again you 
will  still have a single SA/DA.

> What is the evidence from the SP traffic traces?
Clearly if there was such a trace , the service would not work.  :-)
This is based on my experience as an SP , and other SPs I talked with.
In the past this problem was with Gigabit ethernet , and it was resolved 
by using OC48, and OC192 uplinks.

>>
>> It seems to me , that the multiple receiving labels per PW solution 
>> is simple, does not change the pwe3 architecture, and does not overly 
ok, the assumption was that there is no sufficient granularity.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 12 Dec 2007 08:52:48 +0000

Luca Martini wrote:
>>> First let's assume that we want preserve the order of the PW 
>>> packets, then I see the following situations:
>>>
>>> 3) PW can use network ECMP. ( no local link bundles are present 
>>> along the PW path )
>>>
> In 3 you make a decision on the T-PE, and not necessarily in the 
> middle of the network. While in 1 , the T-PE  thinks that there is 
> only one path.
When the ECMP is more than one hop away from the T-PE 1 & 3 look the same.

> will  still have a single SA/DA.
Maybe - what if the presentation is a switch rather than a router? We really
need SP input in the form of required configurations.
>>> However I think that the most common problem is 1b. Applications 
>>> that generate large single amount of pw traffic tend to be 
>>> enterprise applications.
Depends if they have hit crisis or are simply on the way :)
> In the past this problem was with Gigabit ethernet , and it was 
> resolved by using OC48, and OC192 uplinks.
>
>>>
>>> is simple, does not change the pwe3 architecture, and does not 
>>> overly complicates the hardware design of the PE. Since this can 
>>> clearly be used on an exception basis it should be adequate to 
>>> mitigate problem 1a/3a.
>>>
>>> I do not believe that problem 2 is solvable while keeping the 
>>> packets in order. However maybe that is not a requirement.
We need the evidence to resolve this.

Stewart.

---

From: Shane Amante <[email-masked]>
Date: Wed, 12 Dec 2007 22:00:42 -0700

Luca,

> makes an attempt at solving 3a , and 1a.

I agree with you, so far.  IMHO, in the context of just 1a vs. 3a, 1a  
is a more pressing problem than 3a.

> clearly be used on an exception basis it should be adequate to  

In giving this more thought, and in private discussions with some  
others, the PW Labels Block approach seems more like a 'band-aid',  
than providing a relatively long-term fix for the problem at hand.   
Specifically, consider the following use cases where you [will] see  
fat PW's:
1) point-to-point VPWS, specifically in a hub-and-spoke environment,  
e.g.: a Hub site containing a (N x) 10 GbE NNI to another carrier,  
Enterprise DataCenter, etc.  Funneling in to that Hub site will be  
GbE, N x GbE and 10 GbE EoMPLS VC's.
2) multipoint-to-multipoint VPLS.  Although I can't say this is a hard  
requirement at the moment, I would expect that as VPLS adoption  
continues to grow that the solution for "Fat PW's" being discussed  
here will, most likely, get re-used in VPLS at some point down the road.
3) perhaps, further out than VPLS, MS-PW ...

Ultimately, the PW Labels Block approach burns LFIB space.  This seems  
to me to be particularly problematic in p2mp and mp2mp topologies,  
since the impact on LFIB space is felt by all PE nodes using the PW  
Labels Block approach.  In addition, I'm not necessarily convinced the  
impact on LFIB space will be minor, since the more VC labels that are  
allocated for a particular PW, the more diverse input is provided to  
load-hashing algorithms within core LSR's and, ultimately, the more  
evenly flows are distributed over component-links.

Finally, the PW Labels Block approach is concerning because operators  
will likely have to play around to find the 'right' size PW Labels  
Block for their network, LAG/ECMP sizes, etc.  Thus, as their network  
grows, they'll likely have to go back and re-adjust the PW Label Block  
larger or smaller always trying to optimize LFIB size vs. even load- 
balancing ...

Ultimately, BW is growing and shows no signs of abating, (BW growth is  
good for all of us! :-).  I don't believe, as you state above, that  
this solution will only see limited use in "exception cases".  Other  
networks will, if they don't already, need a solution to this same  
problem.  Therefore, I would advocate we think through the design  
fully and make sure it's: a) easy to configure/use/operate, esp. over  
long time scales; b) it's easily extensible to other protocols, (e.g.:  
VPLS); and, c) of course, scalable and interoperable with other  
network elements.

> implementation without requiring a new protocols.

I'm not sure I follow if, or how, you're proposing on solving 1b,  
since you're (b) above says that: "PW does not contain IP traffic/ 
traffic cannot be ID/IP traffic is a single huge flow" ... then, you  
go on to list applications for which there is no way for the ingress  
PE to identify a microflow in order to assign either a PW Label Block  
or Load-Balance Label.  Can you clarify what you mean above?

Thanks,

-shane

>>> (AFAIK) many routers will spot the 0x4 (or 0x6) in the first  
>>> nibble of the payload and do a hash on the IP header - giving  
>>> optimum traffic distribution and also preserving the order of each  
>>> flow.
>>>
>>> If the payload is not IP then I think we have a problem at any  
>>> rate, as we don't necessarily know how to identify a "flow".   
>>> Sure, you could do a MAC hash for an Ethernet pseudowire, but in  
>>> many cases you see precisely one pair of MAC addresses on the PWE.
>>>
>>> Giles
>>>
>>> On Nov 28, 2007 2:47 PM, Shane Amante <[email-masked] <mailto:[email-masked] 
>>> >> wrote:
>>>
>>>    Hi Yaakov,
>>>
>>>    Yaakov Stein wrote:
>> investigated before we go ahead with this solution. Speaking as  
>> someone who needs to make different boxes interoperate in a  
>> network, I would prefer a SINGLE solution to this problem.
>> When we have different protocols, it is generally ok to have  
>> different approaches, but having
>> different approaches in this case seems to make things  
>> exponentially harder.
>>
>> --Tom
>>
>>

---

From: Luca Martini <[email-masked]>
Date: Thu, 13 Dec 2007 08:08:38 -0700

Shane Amante wrote:
> Specifically, consider
Yes I agree that it is not perfect, however it does not change the
forwarding plane , which means that cost optimized hardware has a chance
of supporting it.
> the following use cases where you [will] see fat PW's:
VPLS, and VPWS use the PWs. So I believe that any solution we can design
for a PW would automatically apply there as well.

> impact on LFIB space will be minor, since the more VC 
I do not believe that there is a requirement for Huge single Multicast
flows at this point.
is this what you mean my p2mp ?

> labels that are allocated for a particular PW, the more diverse input
> is provided to load-hashing algorithms within core LSR's and,
> ultimately, the more evenly flows are distributed over component-links.
>
> larger or smaller always trying to optimize LFIB size vs. even
> load-balancing ...
>
This is very tricky. Since there is no standard , we need to guess what
happens here. A small number of labels should be sufficient. We can
always use a programmatic system based on link BW/ and numbers to figure
out how many labels we use.

> networks will, if they 
You make a big assumption that we can identify the flows inside the PW
at the AC.
With 10G ethernet encryption hardware approaching commodity pricing ,
I'm not sure that it is a good assumption.

> don't already, need a solution to this same problem.  Therefore, I
> would advocate we think through the design fully and make sure it's:
> a) easy to configure/use/operate, esp. over long time scales; b) it's
> easily extensible to other protocols, (e.g.: VPLS); and, c) of course,
> scalable and interoperable with other network elements.
>
>
>
> since you're (b) above says that: "PW does not contain IP
> traffic/traffic cannot be ID/IP traffic is a single huge flow" ...
> then, you go on to list applications for which there is no way for the
> ingress PE to identify a microflow in order to assign either a PW
> Label Block or Load-Balance Label.  Can you clarify what you mean above?
>
Not on this list. ;-)
The point is that there are solutions that do not require us to change
any protocols.

Luca

>>>> rate, as we don't necessarily know how to identify a "flow".  Sure,
>>>> you could do a MAC hash for an Ethernet pseudowire, but in many
>>>> cases you see precisely one pair of MAC addresses on the PWE.
>>>>
>>>> Giles
>>>>
>>> someone who needs to make different boxes interoperate in a network,
>>> I would prefer a SINGLE solution to this problem.

---

From: Shane Amante <[email-masked]>
Date: Thu, 13 Dec 2007 09:15:14 -0700

Luca,

> Shane Amante wrote:

[--snip--]

> is this what you mean my p2mp ?

No, that's not what I mean.  By p2mp, I mean a simple, hub-and-spoke 
topology, where several /unicast/ VC's are all funneled back to a single 
point/Hub, similiar to the following:

        +----- Chicago
        |
       NYC --- Dallas
        |
        +----- Washington DC

In the above, there exists three different unicast VC's:
- NYC (Hub) <--> Chicago (Spoke)
- NYC (Hub) <--> Dallas (Spoke)
- NYC (Hub) <--> Washington DC (Spoke)

> out how many labels we use.

I agree there's no standard, but if one were to take this approach I 
would highly recommend that it be operator configurable, because of the 
wide diversity in size of customer networks, LAG/ECMP bundles, 
EoMPLS/VPLS VC sizes and, lastly, LAG/ECMP hashing algorithms -- which 
are unique to every vendor, some of which could require more input to 
achieve fair load-balancing.

BTW, what's your definition of "a small number of labels"?

> I'm not sure that it is a good assumption.

I'm not sure the relevance of this point, since neither PW Label Block 
or LB Label solutions in this draft would be able to accommodate 
encrypted traffic, (unless you're suggesting the SP de-crypt the 
customer's traffic, look for a microflow to determine a PW Label or LB 
Label, re-encrypt and re-xmit the customer's packets ... which, I'm 
fairly sure the customer would find unacceptable).

> The point is that there are solutions that do not require us to change

I think you mean, there are solutions that do not require us to 
[significantly] change existing hardware.  While that's a fair point, I 
don't think that moves the needle far enough and we'll end up 
re-visiting this problem in the not-to-distant future.  Therefore, like 
I mentioned previously, I think we need to carefully think through our 
options here, because if the best, long-term solution will require new 
HW, then we need to know that sooner (rather than later), given the very 
long lead times in designing and building new HW.

-shane

[--snipped to end--]