Subject: Re: [mpls] Merge MAC Withdraw Drafts?

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Sat, 8 May 2010 12:29:22 -0500

Neil,
I think this email goes well beyond the scope of this discussion about a simple LDP extension for existing VPLS/MPLS deployments. 
I am seeing below a number of issues related to at least 3 IETF WGs:

1. LDP has a lot of issues
2. MPLS-TP requires some fixes - "there is still a major problem with MPLS-TP"
3. PWs seem to be a wrong step as a "rather sad consequence of the architectural problems noted above" (probably referring to 1 and 2)
4. same kind of issues for VPLS which is "yet another error"
 
If you or you and Ali want to debate these items I suggest we split the discussion as follows:

- issues 1. and 2. should be placed in one or more different emails addressed to MPLS WG
- issue 3 is of interest for PWE3 - so let's do another email for that one
- issue 4 is for L2VPN WG but should be debated on another email thread.

About issues 3 and 4: if this is the case then indeed we should not bother with any new developments in these areas. I think we should actually close the L2VPN and PWE3 WGs and leave it to IEEE to develop everything.

Personally I do not agree with the statements made for 3 and 4 and I think the large deployments around the world of the PWE3 and VPLS technologies is a proof that there was something right about them. But let's debate the specifics in the proper forums and see whether we need to throw them away.

Florin
PS: I am adding also MPLS, PWE3 WGs as I think they should be involved in this discussion.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, May 08, 2010 4:04 AM
> To: [email-masked]; Balus, Florin Stelian (Florin);
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Merge MAC Withdraw Drafts?
> 
> A few observations:
> 
> Firstly, I would tend to trust Ali's technical judgement/comments...esp
> when it comes to Ethernet. This is based on personal experience of
> dealing with him.
> 
> Wearing a G.800 functional architecture hat I could very easily write
> many pages on why the LDP form of MPLS has 'architectural challenges'
> and causes complexity/problems.  Indeed, one need only look at the
> effort on MPLS-TP in IETF to verify the correctness of this
> point....and
> one of the first tasks here is to deprecate LDP's merging behaviour
> because one MUST only allow p2p and p2mp constructs (==connections) in
> order to provide deterministic resource to clients.....which is a
> fairly
> fundamental requirement of any transport network.
> 
> Besides the merging problem of LDP (and PHP), one of the more serious
> architectural problems with MPLS is that it does not treat all its
> clients equally and in a proper client/server sense.  Wrt to IP this is
> also being addressed in MPLS-TP....and the key point here being the
> differentiation of IP as a *DP client* and IP as a *CP/MP adjunct cl-ps
> layer network* that is providing a logically OOB CP/MP to manage the
> MPLS-TP DP co-ps mode network.
> 
> However, there is still a major problem with the handling of nested
> LSPs
> in MPLS-TP, ie MPLS as a client of MPLS.  In a nutshell, a transport
> network must not use sublayering (ie the S bit, typical of how nested
> LSPs appear today) as this is simply partitioning of a *single* layer
> network and it is not the client/server relationship between different
> layer networks wrt nested LSPs that MPLS-TP requires *if* it is to
> provide a transport role.
> 
> Now a rather sad consequence of the architectural problems noted above
> is the emergence of PWs, ie the treatment of clients other than IP and
> MPLS....and when these are allowed to be multi-hop they generate yet
> another co-ps mode (PW) layer network above MPLS/MPLS-TP.  Like LSP
> sublayering (S bit) these should also not exist in MPLS-TP.  So we are
> not really facing up to our past errors here even in the work on
> MPLS-TP.  And I see a very similar situation here.
> 
> VPLS IMO is yet another errors that builds on the arch mistakes noted
> above...but this takes it to a new level by creating functional
> coupling
> of MPLS/PWs layer networks and an Ethernet layer network...and this is
> a
> really bad idea architecturally.
> 
> One of the key planks of networking is that we do not create functional
> coupling between different layer networks....and in particular a server
> layer network must provide transparency to a client layer network.  In
> essence, transparency means that a server layer network must never try
> and infer meaning of client layer symbols and for sure must never
> change
> them.  IP has been very successful because it always ensured it was
> always treated in a transparent manner by whatever the server layer it
> was carried over as a client, eg Ethernet, SDH VC4, PDH E1, etc, etc.
> 
> When it comes to MPLS however, we seem to have forgotten this very
> important architectural rule on transparency...and VPLS is an example
> of
> such.
> 
> **If we are wanting to impose functional behaviours in an Ethernet
> layer
> network then the only correct architectiral solution is to address this
> in the Ethernet layer network (in the DP/CP/MP as appropriate)....we
> should not (IMO must not) be trying to impose those behavious by
> DP/CP/MP actions in a different server layer network which are then
> functionally coupled in some manner to the client Ehernet layer
> network.**
> 
> One closing remark...I noted folks talking about QinQ in some of the
> earlier mails in this thread.  QinQ in Ethernet is in many ways similar
> to sublayering of LSPs in MPLS as-is.  That is, QinQ is also NOT a
> client/server relationship but simply a form of partitioning a single
> Ethernet layer network......one still has the same set of Ethernet
> access point addressing here.  MACinMAC (ie PBB) OTOH is a proper
> client/server relationship and correctly functionally partitions the
> client (eg CMAC) addressing from the server (BMAC) addressing.
> 
> regards, Neil
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > On Behalf Of Ali Sajassi (sajassi)
> > Sent: 08 May 2010 02:00
> > To: Balus, Florin Stelian (Florin); Shane Amante;
> > [email-masked]; Heron,GDY,Giles,DMF R
> > Subject: RE: Merge MAC Withdraw Drafts?
> >
> >
> > Shane, Giles:
> >
> > I think, we have spent enough time and energy to discuss this
> > subject and I hope this discussion has been informative to
> > our SP colleagues and the pros/cons of these two approaches
> > are now clear since they are the real owner of these
> > solutions. If after these healthy discussions, there are
> > still some SPs/operators who want to go with LDP-based MAC
> > withdraw for C-MACs in PBB-VPLS, then I would like to hear
> > from them since they should have the final say.
> >
> > Again, here is the summary for pros/cons of each approach
> > based on my previous email:
> >
> >  LDP-based:
> > -------------
> > Pros:
> > -	Simple to implement, no certification required, no OSS
> > modification
> > -	Works for E2E MPLS only
> > Cons:
> > -	Slower to converge (relative to Ethernet mechanism)
> > -	Creates interop issues and will require additional interop
> > solutions
> > -	Requires implementing, testing, and operating such interop
> > solutions
> >
> > Native Ethernet-based:
> > Pros:
> > -	Simple to implement, no certification required, no OSS
> > modification
> > -	Works for E2E MPLS
> > -	Faster to converge
> > -	No interop issue
> > -	No additional interop solution development, testing, and
> > operating
> > Cons:
> > -	None ( based on this long email thread, no one has pointed a
> > single con regarding this)
> >
> >
> > Florin, a few comments inline to your response
> >
> > - Ali
> >
> > > -----Original Message-----
> > > From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-
> > > lucent.com]
> > > Sent: Friday, May 07, 2010 10:30 AM
> > > To: Ali Sajassi (sajassi); Shane Amante; [email-masked]; Giles
> Heron
> > > ([email-masked])
> > > Subject: RE: Merge MAC Withdraw Drafts?
> > >
> > > Shane, Giles,
> > >
> > > We have been rambling on this draft that requires only a
> > new LDP TLV
> > > for way too long and I think we did our best to answers
> > Ali's points.
> > > With the reply below I think we are at a point where we need to
> > > conclude it is ok to agree to disagree - this is supposed to be my
> > > night job! I wonder what will happen if we have to debate a 20 page
> > > draft! :)
> > >
> > > Ali,
> > >
> > > I will summarize the point that is left on scalability to make some
> > > steps towards the closure:
> > > - you are admitting below there was "a perfect reason" to
> > use LDP hop-
> > > by-hop for MS-PW status and LDP MAC Flush.
> >
> > For B-MACs !! and there is perfect reason for not doing it for C-MACs
> > :-)
> >
> > > - you do not have any real example to demonstrate the LDP
> > hop-by-hop
> > > procedure is broken - I prompted you to bring up any bad experience
> > > with implementing and deploying HVPLS, MS-PWs and I did not see any
> > > reply.
> >
> > I never said it is broken or I have a bad experience with it.
> > I have been saying that is a bad solution for C-MACs because
> > of the above reasons (refer to the summary).
> >
> > > - I asked you to highlight also any initiative targeted at fixing
> > these
> > > mechanisms in L2VPN or PWE3 and you did not reply with anything
> > either.
> >
> > Again, my issue is not with B-MAC flushing. As I said
> > numerous times, you can extend the B-MAC flush for C-MAC
> > addresses but you will create tons of interop issues down the
> > road and if every SDO does the same thing we will have a
> > nightmare. You have conveniently sidestepping these interop
> > issues and saying that they should be taken care later.
> >
> > > - So we should conclude that this procedure is working just fine in
> > > real life deployments.
> > > - We are proposing an enhanced use of this LDP hop-by-hop procedure
> > > where compared with the above mechanism the PE-rs do not
> > perform any
> > > data plane function. Worthwhile to note for completion that
> > VPLS Mesh
> > > does not use LDP hop-by-hop anyhow.
> > >
> > > So in conclusion I think we need to close this thread too:
> > there is no
> > > scaling problem and the proposed mechanism will work even
> > better than
> > > in the MS-PW and HVPLS cases to address customer
> > requirements for one
> > > toolset in an MPLS E2E scenario.
> > >
> > > The rest is just academic discussion. I will try to address in-line
> > > anything that resembles some scalability discussion just because I
> > like
> > > Ali. :)
> >
> > And I like you - no hard feeling :-)
> >
> > -Ali
> >
> > > The rest we can continue as a discussion in IEEE.
> > >
> > > Florin
> >
> >

---

From: <[email-masked]>
Date: Sat, 8 May 2010 21:17:52 +0100

Thanks Florin,

I think most folks know my personal views on the technical matters I
have raised here...but to be strictly accurate these are actually not
'my views', they are simply conclusions from logical technical analysis
so I have no choice in arriving at these facts.  

Please note that in the co-ps mode we can do many things 'just because
we can' that are not possible in either the cl-ps mode or the co-cs
mode.  So the mere fact certain things exist and are doable is not
evidence they are a good idea and/or technically sound....which I would
differentiate from good marketing of such ;-).

Further, there are large time constants at play between cause and effect
in networking....so it often takes a long time (and large scale) to
start to get a feel for the real impacts of arch errors/complexity (and
even then in my experience true causal reasons are not always correctly
identified).

The reason why it is so easy to do the wrong things in the co-ps mode is
that resource assignment and labelling are decoupled actions.  I'll not
go into the underlying detail here, but it essentially comes down to how
we partition AND label a space/freq/time dimension of resource.....and
in the co-ps mode this is all about the labelling of irregular
time-slices of resource.  Those who want to pursue the detail can look
at G.800....and I am quite happy to go into off-line technical detail.

All I was trying to do in this mail was:
-	present a little bit of the history as to how we arrived at this
point;
-	give some insight as to what the architectural problems are that
we are now having to try and deal with...MPLS-TP is an example of one
reaction to this wrt attempting to provide a proper transparent
transport function in MPLS;
-	urge that in the future we try harder to have proper transparent
client/server relationships....and of course here we have the specific
case of MPLS/PW layer networks as the server to an Ethernet layer
network as the client.

So:  If we want a given functional behaviour in an Ethernet layer
network we should be addressing this in the DP/CP/MP of the Ethernet
layer network...not some other/lower layer network like MPLS, PWs, SDH
VC4 etc.  This is plain/obvious common sense anyway IMO.

Now wrt your remarks below please see in-line:

> From: Balus, Florin Stelian (Florin) 
> [mailto:[email-masked]] 
> Sent: 08 May 2010 18:29
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: Harrison,N,Neil,DKQ7 R; [email-masked]; 
> [email-masked]; Heron,GDY,Giles,DMF R
> I think this email goes well beyond the scope of this 
> discussion about a simple LDP extension for existing 
> VPLS/MPLS deployments. 

NH=> You can look at it this way, and I can easily understand why you
say this.  However, I am merely showing why we are at this juncture and
why, IMO, folks should stand back and look at the bigger networking
picture instead of just ploughing on from where we are now at.
 
> 1. LDP has a lot of issues

NH=> Yes it has Florin....it's an interesting technique and useful for
certain applications, but it has no basis in a transport network...which
is why it (and PHP and ECMP) are excluded in MPLS-TP.
 
> 2. MPLS-TP requires some fixes - "there is still a major 

NH=> Yes there are...the MPLS-TP folks in both IETF and ITU are well
aware of my observations.  I guess however it's not easy to accept that
MPLS-TP needs to do a little more than simple deprecate LDP, deprecate
PHP, deprecate ECMP and take its  CP/MP OOB.  It is, whether one likes
it or not, a simple technical fact that a properly designed co-ps mode
transport network would not have sublayering nor would it have PWs (or
even functions like TTL).  These are all 'carry-over' artefacts due to
the influence of LDP on MPLS's origins.

> 3. PWs seem to be a wrong step as a "rather sad consequence 
> of the architectural problems noted above" (probably 
> referring to 1 and 2)

NH=> This is also just a technical fact. If you want I can explain in
great detail why this is the situation.  However, I am also aware these
exist now and we cannot simply remove/ignore them.  However, this is no
excuse for not being technically accurate or honest about them is it?
And I for sure agree we have to cater for their legacy as we move
forward...but doing so does not mean these past errors should dictate
all future progress in standards...we really ought to strive to do be
'right first time' in the future.  Surely we can all agree with that.

 4. same kind of issues for VPLS which 
> is "yet another error"

NH=> This simply follows from the previous points and the functional
coupling of different layer network technologies.  This is just a fact.

> split the discussion as follows:

NH=> I have no need to debate them *here*.  They are simply facts that
we now have to live with.  If I am asking for anything here it is simply
this:  (i) can we please have some integrity/honesty about these facts
and (ii) can we please stop promulgating/compounding arch errors going
forward?  We cannot change history..... what is done is done, and we now
live with that legacy.  However, we should try and stop making things
worse going forward.

> About issues 3 and 4: if this is the case then indeed we 
> should not bother with any new developments in these areas. I 
> think we should actually close the L2VPN and PWE3 WGs and 
> leave it to IEEE to develop everything.

NH=> I suspect you might be slightly over-reacting here.  I totally
agree we need to cater for what is out there now, but my major plea is
let's not make things worse going forward by having a clear functional
separation of functions that apply to the Ethernet layer networks and
those that apply to the serving MPLS/PW layer networks (subject to the
architectural problems MPLS-TP is now wrestling with that I noted
above).  However, for further functional developments in Ethernet
DP/CP/MP then yes it should be down to IEEE to lead on this.  
> 
> Personally I do not agree with the statements made for 3 and 
> 4

NH=> This does not surprise me...a whole industry has now been created
on these architectural errors, so it is not in the interests of many
parties to 'agree' with the points I have made.  This, however, does not
detract from their technical accuracy of course.

> and I think the large deployments around the world of the 
> PWE3 and VPLS technologies is a proof that there was 
> something right about them.

NH=> Ah yes, the 'it exists therefore it must be right argument'.  There
are some significant commercial/marketing forces at play here that I'd
rather avoid, but I do have to acknowledge they are pertinent.  However,
at a *technical level* the argument that 'it exists therefore it must be
right' does not follow if one is being strictly honest with oneself as
an engineer.  I have already conceded we need to deal/live with our past
mistakes...human history is full of mistakes.....but when one has
figured out what the mistake is one should be somewhat wiser for this.
That is all I am asking for here.

> But let's debate the specifics in 
> the proper forums and see whether we need to throw them away.

NH=> We cannot "throw them away".....it's too late, they exist.
However, let's try and not make things worse going forward.  
regards, Neil

> > Firstly, I would tend to trust Ali's technical 
> > judgement/comments...esp when it comes to Ethernet. This is 
> based on 
> > personal experience of dealing with him.
> > 
> > point....and one of the first tasks here is to deprecate 
> LDP's merging 
> > behaviour because one MUST only allow p2p and p2mp constructs 
> > (==connections) in order to provide deterministic resource to 
> > clients.....which is a fairly fundamental requirement of 
> any transport 
> > network.
> > 
> > clients equally and in a proper client/server sense.  Wrt 
> to IP this 
> > is also being addressed in MPLS-TP....and the key point 
> here being the 
> > differentiation of IP as a *DP client* and IP as a *CP/MP adjunct 
> > cl-ps layer network* that is providing a logically OOB 
> CP/MP to manage 
> > the MPLS-TP DP co-ps mode network.
> > 
> > LSPs in MPLS-TP, ie MPLS as a client of MPLS.  In a nutshell, a 
> > transport network must not use sublayering (ie the S bit, 
> typical of 
> > how nested LSPs appear today) as this is simply partitioning of a 
> > *single* layer network and it is not the client/server relationship 
> > between different layer networks wrt nested LSPs that 
> MPLS-TP requires 
> > *if* it is to provide a transport role.
> > 
> > coupling of MPLS/PWs layer networks and an Ethernet layer 
> > network...and this is a really bad idea architecturally.
> > 
> > One of the key planks of networking is that we do not create 
> > functional coupling between different layer networks....and in 
> > particular a server layer network must provide transparency to a 
> > client layer network.  In essence, transparency means that a server 
> > layer network must never try and infer meaning of client 
> layer symbols 
> > and for sure must never change them.  IP has been very successful 
> > because it always ensured it was always treated in a transparent 
> > manner by whatever the server layer it was carried over as 
> a client, 
> > eg Ethernet, SDH VC4, PDH E1, etc, etc.
> > 
> > of such.
> > layer network then the only correct architectiral solution is to 
> > address this in the Ethernet layer network (in the DP/CP/MP as 
> > appropriate)....we should not (IMO must not) be trying to 
> impose those 
> > behavious by DP/CP/MP actions in a different server layer network 
> > which are then functionally coupled in some manner to the client 
> > Ehernet layer
> > network.**
> > 
> > earlier mails in this thread.  QinQ in Ethernet is in many ways 
> > similar to sublayering of LSPs in MPLS as-is.  That is, 
> QinQ is also 
> > NOT a client/server relationship but simply a form of 
> partitioning a 
> > single Ethernet layer network......one still has the same set of 
> > Ethernet access point addressing here.  MACinMAC (ie PBB) OTOH is a 
> > proper client/server relationship and correctly functionally 
> > partitions the client (eg CMAC) addressing from the server 
> (BMAC) addressing.
> > 
> > regards, Neil
> > 
> > 
> > 
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Ali Sajassi (sajassi)
> > > Sent: 08 May 2010 02:00
> > > To: Balus, Florin Stelian (Florin); Shane Amante; [email-masked]; 
> > > Heron,GDY,Giles,DMF R
> > > subject and I hope this discussion has been informative to our SP 
> > > colleagues and the pros/cons of these two approaches are 
> now clear 
> > > since they are the real owner of these solutions. If after these 
> > > healthy discussions, there are still some SPs/operators 
> who want to 
> > > go with LDP-based MAC withdraw for C-MACs in PBB-VPLS, 
> then I would 
> > > like to hear from them since they should have the final say.
> > >
> > > > night job! I wonder what will happen if we have to debate a 20 
> > > > page draft! :)
> > > >
> > > > Ali,
> > > >
> > > > I will summarize the point that is left on scalability to make 
> > > > some steps towards the closure:
> > > > procedure is broken - I prompted you to bring up any bad 
> > > > experience with implementing and deploying HVPLS, 
> MS-PWs and I did 
> > > > not see any reply.
> > >
> > > I have been saying that is a bad solution for C-MACs 
> because of the 
> > > above reasons (refer to the summary).
> > >
> > > Again, my issue is not with B-MAC flushing. As I said numerous 
> > > times, you can extend the B-MAC flush for C-MAC addresses but you 
> > > will create tons of interop issues down the road and if every SDO 
> > > does the same thing we will have a nightmare. You have 
> conveniently 
> > > sidestepping these interop issues and saying that they should be 
> > > taken care later.
> > >
> > > > - So we should conclude that this procedure is working 
> just fine 
> > > > in real life deployments.
> > > > - We are proposing an enhanced use of this LDP hop-by-hop 
> > > > procedure where compared with the above mechanism the 
> PE-rs do not
> > > perform any
> > > > The rest is just academic discussion. I will try to address 
> > > > in-line anything that resembles some scalability 
> discussion just 
> > > > because I
> > > like
> > > > Ali. :)
> > >

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Sat, 8 May 2010 21:21:22 -0500

Thanks Neil for the clarifications. I am familiar with your views and I see a consistent reasoning here.

I believe though we should not use the architectural considerations presented below to block enhancements of any particular MPLS toolset required to address particular MPLS deployment needs. We have across the 3 WGs active drafts like this, many of them more complex that the current L2VPN proposal under debate. To evaluate them we are bound to use the architectural documents that each WG developed and previous experience (implementation and deployment) to evaluate whether there are any technical issues and whether they are consistent with the previously used models.

Unless you intend to reopen the architectural discussion in the above WGs I suggest we close this thread, go back to l2vpn and focus on evaluating the proposed LDP MAC Flush extension based on the architectural documents and models developed in the L2VPN WG.

Florin

> Sent: Saturday, May 08, 2010 1:18 PM
> To: Balus, Florin Stelian (Florin); [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> > > > my previous email:

---

From: <[email-masked]>
Date: Mon, 10 May 2010 08:17:51 +0100

Thanks Florin,

I agree wrt to closing this thread here wrt points of historical
significance that have led us to where we are today.  I do hope,
however, that by providing this brief look at our heritage we can all
see/agree with the major point I am making...which is:

We should not be functionally coupling different layer networks.  This
has been a central tenet of why IP has been so successful in being able
to be carried over any lower layer network (ie "IP over
everything")....and this is literally all about adhering to the rigorous
architectural requirements of transparency and functional decoupling in
a client/server network.  We should therefore *consistently* practice
what we preach.

I simply provided this background so that one can see that my support of
Ali's position was not a random choice.....though my point is even
broader, ie for functional behaviour changes in layer network X (any
mode) then this should only be effected by changes to the DP/CP/MP
protocols of layer X and not some other layer network Y (any mode)
technology.

regards, Neil

> Sent: 09 May 2010 03:21
> To: Harrison,N,Neil,DKQ7 R; [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]; Heron,GDY,Giles,DMF R
> Thanks Neil for the clarifications. I am familiar with your 
> views and I see a consistent reasoning here.
> 
> I believe though we should not use the architectural 
> considerations presented below to block enhancements of any 
> particular MPLS toolset required to address particular MPLS 
> deployment needs. We have across the 3 WGs active drafts like 
> this, many of them more complex that the current L2VPN 
> proposal under debate. To evaluate them we are bound to use 
> the architectural documents that each WG developed and 
> previous experience (implementation and deployment) to 
> evaluate whether there are any technical issues and whether 
> they are consistent with the previously used models.
> 
> Unless you intend to reopen the architectural discussion in 
> the above WGs I suggest we close this thread, go back to 
> l2vpn and focus on evaluating the proposed LDP MAC Flush 
> extension based on the architectural documents and models 
> developed in the L2VPN WG.
> 
> Florin
> 
> > 'my views', they are simply conclusions from logical technical 
> > analysis so I have no choice in arriving at these facts.
> >
> > evidence they are a good idea and/or technically sound....which I 
> > would differentiate from good marketing of such ;-).
> >
> > Further, there are large time constants at play between cause and 
> > effect in networking....so it often takes a long time (and large 
> > scale) to start to get a feel for the real impacts of arch 
> > errors/complexity (and even then in my experience true 
> causal reasons 
> > are not always correctly identified).
> >
> > The reason why it is so easy to do the wrong things in the 
> co-ps mode 
> > is that resource assignment and labelling are decoupled 
> actions.  I'll 
> > not go into the underlying detail here, but it essentially 
> comes down 
> > to how we partition AND label a space/freq/time dimension of 
> > resource.....and in the co-ps mode this is all about the 
> labelling of 
> > irregular time-slices of resource.  Those who want to pursue the 
> > detail can look at G.800....and I am quite happy to go into 
> off-line 
> > technical detail.
> >
> > > I think this email goes well beyond the scope of this discussion 
> > > about a simple LDP extension for existing VPLS/MPLS deployments.
> >
> > say this.  However, I am merely showing why we are at this juncture 
> > and why, IMO, folks should stand back and look at the bigger 
> > networking picture instead of just ploughing on from where 
> we are now at.
> >
> > certain applications, but it has no basis in a transport 
> > network...which is why it (and PHP and ECMP) are excluded 
> in MPLS-TP.
> >
> > aware of my observations.  I guess however it's not easy to accept 
> > that MPLS-TP needs to do a little more than simple deprecate LDP, 
> > deprecate PHP, deprecate ECMP and take its  CP/MP OOB.  It 
> is, whether 
> > one likes it or not, a simple technical fact that a 
> properly designed 
> > co-ps mode transport network would not have sublayering nor 
> would it 
> > have PWs (or even functions like TTL).  These are all 'carry-over' 
> > artefacts due to the influence of LDP on MPLS's origins.
> >
> >
> >
> > > 3. PWs seem to be a wrong step as a "rather sad 
> consequence of the 
> > > architectural problems noted above" (probably referring 
> to 1 and 2)
> >
> > great detail why this is the situation.  However, I am also aware 
> > these exist now and we cannot simply remove/ignore them.  However, 
> > this is no excuse for not being technically accurate or 
> honest about them is it?
> > > If you or you and Ali want to debate these items I 
> suggest we split 
> > > the discussion as follows:
> >
> > forward?  We cannot change history..... what is done is 
> done, and we 
> > now live with that legacy.  However, we should try and stop making 
> > things worse going forward.
> >
> > >
> > > - issues 1. and 2. should be placed in one or more 
> different emails 
> > > addressed to MPLS WG
> should not 
> > > bother with any new developments in these areas. I think 
> we should 
> > > actually close the L2VPN and PWE3 WGs and leave it to IEEE to 
> > > develop everything.
> >
> > parties to 'agree' with the points I have made.  This, 
> however, does 
> > not detract from their technical accuracy of course.
> >
> > at a *technical level* the argument that 'it exists 
> therefore it must 
> > be right' does not follow if one is being strictly honest 
> with oneself 
> > as an engineer.  I have already conceded we need to 
> deal/live with our 
> > past mistakes...human history is full of mistakes.....but 
> when one has 
> > > > However, there is still a major problem with the handling of 
> > > > nested LSPs in MPLS-TP, ie MPLS as a client of MPLS.  In a 
> > > > nutshell, a transport network must not use sublayering 
> (ie the S 
> > > > bit,
> > > typical of
> > > > *single* layer network and it is not the client/server 
> > > > relationship between different layer networks wrt 
> nested LSPs that
> > > MPLS-TP requires
> > > > another co-ps mode (PW) layer network above MPLS/MPLS-TP.  Like 
> > > > LSP sublayering (S bit) these should also not exist in MPLS-TP.
> > >  So we are
> > > > client layer network.  In essence, transparency means that a 
> > > > server layer network must never try and infer meaning of client
> > > layer symbols
> > > > Ethernet access point addressing here.  MACinMAC (ie 
> PBB) OTOH is 
> > > > a proper client/server relationship and correctly functionally 
> > > > > subject and I hope this discussion has been 
> informative to our 
> > > > > SP colleagues and the pros/cons of these two approaches are
> > > now clear
> > > > > -       None ( based on this long email thread, no 
> one has pointed
> > a
> > > > > > With the reply below I think we are at a point 
> where we need 
> > > > > > to conclude it is ok to agree to disagree - this is
> > > supposed to be my
> > > > > For B-MACs !! and there is perfect reason for not 
> doing it for 
> > > > > C-MACs
> > > > > :-)
> > > > >
> numerous 
> > > > > times, you can extend the B-MAC flush for C-MAC addresses but 
> > > > > you will create tons of interop issues down the road and if 
> > > > > every SDO does the same thing we will have a 
> nightmare. You have
> > > conveniently

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 10 May 2010 12:31:15 -0700

Florin,

In all my previous emails on this thread, I never said there is an issue
with MPLS or PW (as you have listed below in response to Neil) so please
stop muddying the water and confusing the people. What I have said over
and over again is that the use of LDP for flushing C-MAC addresses in
PBB-VPLS is a bad idea and I have refuted your claims of the need for
re-certification and OSS changes !! and I have given you a list of
reasons as to why it is a bad idea to do C-MAC flushing using LDP and
why the native flush is a much better solution (e.g., faster service
convergence, works for E2E MPLS with both LDP and BGP signaling, works
with any mixed of network, etc.). However, I never heard back from you
to challenge me on re-certification or OSS changes or the benefits of
native flush over LDP-based approach, instead I have heard the
repetition of the same argument from you: "there is no issue with LDP
for VPLS and thus it should also be used for PBB-VPLS". I have explained
many time on this thread why the flushing of MACs in VPLS/H-VPLS is like
apples and oranges when compared to flushing of C-MACs in PBB-VPLS and I
won't repeat them here. With enough thrust you can make pig flies but it
doesn't mean there is something wrong with your thruster :-)

-Ali

> Sent: Saturday, May 08, 2010 10:29 AM
> Cc: [email-masked]; Ali Sajassi (sajassi);
> [email-masked]; [email-masked]
> I think this email goes well beyond the scope of this discussion about
> a simple LDP extension for existing VPLS/MPLS deployments.
> 3. PWs seem to be a wrong step as a "rather sad consequence of the
> architectural problems noted above" (probably referring to 1 and 2)
> If you or you and Ali want to debate these items I suggest we split
the
> discussion as follows:
> About issues 3 and 4: if this is the case then indeed we should not
> bother with any new developments in these areas. I think we should
> actually close the L2VPN and PWE3 WGs and leave it to IEEE to develop
> everything.
> 
> Personally I do not agree with the statements made for 3 and 4 and I
> think the large deployments around the world of the PWE3 and VPLS
> technologies is a proof that there was something right about them. But
> let's debate the specifics in the proper forums and see whether we
need
> to throw them away.
> judgement/comments...esp
cl-
> ps
> functional
> similar
> page
> experience
> procedure

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Mon, 10 May 2010 15:37:36 -0500

Ali,
I said "if you or you and Ali want to reopen the discussion". I did not say you want to re-open it. The beginning of your email clarifies the your position. I don't think the rest of your email is required - you already sent your summary of arguments to L2VPN after a long exchange.
Let's just restrict the distribution list back to L2VPN WG and leave it now to the WG to decide.
Thanks,
Florin

> From: Ali Sajassi (sajassi) [mailto:[email-masked]]
> Sent: Monday, May 10, 2010 12:31 PM
> Cc: [email-masked]; [email-masked]; [email-masked]
> about
> > - issue 3 is of interest for PWE3 - so let's do another email for
> that
> > one
> > PS: I am adding also MPLS, PWE3 WGs as I think they should be
> involved
> > in this discussion.
> >
> >
> > > clients equally and in a proper client/server sense.  Wrt to IP
> this
> > is
> > > > > - So we should conclude that this procedure is working just
> fine
> > in
> > > > > real life deployments.
> > > > > anything that resembles some scalability discussion just
> because
> > I
> > > > like
> > > > > Ali. :)
> > > >

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Mon, 10 May 2010 16:30:53 -0500

Ali,
I did not see before my initial reply the text at the end of your email below.

Can you limit yourself to a civilized language? The reference "something wrong with your thruster" is way out of line and I do not think the 3 WG lists are a place for such remarks!

Let's stick to technical debate - you sent your objections on the L2VPN list, I sent my replies, the WG will decide one way or another and I am fine with whatever is decided.
Florin

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 10 May 2010 14:57:54 -0700

Florin,

"With enough thrust you can make pigs fly" is an English adage. The
entire quote was:
" With enough thrust you can make pig flies but it doesn't mean there is
something wrong with your thruster :-)"

It was a light-hearted sentence and that's why you see the smiley face
":-)" at the end of the sentence. lighten up.

-Ali

> Sent: Monday, May 10, 2010 2:31 PM
> To: Ali Sajassi (sajassi)
> Cc: [email-masked]; [email-masked]; [email-masked];
> Subject: Inappropriate email content
> 
> 
> Ali,
> I did not see before my initial reply the text at the end of your
email
> below.
> 
> Can you limit yourself to a civilized language? The reference
> "something wrong with your thruster" is way out of line and I do not
> think the 3 WG lists are a place for such remarks!
> 
> Let's stick to technical debate - you sent your objections on the
L2VPN
> list, I sent my replies, the WG will decide one way or another and I
am
> fine with whatever is decided.
> Florin
> 
> > apples and oranges when compared to flushing of C-MACs in PBB-VPLS
> and
> > I
> > won't repeat them here. With enough thrust you can make pig flies
but
> > it
> > > 2. MPLS-TP requires some fixes - "there is still a major problem
> with
> > > MPLS-TP"
> > > - issues 1. and 2. should be placed in one or more different
emails
> develop
> > > > because one MUST only allow p2p and p2mp constructs
> (==connections)
> > > in
> nested
> > > > is the emergence of PWs, ie the treatment of clients other than
> IP
> > > and
> LSP
> > > > sublayering (S bit) these should also not exist in MPLS-TP.  So
> we
> > > are
> > > > of MPLS/PWs layer networks and an Ethernet layer network...and
> this
> > > is
> > > > a
> > > > layer network must provide transparency to a client layer
> network.
> > > In
> > > > essence, transparency means that a server layer network must
> never
> > > try
> > > > always treated in a transparent manner by whatever the server
> layer
> > > it
> > > > network then the only correct architectiral solution is to
> address
> > > this
> > > > > -       None ( based on this long email thread, no one has
> pointed
> > a
> > > > > > conclude it is ok to agree to disagree - this is supposed to
> be
> > > my
> > > > > For B-MACs !! and there is perfect reason for not doing it for
> C-
> > > MACs
> > > > > :-)
> > > > >
> > > > > > with implementing and deploying HVPLS, MS-PWs and I did not
> see
> > > any
> > > > > > reply.
> > > > >
> in-
> > > line

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Mon, 10 May 2010 17:08:07 -0500

There are jokes I can accept easily in a private setting and jokes with sexual connotation that are not acceptable, in my culture at least, on a public distribution list.

Florin

> Sent: Monday, May 10, 2010 2:58 PM
> To: Balus, Florin Stelian (Florin)
> Subject: RE: Inappropriate email content
>
> Florin,
>
> > > > Personally I do not agree with the statements made for 3 and 4
> and
> > I
> > > > technologies is a proof that there was something right about
> them.
> > > But
> > > > > layer network* that is providing a logically OOB CP/MP to
> manage
> > > the
> > > > > Now a rather sad consequence of the architectural problems
> noted
> > > > above
> > > > > MPLS....and when these are allowed to be multi-hop they
> generate
> > > yet
> > > > > coupling between different layer networks....and in particular
> a
> > > > server
> > > > > was carried over as a client, eg Ethernet, SDH VC4, PDH E1,
> etc,
> > > etc.
> > > > >
> > > > > One closing remark...I noted folks talking about QinQ in some
> of
> > > the
> > > > > to sublayering of LSPs in MPLS as-is.  That is, QinQ is also
> NOT
> > a
> > > > > client/server relationship and correctly functionally
> partitions
> > > the
> > > > > > > With the reply below I think we are at a point where we
> need
> > to

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 10 May 2010 15:21:09 -0700

"Thruster" in that sentence refers to the device that "thrust" the pigs to make them fly. Please refer to your dictionary before making an embarrassing statement of  "jokes with sexual connotation"

Definitions of thruster (n) [from merriam-webster dictionary]
thrust·er [ thrústər ]   
rocket that controls altitude: a rocket on a spacecraft or high-altitude aircraft that controls an altitude or flight path

This is my last reply on this subject as all these WG groups should not be copied for this kind of emails in first place !!

> Sent: Monday, May 10, 2010 3:08 PM
> There are jokes I can accept easily in a private setting and jokes with
> sexual connotation that are not acceptable, in my culture at least, on
> a public distribution list.
> 
> Florin
> 
> > > > In all my previous emails on this thread, I never said there is
> an
> > > > issue
> > > > stop muddying the water and confusing the people. What I have
> said
> > > over
> > > > and over again is that the use of LDP for flushing C-MAC
> addresses
> > in
> > > > with any mixed of network, etc.). However, I never heard back
> from
> > > you
> > > > to challenge me on re-certification or OSS changes or the
> benefits
> > of
> > > > many time on this thread why the flushing of MACs in VPLS/H-VPLS
> is
> > > > like
> discussion
> > > > > architectural problems noted above" (probably referring to 1
> and
> > 2)
> > > > > - issue 4 is for L2VPN WG but should be debated on another
> email
> > > > > thread.
> > > > >
> > > > > > when it comes to Ethernet. This is based on personal
> experience
> > > of
> > > > > > dealing with him.
> > > > > >
> > > > > > Wearing a G.800 functional architecture hat I could very
> easily
> > > > write
> > > > > > and causes complexity/problems.  Indeed, one need only look
> at
> > > the
> > > > > > order to provide deterministic resource to clients.....which
> is
> > a
> > > > > > fairly
> > > > > > architectural problems with MPLS is that it does not treat
> all
> > > its
> > > > > > also being addressed in MPLS-TP....and the key point here
> being
> > > the
> > > > > > network must not use sublayering (ie the S bit, typical of
> how
> > > > nested
> > > > > > LSPs appear today) as this is simply partitioning of a
> *single*
> > > > layer
> > > > > > layer networks wrt nested LSPs that MPLS-TP requires *if* it
> is
> > > to
> > > > > > VPLS IMO is yet another errors that builds on the arch
> mistakes
> > > > noted
> > > > > > them.  IP has been very successful because it always ensured
> it
> > > was
> > > > > > DP/CP/MP actions in a different server layer network which
> are
> > > then
> > > > > > client/server relationship but simply a form of partitioning
> a
> > > > single
> > > > > > > -       No additional interop solution development,
> testing,
> > > and
> > > > > > > operating
> > > > > > > Cons:
> > > > > > > > night job! I wonder what will happen if we have to debate
> a
> > > 20
> > > > > page
> > > > > > > > draft! :)
> > > > > > > >
> > > > > > > > Ali,
> > > > > > > >
> > > > > > > > - I asked you to highlight also any initiative targeted
> at
> > > > fixing
> > > > > > > these
> just