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

[Stewart Bryant <stbryant at cisco.com>]

Luca Martini wrote:
> Stewart Bryant wrote:
> > Luca Martini wrote:
> > > 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 )
> > 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?
> 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.

> > > 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.
> > It could also be Ethernet with SA DA VLAN being suitable as a
> > discriminator.
> > >
> 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.
Maybe - what if the presentation is a switch rather than a router? We really
need SP input in the form of required configurations.
> > > 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.
> > What is the evidence from the SP traffic traces?
> Clearly if there was such a trace , the service would not work.  :-)
Depends if they have hit crisis or are simply on the way :)
> 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 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.
> > Depends on whether there is sufficient, accessable, granularity in 
> > the flow
> ok, the assumption was that there is no sufficient granularity.
We need the evidence to resolve this.

Stewart.


_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3