Subject: Re: [PWE3] draft-ietf-pwe3-ms-pw-arch-05.txt

From: "BOCCI Matthew" <[email-masked]>
Date: Mon, 8 Dec 2008 11:32:44 +0100

Neil, 

> 
> 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.

I agree, but there *is* no merging at the PW layer at S-PEs. If you look
at the design in draft-ietf-pwe3-dynamic-ms-pw, there is only one
upstream S-PE to which a next hop S-PE or T-PE will allocate a label to
for a given FEC, and PHP is not applied to the PW label. 

This issue is dealt with in Section 5.1.1 of this architecture draft,
where we only allow a mapping of one ingress PW to one egress PW
(although I agree this will change for P2MP PWs). Please let me know if
you think this needs further clarificatio in the arch draft.

> 
> 
> 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.

I assume you are refering to the procedures in
draft-ietf-pwe3-dynamic-ms-pw: 

      -ii. Check that a PSN tunnel exists to the next hop S-PE or T-PE.
            If no tunnel exists to the next hop S-PE or T-PE the S-PE
            MAY attempt to setup a PSN tunnel.

Please can you clarify exactly your comment on the architecture draft
with respect to this.

Regards

Matthew

> 
> 
> Hope that helps and is now clear.
> 
> regards, Neil 
> 
> > -----Original Message-----
> > From: BOCCI Matthew [mailto:[email-masked]]
> > Sent: 28 November 2008 15:49
> > To: Harrison,N,Neil,CXM R; [email-masked]
> > Cc: Niven-jenkins,B,Ben,DMF R; [email-masked]
> > Subject: RE: [PWE3] draft-ietf-pwe3-ms-pw-arch-05.txt
> > 
> > 
> >  Neil,
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: 27 November 2008 19:09
> > > To: [email-masked]; BOCCI Matthew
> > > Cc: [email-masked]; [email-masked]
> > > 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: [email-masked] [mailto:[email-masked]]
> > > 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: [email-masked] [mailto:[email-masked]]
> > > 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
> > > > > [email-masked]
> > > > > https://www.ietf.org/mailman/listinfo/pwe3
> > > > > 
> > > > _______________________________________________
> > > > pwe3 mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/pwe3
> > > > _______________________________________________
> > > > pwe3 mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/pwe3
> > > > 
> > > 
> > 
> 
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: <[email-masked]>
Date: Wed, 10 Dec 2008 12:17:12 -0000

Sorry for late response Matthew (middle of moving house)...please see
in-line:

> Sent: 08 December 2008 10:33
> > 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 
> 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
> 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).
> > 
> 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
> > IP) server layer PSNs....and each of these server layer partitions 
> > could belong to a different operating party.
> > 
> connections (can 
> > extend argument to an arbitrary number of hops)
> > 
> > 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.
> > 
> > 
> I agree, but there *is* no merging at the PW layer at S-PEs. 
NH=> Yes I know...all I was saying here is don't repeat the (merging)
mistake of LDP and PHP again in a higher layer network.....here the PW
layer network.
Aside=> This may not be a very popular thing to point out, but if one
deprecates LDP/PHP (and ECMP), as one must in MPLS-TP, then most of the
rationale for creating the PW layer network in the first place has
actually gone...espceially the 1st nibble hack necessary to work with
ECMP.

> If you look
NH=> But did you understand the key point I was making earlier, ie the
*current* semantic of a PW label is SA....and if any *lower* level
LDP/PHP is used then you MUST retain this SA semantic for the PW label
else you cannot recover the loss of information due to lower layer
merging.  However, once PWs are MH we now need a PW label for fowarding
that has a DA proxy semantic.  So there is a potential conflict of
requirements here.

Of course if one does not use LDP/PHP in MPLS and uses proper
connections instead (let's call it MPLS-TP based on RSVP-TE, ideally the
OOB GMPLS version) then there is no need for the PW label to hold a SA
semantic as there is no loss of source information due to lower layer
merging....and the connection/LSP itself carries the SA semantic now as
a proper connection MUST only have a single source. {And as I noted in
the aside above, the rational that created PWs in the 1st place has now
actually gone.}

If any of the above is not clear then a read of G.800 (unified modelling
of networks) might help as it explains how the 3 modes arise and why a
connection must only have a single source.

> you think this needs further clarificatio in the arch draft.
NH=> The only thing that needs understanding/clarification is what I
have tried to explain above.  It is rather important that folks grasp
what I am saying here....and I'm not sure this is really the general
case yet.

> Please can you clarify exactly your comment on the architecture draft
NH=> Well, there is a strong reluctance in my experience (possibly due
to what happened with ATM) to accept that one cannot have a single
instance of routing running across a stack of layer networks.  However,
this is a fact and the sooner it is accepted the better, ie so we can
stop making so many arch mistakes.  Folks working on GMPLS (esp with
co-cs mode technologies like SDH and OTN) have had to come to terms with
this.  MPLS has avoided this confrontation to date and tried to keep a
special relationship with the (cl-ps) IP layer network.  However, this
creates all sorts of problems, not least of which is the confusion
between IP as *client* DP traffic PDUs and IP as (MPLS *server*) CP/MP
PDUs.....in unified-modelling/func-arch language I would classify this
as a lack of consistent characteristic information (CI) (in a layer
network the CI MUST be consistent, and in MPLS as-is it is not).

The fact MPLS-TP is emerging is one very clear indication of this
underlying problem, but when PWs go MH then these also expose this
problem directly.....that is, because we have to treat the MH PWs as
connections in their own layer network they MUST have all the functional
components (routing is but one of these, eg own addressing, own
signalling, own OAM, etc) one need to operate such a layer network...and
these cannot be associated with a serving MPLS layer network.....esp if
each link connection of the MH PW is served by a **different** party's
MPLS layer network (this was the exmaple I tried to show in my initial
mail).

So as I said, the sooner we all accept that the notion of a common
instance of CP across all layer networks is not viable the better.  And
if folks want to press on with MH PWs then this is indeed the case that
must be applied, ie MH PWs will require their own CP.  Of course, as I
also noted earlier, once LDP/PHP/ECMP go (as they must for MPLS-TP) then
the initial rationale for PWs has also gone....just a fact, even if not
the sort of thing one might want to hear.

regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 10 Dec 2008 23:01:53 +0000

Neil,

> that has a DA proxy semantic.  So there is a potential conflict of

Assuming there is no merging at the PW layer (which I believe to be true)
then can the PW label field not contain source & destination semantics at
the same time.  Surely the real requirement is to be able to identify the
connection the PW represents and from that can be derived the source of the
PW/connection? Is this not analogous to ATM & FR which are both co-ps and
neither contains a SA field in their headers?

The one disadvantage of not having an explicit SA field is that you can't
detect mismerges using just the data plane header but have to explicitly use
OAM to do so.

Ben

---

From: <[email-masked]>
Date: Thu, 11 Dec 2008 13:10:59 -0000

Thanks Ben...see below: 

You wrote 10 December 2008 23:02 (and snipped)
> >> upstream S-PE to which a next hop S-PE or T-PE will 
> allocate a label 
> >> to for a given FEC, and PHP is not applied to the PW label.
> > merging.  However, once PWs are MH we now need a PW label for 
> > fowarding that has a DA proxy semantic.  So there is a potential 
> > conflict of requirements here.
> 
NH=> Please try and forget PW merging...I know this does NOT currently
happen and all I was saying to Matthew previously was 'let's not make
the merging mistake again *above* MPLS'...you know the problems this
creates, and we must also ensure this does not happen in MPLS-TP either.

>  then can the PW label field not contain source & 
> destination semantics at the same time.
NH=> No.  Have a read of my internal BT paper on 'how many networks do
we need?' (sorry non-BT folks, this is not yet publicly published) and
G.800...these explain in some detail how BOTH labelling and resource
assignment work (from going right back to the basics of Shannon
Information Theory) and how this generates the 3 modes we all are
familiar with.

No network mode forwards on a SA semantic....but only the cl-ps mode
demands that a SA be included in each/every traffic unit.  You do not
have to include a SA in the (child) traffic units of both co-cs and
co-ps mode networks IFF you respect the (information theoretic)
requirements of a (parent) connection....which is a constraining entity
(wrt routing choice) under defect-free conditions.....the (parent)
connection holds the SA semantic *in the CP (or MP)*.

However, there are rather important operational advantages from
including a SA in co traffic units under misconnectivity defect
conditions (ie the connection is now NOT performing correctly as a
constraining entity), and you get these benefits *without* running any
CV OAM at all, as such connections are intrinsically protected from
misdelivering traffic to the wrong DA....this is what we find in PBB-TE
for example since it based on a cl-ps Ethernet traffic unit and these
contain a SA.

BTW - An important corollary of what I noted above is that
request/response OAM CANNOT be trusted in co mode networks under
misconnectivity defects....there will not (prob->1) be a return
direction/connection for leaking traffic.  This is one reason why cl-ps
mode OAM is NOT the same as co mode OAM

If you are still having problems understanding this please speak to Andy
Reid who wrote most of G.800....he can give you a very detailed
explanation of why what I am saying is correct.

> ie MUST only have a single source  Surely the real 
> requirement is to be able to identify the connection the PW 
> represents and from that can be derived the source of the 
> PW/connection? Is this not analogous to ATM & FR which are 
> both co-ps and neither contains a SA field in their headers?
NH=> Yes!!  But my initial point was that if you violate the rules of a
connection in a **server** layer (as LDP/PHP does in MPLS) *and* the
**client** is NOT cl-ps (ie does not contain unique SA) you MUST provide
a means to revover the lost information **between** the client and the
server...and today this is what a PW does....the PW label has nothing to
do with the *forwarding* requirements on the PW entity, it is all about
recovering lost infortmation in the **lower** LDP network.  Now, this
works OK providing the PW entity is NOT networked (ie 1-hop), but if you
do want to network the PW entity (ie multi-hop) then the labelling you
need in the PW traffic units MUST be a proxy for a PW *layer network*
DA.

Please also go back to my original example where I showed 3 concatenated
independent MPLS *server* layer networks....of LDP + LDP + RSVP-TE...for
*each* link connection of a 3 hop client PW.  One of the really
important points I was trying to bring out here is that the recovery of
SA information from lower LDP merging MUST be done independently on
*each* of the LDP served PW hops....and there is no need for this at all
on the last RSVP-TE served PW hop.  And to be really clear here....You
cannot recover the loss of SA information on an end-end basis at the 3
hop PW level, this MUST be done independenly on each PW hop...so the PW
label CANNOT contain a SA semantic here...and indeed you now want it to
ONLY conatain a DA semantic.

The other key point this example showed is that there can be NO COMMON
CP instance between each of the 3 serving MPLS networks and the client
PW network.  This too is a critical point that so far seems not to be
generally well recognised.

> 
> The one disadvantage of not having an explicit SA field is 
> that you can't detect mismerges using just the data plane 
> header but have to explicitly use OAM to do so.
NH=> Agreed.  In fact this is the ONLY reason to include the SA in the
(child) traffic units of a *co* mode layer network (parent)
connection....but it is rather an important operational advanatge...and
something we an an industry ought to pick-up on, and one of the key
spin-off insights from the G.800 unified modelling work.  And as you
know, this was something we first brought to folks attention in PBB-TE.

regards, Neil