Subject: RE: I-D ACTION:draft-ietf-pwe3-fragmentation-08.txt

From: "Yang, Seung Yeop \(Seung Yeop\)" <[email-masked]>
Date: Thu, 17 Feb 2005 09:53:55 -0500

Hi Andy,

Thank you for your reply.

May I ask you another question?
Does PWE3 has independent PW layer from protocol perspective?
As for me, the PWE3 architecture document described it as an independent
layer model, but my impression from other encapsulation documents is
like the PW is a kind of extension from MPLS or L2TP. In other words, it
looks like MLPS dependent PW or L2TP dependent PW. It might be from the
lack of the solid PSN convergence layer that could decouple PSN and PW.

Is my understanding corret? Please, correct me if I'm wrong.

Thanks,
Seung Yeop.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Andrew G. Malis
> Sent: Wednesday, February 16, 2005 3:03 AM
> To: Seung Yeop Yang
> Cc: [email-masked]
> Subject: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-fragmentation-08.txt
> 
> 
> Seung Yeop,
> 
> Fragmentation is an additional optional function added to the 
> encapsulation 
> layer, rather than a separate layer.  It uses two bits 
> reserved for the 
> function in the CW, and re-uses the same sequence number field in the 
> CW.  The reason that it's in a separate draft is that it's a common 
> function across a number of encapsulations, and this way we 
> don't have to 
> repeat that same text in every encapsulation draft.  As Mark 
> said, the only 
> purpose for the fragmentation is to allow PWE3 to function in 
> environments 
> where the encapsulated packets would be larger than the path MTU, and 
> dropped by the network as a result.
> 
> Cheers,
> Andy
> 
> ----------
> 
> At 2/15/2005 11:02 AM -0800, Seung Yeop Yang wrote:
> >Thank you, Mark and Andy.
> >
> >Please, let me ask you another question.
> >
> >As this fragmentation document is related only MTU-issue, 
> then it's the
> >function of PWE3 demultiplexer layer as described in PWE3 
> architecture 
> >I-D, and multilink PW should be carried on PW encapsulation layer.
> >Is my understanding correct?
> >
> >Then PW-CW is used for reassembly in demux layer, is it 
> still valid to 
> >be
> >used for PW encapsulation layer?
> >Then where is the PW-CW termination layer, is it 
> demultiplexer layer or 
> >encapsulation or both?
> >
> >Regards,
> >Seung Yeop.
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Seung Yeop Yang <[email-masked]>
Date: Thu, 17 Feb 2005 11:39:04 -0800 (PST)

Andy,

Yes, I can see that it will be efficient to use label stacking if it is Single Hop PW case.
 
But, how about multi-hop PW case among distinct PSNs or series of them? 
If we had an independent PW layer, then we could easily switch in the intermediate systems.
However, currently, we have to terminate incoming PSN and remap to outgoing PSN like interworking or gateway function.
 
Isn't it a big pain for the intermediate system?
 
Thanks in advance,
Seung Yeop.
 
p.s. Something is wrong with my company's e-mail system. I can't get e-mails from the account.

"Andrew G. Malis" <[email-masked]> wrote:
Seung Yeop,

Well, you can think of PWs being a separate layer in the abstract, but in 
the implementation we chose to pragmatically take advantage of features in 
MPLS and L2TPv3 that enable the PW layer (such as the MPLS label 
stack). It was the combination of the label stack, and the need to 
standardize and automate previous proprietary, manually provisioned L2 over 
IP or MPLS approaches, that got people thinking about this in the first place.

Cheers,
Andy

---------

>Is my understanding corret? Please, correct me if I'm wrong.

---------------------------------
Do you Yahoo!?
 Yahoo! Search presents - Jib Jab's 'Second Term'

---

From: "Yang, Seung Yeop \(Seung Yeop\)" <[email-masked]>
Date: Thu, 17 Feb 2005 16:15:31 -0500

Scott,

That's why I'm wondering as below. 
Do you have any comments? Any comments will be appreciated.

Regards,
Seung Yeop.
-----------------------------------------------------------------------
Andy,

Yes, I can see that it will be efficient to use label stacking if it is
Single Hop PW case.
 
But, how about multi-hop PW case among distinct PSNs or series of them? 
If we had an independent PW layer, then we could easily switch in the
intermediate systems.
However, currently, we have to terminate incoming PSN and remap to
outgoing PSN like interworking or gateway function.

Thanks in advance,
Seung Yeop.
 
p.s. Something is wrong with my company's e-mail system. I can't get
e-mails from the account.

Well, you can think of PWs being a separate layer in the abstract, but
in 
the implementation we chose to pragmatically take advantage of features
in 
MPLS and L2TPv3 that enable the PW layer (such as the MPLS label 
stack). It was the combination of the label stack, and the need to 
standardize and automate previous proprietary, manually provisioned L2
over 
IP or MPLS approaches, that got people thinking about this in the first
place.

Cheers,
Andy
-----------------------------------------------------------------------

-----Original Message-----
From: Scott W Brim [mailto:[email-masked]] 
Sent: Thursday, February 17, 2005 4:00 PM
To: Yang, Seung Yeop (Seung Yeop)
Cc: Andrew G. Malis; Seung Yeop Yang; [email-masked]
Subject: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-fragmentation-08.txt

A single-hop pseudowire is not a separate layer network, but an
adaptation function to the server layer network (e.g. MPLS).
Multi-hop pseudowires are a different kind of animal entirely.
Fragmentation is considered to be one or more sublayers.

Scott

On Thu, Feb 17, 2005 09:53:55AM -0500, Yang, Seung Yeop (Seung Yeop)

---

From: [email-masked]
Date: Thu, 17 Feb 2005 23:37:38 -0000

Absolutely right Scott.  Neil

> Behalf Of Scott W Brim
> Sent: 17 February 2005 21:00
> A single-hop pseudowire is not a separate layer network, but 
> an adaptation function to the server layer network (e.g. 
> MPLS). Multi-hop pseudowires are a different kind of animal 
> entirely. Fragmentation is considered to be one or more sublayers.
> 
> Scott
> 
> 
> On Thu, Feb 17, 2005 09:53:55AM -0500, Yang, Seung Yeop 
> (Seung Yeop) allegedly wrote:
> > Hi Andy,
> > 
> > Does PWE3 has independent PW layer from protocol 
> perspective? As for 
> > me, the PWE3 architecture document described it as an independent 
> > like the PW is a kind of extension from MPLS or L2TP. In 
> other words, 
> > it looks like MLPS dependent PW or L2TP dependent PW. It 
> might be from 
> > the lack of the solid PSN convergence layer that could decouple PSN 
> > and PW.
>

---

From: [email-masked]
Date: Thu, 17 Feb 2005 23:37:39 -0000

Andy....I wish more folks would make the effort to get familar with how
to formally describe layer networks in func arch terms (ie G.805 and
G.809), if they did much of the confusion we see might not exist.

Seung Yeop...let me try and explain what is the problem here.  When we
have a client/server relationship between 2 layer networks one needs a
way to adapt the client traffic units into the server traffic units.
Now there are 3 network modes...cl-ps, co-ps and co-cs.  These are not
the same (despite what you will undoubtably hear to the contrary), and
the adaptation functions between pairs of these (there are 9 potential
combinations here) are not the same either.  The key requirement in
*any* client/server relationship is layer independence.  Sadly, PWE3
decided to break this rule early on. {Aside - the familar expression 'IP
over everything' owes its very existence to the fact that this rule was
not broken for IP, ie IP critically (and correctly) relies on the
functional decoupling of IP from anything it is transported over, which
is precisely what G.805 requires.  A case of '1 rule for me and another
rule for you' IMO.}

Now IP!=MPLS, but being IETF we are not allowed to say this too loudly
;-).  So PWs assumed we had to have a common adaptation for XoverIP and
XoverMPLS.....however, folks know that stuff has already diverged from
this for practical reasons (because indeed IP!=MPLS).  A similar
striking example of the modal differences is GMPLS, where the co-cs mode
forces things like OOB control, no merging, no QoS classes and crucially
allows client/server decoupling.

MPLS was orginally only intended to work only with an IP client.....this
is why there is no adaptation for an IP client.  Then some folks decided
it would be a good idea to carry other layer network types over MPLS
(and IP)....ergo PWs were spawned.  

Now whilst a PW was nothing more that an adaptation function for mapping
client X to MPLS (or IP) then things weren't too bad.  In other words we
don't 'network' adaptation functions....and the PW adaptation function
(no matter how good/bad one considered it) was a static mapping at the
end of an MPLS trail (LSP) or an IP flow.  The problems arise however
when folks want to make PWs a networked function, ie more than 1 hop.
Now, like it or not, a PW starts to take on the characteristics of a
layer network....which I beleive was your orginal observation, and if so
you are correct.  And one also invokes the nasty potential consequence
of having to interwork PWs where one network partition uses XoverIP and
the other XoverMPLS.

But as I noted above, all this func arch stuff is not that well
understood in my experience and folks don't look at networking in these
terms here (more is the pity IMO).

Does that help?  If you want to learn more about func arch and why we
consider it so very important (because its the precursor to good NE
specifications and management information models) I can point you to a
couple of textbooks...let me know if you are interested off-list.

regards, Neil

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Andrew G. Malis
> Sent: 17 February 2005 17:42
> Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-fragmentation-08.txt
> 
> 
> Seung Yeop,
> 
> in the implementation we chose to pragmatically take advantage
> of features in 
> >Does PWE3 has independent PW layer from protocol perspective? As for
> >me, the PWE3 architecture document described it as an
> independent layer
> >model, but my impression from other encapsulation documents
> is like the
> >PW is a kind of extension from MPLS or L2TP. In other words,
> it looks
> >like MLPS dependent PW or L2TP dependent PW. It might be
> from the lack
> >of the solid PSN convergence layer that could decouple PSN and PW.
> >

---

From: "Yang, Seung Yeop \(Seung Yeop\)" <[email-masked]>
Date: Fri, 18 Feb 2005 10:06:16 -0500

Neil,

As attached below, you, Scott, and I are all in same page with regard to
MH-PW case.
IMHO, the first step is to decouple PSN and PW to make PW as an
independent network layer from PSN.

What's your idea to solve this problem?

Regards,
Seung Yeop.

p.s. Yes, I would like to learn more. Would you please send me the
titles or authors of the books?

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, February 17, 2005 6:38 PM
> To: [email-masked]; Yang, Seung Yeop (Seung Yeop)

Snip..
> 
> Now whilst a PW was nothing more that an adaptation function 
> for mapping client X to MPLS (or IP) then things weren't too 
> bad.  In other words we don't 'network' adaptation 
> functions....and the PW adaptation function (no matter how 
> good/bad one considered it) was a static mapping at the end 
> of an MPLS trail (LSP) or an IP flow.  The problems arise 
> however when folks want to make PWs a networked function, ie 
> more than 1 hop. Now, like it or not, a PW starts to take on 
> the characteristics of a layer network....which I beleive was 
> your orginal observation, and if so you are correct.  And one 
> also invokes the nasty potential consequence of having to 
> interwork PWs where one network partition uses XoverIP and 
> the other XoverMPLS.
> 
> regards, Neil
> 

Snip.. 

> entirely. Fragmentation is considered to be one or more sublayers.

Snip.. 

> From: Seung Yeop Yang [mailto:[email-masked]] 
> Sent: Thursday, February 17, 2005 2:39 PM
> To: Andrew G. Malis; Yang, Seung Yeop (Seung Yeop)
intermediate systems.
> However, currently, we have to terminate incoming PSN and remap to
outgoing PSN like interworking or gateway 
> function.

> > in the implementation we chose to pragmatically take advantage of 
> > features in MPLS and L2TPv3 that enable the PW layer (such 
> as the MPLS 
> > label

---

From: Scott W Brim <[email-masked]>
Date: Fri, 18 Feb 2005 10:23:15 -0500

> independent network layer from PSN.

Slow down please.  I just answered one of your questions.  Multihop 
PWs already are a separate layer, in formal architectural terms, by 
their nature.  In terms of instantiation I don't think some vast 
decoupling project is necessary.

---

From: [email-masked]
Date: Fri, 18 Feb 2005 15:40:27 -0000

Seung Yeop,

Please see below....

> From: Yang, Seung Yeop (Seung Yeop) [mailto:[email-masked]] 
> Sent: 18 February 2005 15:06
> To: Harrison,N,Neil,IKM1 R; [email-masked]; [email-masked]
> Cc: [email-masked]
> As attached below, you, Scott, and I are all in same page 
> with regard to MH-PW case. IMHO, the first step is to 
> decouple PSN and PW to make PW as an independent network 
> layer from PSN.
> 
NH=> Ah it were only so simple!  If you really want to solve the problem
you are have to going to unravel all the problems that created it in the
1st place (PWs are a symptom, they are not the cause)....and I am afraid
there is too much sunk interest now to allow that.  But if you really
want to know here's a summary:
-	First, you have to be really clear about func arch and the
nature of the 3 modes....they are different and you cannot treat them
the same.  One key thing you cannot do is assume you can 'functionally
crunch' them all, eg single instance of addressing or routing or OAM or
whatever from IP to optics.  This is most obvious for the co-cs mode
(GMPLS) where stuff like OOB control/management is forced.
-	Second, you need be clear what are the functional components and
arch rules of the mode you are dealing with.  In the co-ps mode you
should never do merging (so that means LDP mp2p and PHP are bad
news....and I perhaps should add ECMP to that list of 'not good
things').  Then we must address the functional deficiencies...where the
most obvious missing things are:  no consistent access point addressing
on LSPs, no OOB control/management, no good OAM (see Y.1711 if you want
to understand what I mean by good OAM...the concepts are general to the
co-ps mode and not MPLS specific).
-	Thirdly, you must respect the rules of client/server layer
network relationships....key of which is client/server functional
independence.  There are many reasons why this is important.  But a
particularly key one is the ability to create a network builder service.
MPLS is based on a digital wrapper and it is not possible to do
this....except by inserting a PW to create a functional breakwater
between the MPLS networks of 2 parties, where one party simply wants to
lease capacity off the other party without any notion of 'peering'.

You should however note that I regard the idea of PWs as a layer network
in their own right quite abhorent and not necessary.  However, this
requires accepting that XoverMPLS != XoverIP....and having consistent
solutions for MPLS as the server layer that are largely agnostic of its
client.

But as I said....its all too far gone now to fix IMO.
> 
> Regards,
> Seung Yeop.
> 
> p.s. Yes, I would like to learn more. Would you please send 
> me the titles or authors of the books?
NH=> Will do.

regards, Neil
> > > Subject: RE: [PWE3] I-D 
> ACTION:draft-ietf-pwe3-fragmentation-08.txt
> > > 
> > > 
> > > Seung Yeop,
> > >

---

From: Seung Yeop Yang <[email-masked]>
Date: Fri, 18 Feb 2005 14:46:20 -0800 (PST)

Hi Neil and Scott,
 
Thank you for your reply, and Have a nice weekend!!
 
May I ask you a couple of more questions?
 
Scott is telling that MH-PW are already separate layer; you are telling there are a lot of functional deficiencies to do MH-PW, and you think that it is not necessary to make as a layer network because sunken interests and gone too far in SH-PW or SH-PW/MPLS? 
 
Does XoverMPLS != XoverIP means that if the PW is only over MPLS or only over IP, then it's O.K. to have PW as it is because it can be processed as SH-PW?
 
Any comments will be appreciated.
 
Thanks in advance,
Seung Yeop.

[email-masked] wrote:
Seung Yeop,

Please see below....

NH=> Will do.

regards, Neil

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: [email-masked]
Date: Sat, 19 Feb 2005 12:40:55 -0000

Please see below...

-----Original Message-----
From: Seung Yeop Yang [mailto:[email-masked]] 
Sent: 18 February 2005 22:46
To: Harrison,N,Neil,IKM1 R; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-fragmentation-08.txt

Hi Neil and Scott,

 
Scott is telling that MH-PW are already separate layer; 
NH=> Scott is right....this is what is being created, though I'm not
sure all folks see this.  Whether it will get specified correctly or not
is a different question.  My observations were:
-    well, if we have MPLS under the PW 'layer' don't you think its
makes more sense to make sure the MPLS layer network is sorted first (ie
before paying attention to the PW layer)?
-    but I then observed that I don't see how that it will be possible
to unpick what has already been done in MPLS.
 
  you are telling there are a lot of functional deficiencies to do
MH-PW, 
NH=> Not exactly, I am saying MPLS per se has some issues IMO.....this
has nothing to do with PWs.
 
  and you think that it is not necessary to make as a layer network
because sunken interests and gone too far in SH-PW or SH-PW/MPLS? 
NH=> Again not exactly....I am saying if MPLS was truly 'Multi-Protocol'
then (i) it would have been developed as a layer in its own right from
the outset and (ii) IP would have been just another client treated like
any other. 
 
Does XoverMPLS != XoverIP means that if the PW is only over MPLS or only
over IP, then it's O.K. to have PW as it is because it can be processed
as SH-PW? 
NH=> No, what I meant was that the cl-ps, co-ps and co-cs modes are
different....and the client/server relationships between them are not
the same (which also impacts inheritance).  My 2nd point here was that
by attempting to 'equate' a PW over MPLS and a PW over IP you end up
creating a peer-partition interworking problem, eg the LDP signalling
protocol used in MPLS say is not the same as that used in L2TPv3
say.....so you now have now created a protocol conversion problem.
 
regards, Neil

Thanks in advance,
Seung Yeop.

Seung Yeop,

Please see below....

NH=> Will do.

regards, Neil