Re: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

[<[e-mail]>]

Colleagues,
 
I think there are some important issues here that appear not to be being tackled correctly...and if we do not get our thinking/arch straight here these issues will not go away but surface time and time again until we are finally forced to properly resolve them.  Here is my take on the salient points.
 
1    I saw an astute observation from Sasha on the PW CP.  And he was right to raise this.  This harps back to my long-standing observation to PWE3 that once PWs become multi-hop they create a new co-ps layer network above MPLS instead of being just client/server adaptation function (1-hop case).  The deeper history behind this is related to (i) the requirement in MPLS LDP for IP to run raw in the DP to provide CP/MP functions, and (ii) the fact that LDP creates mp2p merging LSP constructs.  The important consequence of the latter point being that a PW label must convey source information semantics to recover this lost information due to lower level LDP LSP merging.  There is a further, and still largely unrecognised IMO, problem in that when PWs move from 1-hop to multi-hop entities the PW label needs to change semantic from 'source information' to 'forwarding information'......I explained this issue in detail in a (PWE3) mail to Matthew Bocci  29/11/2008...I attach for ease of reference.
 
====
 
 
2    In MPLS-TP we need to be able to deterministically manage resource (because MPLS-TP is supposed to be a next gen transport network, and resource management is a principle requirement of transport networks).  This means we must only create p2p and p2mp LSPs in MPLS-TP.....mp2p LSPs do not allow deterministic resource management because they are not single source *connection* constructs (G.800 explains why this is so). 
 
In MPLS-TP we are also required to take the CP/MP IP-based protocols out of the traffic DP and run them in the logically OOB G-ACH link between adjacent MPLS-TP nodes.....so this correctly follows the OOB CP/MP behaviour we are forced to use for the co-cs mode in GMPLS.  
 
All these factors mean that the arch conditions that created PWs in MPLS no longer exist in MPLS-TP.  Put very simply/bluntly, there is no reason to have PWs in MPLS-TP at all....that is just a technical fact.  However, such a bald technical statement could be considered rather embarrassing (for want of a better word) given how much effort has gone into PW related topics so far.  Given this, what we can therefore do is keep PWs, in-name at least, but be very clear we must not create a co-ps mode PW layer network above MPLS-TP.   And this is a very good thing because we can avoid generating a whole raft of DP/CP/MP functions unnecessarily....which addresses Sasha's observation on the PW CP above, ie there is no need for a PW CP because there is not a PW layer network in MPLS-TP, and its also addresses my previous point on the changing nature of a PW label, ie the problem goes away because MS PWs are not allowed in MPLS-TP.
 
===
 
 
3    Let me now turn to section 3.4.1 of the draft under discussion.  Firstly, I see talk of 'network layer' protocols which harps back to the flawed OSI Ref Model architecture.  We really should leave the OSI RM behind now because we should know (especially those who have been exposed to functional architecture, and in particular G.800 unified modelling of networks) that any technology that has routing/switching is a 'network layer' protocol by definition.  Further, the L1, L2 and L3 classifications of technology are meaningless at best, and the only thing that really matters is the cl-ps, co-ps and co-cs mode classification of networks....no mode is more important than the others, but each is different and all are required in a complete network architecture model.
 
===
 
 
4    It would appear from from what is said in section 3.4.1 that (i) we can miss-out the PW adaptation for *DP* IP, MPLS and MPLS-TP clients and (ii) we can select an arbitrary/normal forwarding label to identify each of these clients (S=1 in this BOS header).  I don't think this is a good idea.
 
Let me deal with the 2nd issue first:  This works fine under defect-free conditions.  But what about the case of misconnectivity (including unintended replication/merging defects)?  So here it would seem that we have a 1st-order combinatorial '2 out of 4' potential misconnectivity problem, ie across IP/MPLS/MPLS-TP/PW cases (its actually worse than this as MPLS is not singular).  If we are serious about using this 'BOS label' technique to identify the client carried under all conditions (ie including all misconnectivity cases) we really should be using labels that have a globally well-known semantic.  In func arch speak we are creating a case of consistent CI...and this is also why the OAM used on each LSP in the whole network needs to be the same, ie under any case of misconnectivity the receiving node knows how to parse and read the semantic of the information it sees (be this a label/header or OAM).
 
Wrt to the 1st issue above:  IMO it would be usually be preferable to have a single/consistent way to deal with all clients.  So no matter what they are they would always be encapsulated via a common PW adaptation function (which can include a common PID function).  This is a cleaner/consistent architectural approach.
 
====
 
 
5    There is an important issue I ducked above (on purpose, because it warrants examination on its own), and that is LSP nesting as sublayers, ie the S bit issue.  This is particularly important because there will be a requirement on MPLS-TP to be able to create a functionally decoupled case of MPLS-TPoverMPLS-TP....that is, where the MPLS-TP layer network of one party is carried transparently (all 3 traffic/control/management planes) over the (*traffic DP*) of a server MPLS-TP layer network owned by a different party.
 
 In the past we have discussed dealing with this by the insertion of a degenerate 1-hop Ethernet PW to create a 'functional breakwater' between the 2 MPLS networks.  This however in neither elegant nor efficient.  So we need a better solution IMO.
 
In the past I suggested we should select a special label from the reserved set (ie 0-15) to identify this functional breakwater between different LSP stacks (so the S bit could be treated independently in each.  So this approach would tie-in with the first case issue discussed under item 4 above, ie MPLS-TP as a client would have its own special label (just like the IP and MPLS cases too).
 
Alternatively we could use the approach discussed under the second case in item 4 above, ie a consistent treatment of all clients using a common PW adaptation (that could include a common PID function).
 
===
 
I assume some/all of the above has been discussed within the MEAD team, and it would be useful to hear what analysis/conclusions were reached on the above topics and why this was.
 
Would someone from the MEAD team (Stewart or Adrian maybe?) be able to comment on the above please?
 
thanks.....regards, Neil
 


________________________________

	From: Jiang Yuan-long [mailto:[e-mail]] 
	Sent: 21 August 2009 02:59
	To: Yong Lucy; [e-mail]; 'Drake, John E'
	Cc: [e-mail]; Harrison,N,Neil,DEY2 R; [e-mail]
	Subject: Re: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"
	
	
	Lucy, 
	 
	Please see my comments inline.
	 
	  Thanks 
	Yuanlong Jiang

		----- Original Message ----- 
		From: Yong Lucy <mailto:[e-mail]>  
		To: 'Jiang Yuan-long' <mailto:[e-mail]>  ; [e-mail] ; 'Drake, John E' <mailto:[e-mail]>  
		Cc: [e-mail] ; [e-mail] ; [e-mail] ; [e-mail] ; [e-mail] 
		Sent: Friday, August 21, 2009 3:14 AM
		Subject: RE: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"
		
		

		Hi Jiang and John,

		 

		IMO. MPLS-TP supports two types of client: client network layer and client non-network layer. IP can be as client in both cases. The matter is that transport characteristics in two methods have some differences. As the result, to carry a L3 network client, it is required to use the service label. This is what I try to get clarification from John.

		 

		[J]: I don't understand what you meant in the differences of transport characteristics (in the last Email, you said the PW does not guarantee link characteristics),IMO, PW can also be a bidrectional p2p connection. From the discussion with Matthew and Sasha, I think the service label may be a PW label actually.

		 

		In fact, both PW label and service label are the bottom label. (S=1). This is the importance. Separating them is to distinguish server transport methods, not much to the payload itself. 

		 

		[J]: Yes, in the data plane, PW label and service label is undistinguishable. But how the egress node will process the demultiplexed IP payload? I think there are some subtle processing differences: 

		  1) If the bottom label is a non-PW label, then the IP packet will be routed, as in L3VPN; 

		  2) If the bottom label is a PW label, then the IP packet will just be encapsulated with some data link header and forwarded (no routing is needed), as arp-mediation draft demonstrates. 

		Do you think so?

		 

		 

		Regards,

		Lucy

		 

		
________________________________


		From: Jiang Yuan-long [mailto:[e-mail]] 
		Sent: Wednesday, August 19, 2009 10:20 PM
		To: [e-mail]; Drake, John E
		Cc: [e-mail]; Yong Lucy; [e-mail]; [e-mail]; [e-mail]; [e-mail]
		Subject: Re: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

		 

		Hi Liu,

		 

		Mapping our discussion topic to the nomenclature of this draft, it is:

		Can this service label be a PW label when the payload is IP?

		 

		Thanks,

		Yuanlong

			----- Original Message ----- 

			From: [e-mail] 

			To: Drake, John E <mailto:[e-mail]>  

			Cc: [e-mail] ; Yong Lucy <mailto:[e-mail]>  ; [e-mail] ; [e-mail] ; [e-mail] ; [e-mail] ; Jiang Yuan-long <mailto:[e-mail]>  

			Sent: Thursday, August 20, 2009 9:53 AM

			Subject: RE： [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

			 

			
			hi,all 
			I reviewed section 3.4.1 in draft-ieft-mpls-tp-framework-02, for all cient services, there is a unite service label(s=1) to identify procotol payload type, and The mapping between protocol payload type and Service Label is either configured or signaled. 
			if this section will not changed in the future. I think that it is unnecessary to continue to disscuss the topic. 
			
			how about all? 
			
			best regards 
			liu

 

 

			
			
			
			

"Drake, John E" <[e-mail]> 
发件人:  [e-mail] 

2009-08-20 04:31 

收件人

"Yong Lucy" <[e-mail]>, "Jiang Yuan-long" <[e-mail]>, <[e-mail]>, <[e-mail]> 

抄送

[e-mail], [e-mail] 

主题

[mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE:        [PWE3] An error in RFC 4446"IANA Allocations        for        PseudowireEdge to Edge Emulation (PWE3)"

 

 

 


ie

			
			
			
			Lucy,
			
			I'm sorry but I don't understand your conclusion.  I think your
			penultimate sentence is correct but I don't understand its relevance,
			and your last sentence appears to have precipitated a layer inversion.
			
			Section 3.4.1 deals with client network layer payloads, where 'network
			layer' is defined in RFC 3031 to be "synonymous with layer 3".
			
			Thanks,
			
			John  
			
			> -----Original Message-----
			> From: Yong Lucy [mailto:[e-mail]] 
			> Sent: Wednesday, August 19, 2009 12:44 PM
			> To: Drake, John E; 'Jiang Yuan-long'; [e-mail]; 
			> [e-mail]
			> Cc: [e-mail]
			> Subject: RE: [PWE3] An error in RFC 4446"IANA Allocations for 
			> PseudowireEdge to Edge Emulation (PWE3)"
			> 
			> Hi John,
			> 
			> One clarification on this:
			> 
			> When client network layer over MPLS-TP LSP directly, the 
			> method implies that client network layer can use this MPLS-TP 
			> LSP as a client network link because the LSP is a 
			> bidirectional point to point connection. When client traffic 
			> over a PW, the PW does not guarantee link characteristics.
			> Therefore, the method only applies to client non-network layer.
			> 
			> Is my understanding correct? 
			> 
			> Regards,
			> Lucy
			> 
			>  
			> 
			> > -----Original Message-----
			> > From: [e-mail] [mailto:[e-mail]] 
			> On Behalf 
			> > Of Drake, John E
			> > Sent: Wednesday, August 19, 2009 8:09 AM
			> > To: Jiang Yuan-long; [e-mail]; [e-mail]
			> > Cc: [e-mail]
			> > Subject: Re: [PWE3] An error in RFC 4446 "IANA Allocations for 
			> > PseudowireEdge to Edge Emulation (PWE3)"
			> > 
			> > Yuanlong Jiang,
			> > 
			> > Please see section 3.4.1 of the MPLS TP Framework I-D:
			> > 
			> > http://www.ietf.org/id/draft-ietf-mpls-tp-framework-02.txt
			> > 
			> > It describes how client network layer payloads (e.g., IP 
			> and MPLS) are 
			> > carried directly, i.e., without a pseudo-wire, over an MPLS 
			> TP server 
			> > network.
			> > 
			> > Client non-network layer payloads still use pseudo-wires.
			> > 
			> > Thanks,
			> > 
			> > John
			> > 
			> > > -----Original Message-----
			> > > From: Jiang Yuan-long [mailto:[e-mail]]
			> > > Sent: Tuesday, August 18, 2009 7:21 PM
			> > > To: [e-mail]; [e-mail]
			> > > Cc: [e-mail]
			> > > Subject: Re: [PWE3] An error in RFC 4446 "IANA Allocations for 
			> > > PseudowireEdge to Edge Emulation (PWE3)"
			> > >
			> > > Neil,
			> > >
			> > > Thank you for your reply.
			> > > As Himanshu said in the last email, 0x000B is actually 
			> the PW type 
			> > > for IP, rather than L2TP PW type for IP. So I believe it is also 
			> > > feasible for MPLS-TP.
			> > >
			> > > I agree with you that there is some difficulty for MPLS 
			> label stack 
			> > > to operate in the same manner as client/server layering 
			> model, but 
			> > > an adaptation layer such as PW functions now is indispensable.
			> > >
			> > >  Best Regards
			> > > Yuanlong Jiang
			> > >
			> > >
			> > >
			> > >
			> > >
			> > >                  ----- Original Message -----
			> > >                  From: [e-mail]
			> > >                  To: [e-mail] ; [e-mail]
			> > >                  Cc: [e-mail]
			> > >                  Sent: Wednesday, August 19, 2009 4:16 AM
			> > >                  Subject: RE: [PWE3] An error in RFC 4446 "IANA Allocations for 
			> > > Pseudowire Edge to Edge Emulation (PWE3)"
			> > >
			> > >                  Hi Yuanlong Jiang,
			> > >
			> > >                  Where you said below:
			> > >                  "I also wonder whether we should define a PW type for 
			> IP payload so 
			> > > that everything on PW is possible"
			> > >
			> > >                  This is precisely what a key consequence of MPLS-TP is, 
			> ie in the 
			> > > LDP spin of MPLS we had to define PWs (one reason being that LDP 
			> > > requires that IP traffic units can run native in the DP with MPLS 
			> > > traffic units), but given we can't have IP in the MPLS-TP 
			> DP and we 
			> > > can't have LDP mp2p merging constructs in MPLS-TP anyway 
			> (the latter 
			> > > point is all about resource management determinism) then the 
			> > > original driver for PWs is gone.....just a fact.  So now 
			> everything 
			> > > is a PW and nothing is a PW....that is, we just have 
			> clients (any) 
			> > > of MPLS-TP.
			> > >
			> > >                  We still have a tricky issue with the S bit that is not fully 
			> > > understood IMO yet (S bit => sublayering, as opposed to true 
			> > > client/server layering), which is also related to the important 
			> > > topic of being able to do MPLSoverMPLS as a proper client/server 
			> > > relationship.
			> > >
			> > >                  So what you point out below will be the case in MPLS-TP anyway 
			> > > (though I'm not sure everyone is comfortable with the 
			> acceptance of 
			> > > this fact yet)
			> > >
			> > >                  regards, Neil
			> > >
			> > >
			> > >
			> > > ________________________________
			> > >
			> > >                                   From: [e-mail]
			> > > [mailto:[e-mail]] On Behalf Of Jiang Yuan-long
			> > >                                   Sent: 18 August 2009 14:01
			> > >                                   To: [e-mail]
			> > >                                   Cc: [e-mail]
			> > >                                   Subject: [PWE3] An error in RFC 4446 "IANA 
			> Allocations for 
			> > > Pseudowire Edge to Edge Emulation (PWE3)"
			> > >
			> > >
			> > >                                   Hi, all:
			> > >
			> > >                                   I came accross an error in RFC 4446 "IANA 
			> Allocations for 
			> > > Pseudowire
			> > >                                   Edge to Edge Emulation (PWE3)".
			> > >
			> > >                                   In Sec 3.2, it says:
			> > >                                   "   0x000B  IP Layer2 Transport
			> > >              [RFC3032]"
			> > >
			> > >                                   it should be:
			> > >                                      0x000B  IP Layer2 Transport
			> > >       [draft-ietf-l2tpext-pwe3-ip]
			> > >
			> > >                                   The same problem also exists in web page version 
			> > > http://www.iana.org/assignments/pwe3-parameters
			> > > <http://www.iana.org/assignments/pwe3-parameters> .
			> > >
			> > >                                   I wonder how about the status of this expired 
			> WG draft, will any 
			> > > more work
			> > >                                   continue on this document or just expired as it is?
			> > >                                   I also wonder whether we should define a PW 
			> type for IP payload so 
			> > > that
			> > >                                   everything on PW is possible.
			> > >                                   Any comments?
			> > >
			> > >                                      Thanks,
			> > >                                   Yuanlong Jiang
			> > >
			> > >
			> > >
			> > _______________________________________________
			> > pwe3 mailing list
			> > [e-mail]
			> > https://www.ietf.org/mailman/listinfo/pwe3
			> 
			> 
			> 
			_______________________________________________
			mpls-tp mailing list
			[e-mail]
			https://www.ietf.org/mailman/listinfo/mpls-tp
			
			
			

			--------------------------------------------------------
			ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
			This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
			This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

--- Begin Message ---

Thank you Matthew.

I suspect I'm not getting across my point clearly enough.  So let me
have one more go and see if this helps.

The problems relate to the way MPLS as-is is defined.....and where
MPLS-TP is trying to correct some of these problems.

Here the specific problem is that if LDP (and/or PHP) is used then we
have a merging behaviour of symbols and thus we lose
information...specifically SA information.  Normally in the co-ps mode
this is not an issue as a connection MUST only have a single source, and
thus we do not have to add this (SA) information to the (child) traffic
units as this information is carried by the (parent) connection itself
(and known to the CP/MP).  Of course, if you violate the rules of a
connection then one suffers other problems besides a loss of SA
information, eg significant increase in OAM complexity,
non-deterministic resource management, etc. with the consequence that
the whole network has to both designed and operated to the demands of
the single most stringent customer SLA in force...so the consequences of
merging are more serious than simply a loss of SA information.

When a client of a server layer merging construct is cl-ps, such as IP,
these clients MUST carry SA in each/every traffic unit....because they
don't have a parent connection to convey this information in their layer
network by definition.  So here the loss of information in the (server)
LDP (PHP) construct is not a problem as the client can recover this
information (providing the SAs are unique in the client layer network).

So, when the client is not cl-ps (most of the PW cases) we have no
choice but to add information that recovers from the loss of SA due to
server layer LDP (PHP) merging.....in other words a PW label MUST be a
proxy for SA, and indeed this is what it is.  So providing a PW entity
is not networked (ie only 1-hop) this all works fine/good (at least
under no misconnectivity defects).

However, if we want to create a MH PW entity with flexibility of routing
choice (and don't forget there are issue of MH PW protection-switching
here which highlight the same 'flexibility of routing' requirement) then
we create a co-ps networked entity.  Now providing we don't go and
violate the rules of a connection again for this PW entity (ie only
allow it to have a single source) then its traffic units MUST contain a
label that is used for forwarding.....and this, by definition, MUST be a
proxy for the DA (assuming we are using the traditional label-swapping
approach to forwarding in the co-ps mode).

Even if the SA was provided in such traffic units a SA is NEVER used for
forwarding.....not even in the cl-ps mode.


Further, a solution to the MH PW client case SHOULD take into account
the situation where each of the link connections (ie hops) of the MH PW
are provide by *different* MPLS (or even IP) server layer PSNs....and
each of these server layer partitions could belong to a different
operating party.

For example, consider the following case:

Imagine a 3 hop MH PW, so this has 4 nodes and 3 link connections (can
extend argument to an arbitrary number of hops)

	o-----------o-----------o-----------o
	A		B		C		D

Assume the server link connections A-B and B-C are using LDP and server
layer link connection C-D is using RSVP-TE.  

This means there will be *independent* merging LSPs (of some arbitrary
number of LDP hops) in each of the A-B and B-C links.  Thus when a
client PW traffic unit from A arrives at B, B will not know it came from
A unless we add information to identify A as the source.  Similarly,
when the PW client traffic unit is sent from B to C, C will not know it
came from B unless we add information to identify B as the source (in
*this* server LDP network partition B-C).  We don't have this problem on
the link C-D because a server layer RSVP-TE LSP respects the rules of a
connection and conveys the information of C being the source of *this*
server layer link connection to D.


The labelling could work like this:

Node A imposes 3 labels:  {LDP(A-B) + Demerge(A-B)} + MHPW(A-B).  

The last label (ie MHPW(A-B)) is a normal DA forwarding label for the
MHPW A-B-C-D and it will get swapped at nodes B and C.  The former 2
labels MUST be a pair and both get removed at node B....the LDP(A-B)
label is normal forwarding across the 1st LDP network server partition
whilst the Demerge(A-B) label removes the merging in this partition, ie
to identify the MHPW as from A.

At node B the LDP(A-B) + Demerge(A-B) labels are both removed, MHPW(A-B)
label is swapped to a MHPW(B-C) label and a new pair of LDP(B-C) +
Demerge(B-C) labels imposed to get across the 2nd LDP server layer
partition.  

At node C the LDP(B-C) + Demerge(B-C) labels get removed, MPHW(B-C)
label is swapped to MHPW(C-D) label and a *single* server layer
RSVP-TE(C-D) label added.

There is no need for an end-end SA label for the MH PW *providing* there
is no merging in the PW layer.


Now we should also note at this point that there can be no notion of a
"common (ie same instance of) CP" (usually meant to imply a routing
component, but this applies to all DP/CP/MP components) straddling the
MH PW and each of the (independent) server layer MPLS networks.  Nothing
new here, the folks working on GMPLS have had to come to terms with this
issue over the years.....and as one of my colleagues said to me recently
(in the context of G.800, and directly applicable to this issue) "you
can only configure what already exists"....quite.....and putting this
slightly differently for this specific case, the routing process for the
MH PW MUST assume a different process *has already* created each of its
link connections...as these are end-end network connections in each of
the server MPLS partitions.


Hope that helps and is now clear.

regards, Neil 

> -----Original Message-----
> From: BOCCI Matthew [mailto:[e-mail]] 
> Sent: 28 November 2008 15:49
> To: Harrison,N,Neil,CXM R; [e-mail]
> Cc: Niven-jenkins,B,Ben,DMF R; [e-mail]
> Subject: RE: [PWE3] draft-ietf-pwe3-ms-pw-arch-05.txt
> 
> 
>  Neil,
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: 27 November 2008 19:09
> > To: [e-mail]; BOCCI Matthew
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: [PWE3] draft-ietf-pwe3-ms-pw-arch-05.txt
> > 
> > This is now raising questions about the semantic of the PW 
> label and 
> > the relationship of the MPLS/IP server layer CP/MP and PW CP/MP.
> > 
> > In vanilla LDP MPLS where we have mp2p merging LSPs constructs (PHP 
> > also creates merging but only on the last
> > hop) one loses information of the source.  Not a problem if 
> the client 
> > is IP as each client traffic unit carries a SA that compensates for 
> > the loss of SA information due to the lower level LDP/PHP merging.  
> > However, when one has PW clients the PW label must act as a 
> proxy for 
> > a SA of the PW.
> > For single-hop PWs there is no problem as these are not networked 
> > entities.  But when we have multi-hop PWs we do have a networked 
> > entity...and as Matthew notes below in response to Ben:
> > 
> > BNJ=> > to me that where the PSN domains are of the same 
> type then a 
> > simple
> > > > label swap ala
> > > > RFC3031 can always be performed but this is not true if the PW 
> > > > demultiplexer is an L2TP session ID or UDP port as allowed
> > > by RFC3985.
> > > 
> > MB=> Agreed. What we were trying to say was that a swap of the PW
> > > demultiplexer is performed, which in the case of MPLS is a
> > label swap.
> > 
> > The first problem here is that PW labels were originally 
> never meant 
> > to change as they were acting as a SA proxy across a single 
> hop (this 
> > was when PWs were more like an adaptation function and thus not a 
> > networked entity).  But with multi-hop PWs one really wants 
> the label 
> > to act as a DA proxy for forwarding.....and traditionally such DA 
> > proxy labels get swapped hop by hop by co-ps mode networks.
> > 
> > So what semantics does a multi-hop PW label now convey?
> 
> The semantic is the same as in the single segment case. The 
> label is the context representing th FEC for the PW, which is 
> the destination AC in both cases.
> 
> In common with other co-ps networks, we would rely on OAM to 
> detect and diagnose defects, but that is out of scope of the 
> architecture draft.
> There is some ongoing work on OAM for MS-PWs in 
> draft-ietf-pwe3-segmented-pw to address MS-PW OAM, and the 
> MPLS-TP OAM work will be applicable to MS-PWs as well.  
> 
> 
> > 
> > A further issue arises wrt the relationship of the CP/MP of the 
> > multi-hop PW entity (esp the route calculations of such) when it is 
> > served by 2 or more MPLS/IP server layer partitions that may be 
> > owned/operated by different parties.
> 
> The MS-PW routing domain is distinct from the PSN routing 
> domain (except of course that PSN tunnels and PW segments 
> terminate on the same nodes).
> However, I do agree with you that it becomes more complex if 
> you have either MPLS and IP PSN partitions, but the details 
> of how to implement this are really outside the scope of this draft.
> 
> Thanks
> 
> Matthew
> 
> 
> > 
> > regards, Neil
> >  
> > 
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > On Behalf
> > > Of Reshad Rahman (rrahman)
> > > Sent: 27 November 2008 13:37
> > > To: BOCCI Matthew
> > > Cc: Niven-jenkins,B,Ben,DMF R; pwe3
> > > Subject: Re: [PWE3] draft-ietf-pwe3-ms-pw-arch-05.txt
> > > 
> > > Hi,
> > > 
> > > In the example below from section 1.1, PE2 is acting both as S-PE 
> > > (with
> > > PE1 and PE4 acting as T-PEs) and also as T-PE (for "local" 
> > > traffic), but I assume that for a given PW a node only 
> has one role?
> > > 
> > > Regards,
> > > Reshad.
> > > 
> > >    Consider a single PWE3 domain, such as that shown in Figure 1. 
> > > There
> > >    are 4 PEs, and PWE3 must be provided from any PE to any
> > other PE.  
> > >    With SS-PWs, PWE3 would be achieved by establishing a
> > full mesh of
> > >    PSN tunnels between the PEs, requiring a full mesh of
> > LDP signaling
> > >    adjacencies between the PEs. Pseudowires would therefore be 
> > >    established between any PE and any other PE via a 
> single, direct 
> > > PSN
> > >    tunnel that is switched only by intermediate P-routers
> > (not shown
> > > in
> > >    the figure). A PE must terminate all the pseudowires that are 
> > > carried
> > > 
> > >    on the PSN tunnels that terminate on that PE according to the 
> > >    architecture of RFC 3985. This solution is adequate for small 
> > > numbers
> > > 
> > >    of PEs, but the number of PEs, PSN tunnels and signaling 
> > > adjacencies
> > >    will grow in proportion to the square of the number of PEs.  
> > > 
> > >    A more efficient solution for large numbers of PEs would be to 
> > >    support a partial mesh of PSN tunnels between the PEs,
> > as shown in
> > >    Figure 1. For example, consider a PWE3 service whose
> > endpoints are
> > >    PE1 and PE4. Pseudowires for this can take the path
> > PE1->PE2->PE4,
> > >    and rather than terminating at PE2, be switched between
> > ingress and
> > >    egress PSN tunnels on that PE. This requires a 
> capability in PE2 
> > > that
> > > 
> > >    can concatenate PW segments PE1-PE2 to PW segments PE2-PE4. The
> > > end-
> > >    to-end PW is known as a multi-segment PW. 
> > > 
> > >                                 ,,..--..,,_ 
> > >                             .-``           `'., 
> > >                     +-----+`                   '+-----+ 
> > >                     | PE1 |---------------------| PE2 | 
> > >                     |     |---------------------|     | 
> > >                     +-----+      PSN Tunnel     +-----+ 
> > >                     / ||                          || \ 
> > >                    /  ||                          ||  \ 
> > >                   |   ||                          ||   | 
> > >                   |   ||         PSN              ||   | 
> > >                   |   ||                          ||   | 
> > >                    \  ||                          ||  / 
> > >                     \ ||                          || / 
> > >                      \||                          ||/ 
> > >                     +-----+                     +-----+ 
> > >                     | PE3 |---------------------| PE4 | 
> > >                     |     |---------------------|     | 
> > >                     +-----+`'.,_           ,.'` +-----+ 
> > >                                 `'''---''`` 
> > >          Figure 1 Single PSN PWE3 with Partial Mesh of PSN Tunnels
> > >  
> > > 
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > On Behalf
> > > Of BOCCI Matthew
> > > Sent: Monday, November 24, 2008 10:56 AM
> > > To: Ben Niven-Jenkins; pwe3
> > > Subject: Re: [PWE3] draft-ietf-pwe3-ms-pw-arch-05.txt
> > > 
> > > Ben,
> > > 
> > > Many thanks for your comments. Please see below.
> > > 
> > > Regards
> > > 
> > > Matthew
> > >  
> > > 
> > > > Colleagues,
> > > > 
> > > > While I read draft-ietf-pwe3-ms-pw-arch-05.txt I came up
> > > with a couple
> > > 
> > > > of comments/qeustions - see below.  Overall I think this
> > is a good
> > > > document and should be progressed.
> > > > 
> > > > Ben
> > > > 
> > > > 
> > > > Section 3.
> > > > " That is, 
> > > >    although a PW segment will follow the path of the PSN tunnel 
> > > > between
> > > >    S-PEs, the MS-PW is independent of the PSN tunnel routing,
> > > >    operations, signaling and maintenance."
> > > > 
> > > > What about T-PEs?
> > > 
> > > Agreed. That should read "...tunnel between S-PEs and 
> between S-PEs 
> > > and T-PEs, the MS-PW is independent..."
> > > 
> > > > 
> > > > Section 3.1
> > > > I am confused by your use of the term "layer" in the following:
> > > > 
> > > > "   PWE3 defines the Encapsulation Layer, i.e. the method 
> > > of carrying
> > > >    various payload types, and the interface to the PW
> > Demultiplexer
> > > >    Layer. It is expected that other layers will provide the
> > > following:
> > > > 
> > > >       . PSN tunnel setup, maintenance and routing
> > > > 
> > > >       . T-PE discovery "
> > > > 
> > > > To me encapsulation, demultiplexing and T-PE discovery are not 
> > > > separate layers but separate functions but if I'm the
> > only one that
> > > > thinks this then I'll concede to the use of layer in 
> this context.
> > > 
> > > These are functions, but they are provided by layers
> > outside of PWE3,
> > > assuming that e.g. the PSN is treated as a separate layer 
> from the 
> > > MS-PW. The last sentence above the bullets should be reworded to 
> > > explain this better.
> > > 
> > > 
> > > > 
> > > > Section 6
> > > > " Where the ingress and
> > > >    egress PSN domains of the S-PE are of the same type
> > e.g. they are
> > > >    both MPLS PSNs, a simple label swap operation is 
> performed, as
> > > >    described in RFC 3031 [5] Section 3.13."
> > > > 
> > > > Is the use of simple label swap only an example here? The
> > > text implies
> > > 
> > > > to me that where the PSN domains are of the same type
> > then a simple
> > > > label swap ala
> > > > RFC3031 can always be performed but this is not true if the PW 
> > > > demultiplexer is an L2TP session ID or UDP port as allowed
> > > by RFC3985.
> > > 
> > > Agreed. What we were trying to say was that a swap of the PW 
> > > demultiplexer is performed, which in the case of MPLS is a
> > label swap.
> > > 
> > > > 
> > > > Section 10
> > > > " each S-PE is a new point at which defects may occur
> > > >    along the path of the PW. In order to troubleshoot MS-PWs, 
> > > > management
> > > >    and monitoring should be able to operate on a subset of the 
> > > > segments
> > > >    of an MS-PW, as well as edge-to-edge. That is, connectivity
> > > >    verification mechanisms should be able to troubleshoot and
> > > >    differentiate the connectivity between T-PEs and 
> intermediate 
> > > > S-PEs,
> > > >    as well as T-PE to T-PE.  "
> > > > 
> > > > Have you consciously omitted S-PE to S-PE connectivity
> > verification?
> > > 
> > > No. We certainly need to include that case. I'll add this
> > to the list
> > > of mechanisms.
> > > 
> > > 
> > > > 
> > > > _______________________________________________
> > > > pwe3 mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/pwe3
> > > > 
> > > _______________________________________________
> > > pwe3 mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/pwe3
> > > _______________________________________________
> > > pwe3 mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/pwe3
> > > 
> > 
> 

--- End Message ---