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

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 17 Nov 2008 09:18:19 -0600

I have reviewed draft-ietf-pwe3-ms-pw-arch-05.txt and believe that it
is ready to be progressed.

Thanks,
Andy
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 24 Nov 2008 15:02:41 +0000

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?

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.

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.

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?

---

From: "BOCCI Matthew" <[email-masked]>
Date: Mon, 24 Nov 2008 16:55:49 +0100

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, 

Agreed. That should read "...tunnel between S-PEs and between S-PEs and
T-PEs, the MS-PW is independent..."

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

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

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

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 27 Nov 2008 08:37:28 -0500

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,

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, 

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

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

---

From: <[email-masked]>
Date: Thu, 27 Nov 2008 19:08:32 -0000

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 
> > demultiplexer is an L2TP session ID or UDP port as allowed 
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?

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.

regards, Neil

> 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
> 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.
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of BOCCI Matthew
> Agreed. That should read "...tunnel between S-PEs and between 
> S-PEs and T-PEs, the MS-PW is independent..."
> 
> > 
> > Section 3.1
> 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
> text implies
> No. We certainly need to include that case. I'll add this to 
> the list of mechanisms.
> 
> 
> >

---

From: "BOCCI Matthew" <[email-masked]>
Date: Fri, 28 Nov 2008 16:49:00 +0100

Neil,

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

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

> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Reshad Rahman (rrahman)
> >    tunnel that is switched only by intermediate P-routers 
> (not shown 
> > in
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of BOCCI Matthew
> > Agreed. That should read "...tunnel between S-PEs and between S-PEs 
> > and T-PEs, the MS-PW is independent..."
> > 
> > > 
> > > Section 3.1
> > MS-PW. The last sentence above the bullets should be reworded to 
> > explain this better.
> > 
> > 
> > > 
> > > Section 6
> > > " Where the ingress and
> > No. We certainly need to include that case. I'll add this 
> to the list 
> > of mechanisms.
> > 
> > 
> > >

---

From: <[email-masked]>
Date: Sat, 29 Nov 2008 09:43:20 -0000

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 

> 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]
> 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
> 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:
> > 
> 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.
> > 
> 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.
> draft-ietf-pwe3-segmented-pw to address MS-PW OAM, and the 
> MPLS-TP OAM work will be applicable to MS-PWs as well.  
> 
> 
> > 
> 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
> >  
> > 
> > >    established between any PE and any other PE via a 
> single, direct 
> > > PSN
> > >    egress PSN tunnels on that PE. This requires a 
> capability in PE2 
> > > that
> > > 
> > > >    differentiate the connectivity between T-PEs and 
> intermediate 
> > > > S-PEs,