Subject: Re: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was: RE: PHBs and "ordered aggregates"]

From: Maarten Vissers <[email-masked]>
Date: Tue, 02 Mar 2010 16:29:56 +0100

Sasha,

Your understanding of an Ethernet VLAN and my understanding are different. 
My focus is on the data plane construct, not on the particular control or
management plane method to set up the VLAN. I have the idea that you
associated Ethernet VLAN with both the data plane construct *and*  the
802.1Q control plane method. 
My view is strongly influenced by the functional model for Ethernet layer
networks created in ITU-T and documented in G.8010 and the other ethernet
recommendations (e.g. G.8021, G.8031, Y.1731, etc).

For me, an Ethernet VLAN represents an 'Ethernet transport service path'
through which "ETH Characteristic Information (ETH_CI)" is transferred
between the n (n>=2) ports at the edge of that 'Ethernet transport service
path'. 

An 'Ethernet transport service path' can be set up by NMS or GMPLS or other
means (e.g. in some domain xSTP/xVRP); how this 'ETH transport service path'
is set up does not impact the definition of the 'ETH transport service path'
(i.e. Ethernet VLAN) in my view.  

An 'Ethernet transport service path' can be subnetwork connection protected,
or can be dual node interconnect protected. Such protection does not impact
the definition of the 'ETH transport service path' in my view.

An 'Ethernet transport service path' can include more p2p ETH link
connection then necessary to reduce latency; if this is the case, then
additional loop prevention techniques are to be applied (i.e. split horizon
port groups). Such split horizon does not impact the definition of the 'ETH
transport service path'; it only amends the most basic filtering rule in a
MAC relay function for such 'Ethernet transport service path' (VLAN). 
I agree with you that this amended filtering rule is not included in the
802.1Q filtering rule set. But this is something we can ask to add to 802.1Q
as there are now many nodes in the network that support this amended
filtering rule; i.e. all the VPLS capable nodes support it.

In all those cases there are just different designs of the same 'ETH
transport service path', through which ETH_CI is traversing. In all those
cases, Ethernet OAM (Y.1731/802.1ag) can be and is deployed for monitoring
purposes.

An 'Ethernet transport service path' signal can be multiplexed with other
service path signals into a server layer transport path. When this is done,
each 'Etherent transport service path' signal requires a unique identifiers
within the server layer transport path. Such identifier can be one of the
802.1Q defined identifiers (CVID,SVIC,ISID), or can be a server layer based
identifier (PW Label, GFP-F linear extension header, ..). The same 'Ethernet
transport service path' signal can be equipped with one of these identifier
types when carired in one server layer's  transport path, and another of
these identifier types when carried in another server layer transport path.

Example: an 'Ethernet transport service path' signal may have the following
identifiers on successive links:
CVID - SVID - PW label - ISID - PW label - SVID - etc. This capability is
used in operator networks to carry 'ETH transport service path' signals
through domains with different transport path layer technologies; e.g.
Ethernet domain, PBB-TE domain, MPLS domain, SDH domain, OTN domain.

'Ethernet transport service path' signals require that its demultiplexer
header is able to carry the following information elements:
- vlan_idnetifier
- priority
- drop_eligible.
The multi-root E-Tree service may add one more information element (udner
discussion at the moment), i.e.
- leaf indicator.

The 'ETH transport service path signal' does not care how this information
is encoded. 
This allows for great flexibility in network designs. 
This is also why MPLS/VPLS could start initially in the core, while the
'Ethernet transport service path' continued in metro and access domains,
where it was carried by non-MPLS technologies (e.g. Ethernet VLAN, PBB-TE
ESP, GPON) and identified by non-PW labels.

> Rx PW label identifies specific VPLS peer within the VPLS instance for
> MAC learning purposes.
> As a consequence, a VSI with N peers requires N different Rx PW labels.

In a 'VPLS' - i.e. part of an 'Ethernet transport service path' which
deploys a full mesh of p2p ETH link connections between the N+1 Ethernet MAC
relay functions supporting this service path - each of the N+1 MAC relay
functions is connected via N p2p Ethernet link connections with the other N
MAC relay functions. If those N p2p Ethernet link connections are all
carried by a different server layer transport path then it is possible to
use the same PW label value on all those server layer transport paths, like
it is possible to use the same VID on each server layer transport path when
the server layer is ethernet VLAN. Each server layer transport path endpoint
forms a (Virtual) Bridge Port on the bridge and this (virtual) bridge port
is associated with a unique bridge port number. The MAC relay function
expects to see now the same vlan_identifier value on all those (virtual)
bridge ports identifying the frames that belong to one VLAN ('Ethernet
transport service path'). If different values are present on the links, then
vlan identifier translation is used to presetn the same vlan_identifier
value to the MAC relay function.

It is possible to do the identification in a different manner; i.e. ignore
the (virtual) bridge port identification and do all the necessary
identification with the 'Ethernet transport service path' (VLAN/VPLS)
identifier; e.g. use unique PW label values to both identify the 'Ethernet
transport service path' instance and the (virtual) bridge port over which
the frame has to be or is carried. Same information is present, just with a
different encoding.

The server layer transport paths that can be used in the above example are
e.g.: LSP, ESP, ODUk, server VLAN, VC-n. It is possible to mix those server
layer transport path technologies in one 'VPLS'; e.g. have one node sending
the 'Ethernet transport service path' signal to e.g. 2 virtual bridge ports
supported by two MPLS LSPs (using PW labels), 2 other virtual bridge ports
support by two ODUks (using VIDs), 1 other virtual bridge port supported by
an ESP (using ISID) and 3 other virtual bridge ports supported by a server
layer p2p VLAN (using VIDs). The forwarding of the ETH_CI in such 'VPLS'
will still function as normal.

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: maandag 1 maart 2010 6:55
To: Maarten Vissers
Cc: [email-masked]; 'Igor Bryskin'; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Maarten (and all),
I have added the L2VPN WG list since two of your comments deal with VPLS.

I disagree with two of your comments dealing with VPLS:

	VPLS technology is Ethernet VLAN technology

IMHO this incorrect:
Ethernet/VLAN (as technology) does not use "split horizon", and VPLS does
not need any form of STP for loop elimination across a full mesh of PWs.

	PW label identifies the VPLS/VLAN instance

IMHO this is also incorrect/inaccurate:
Rx PW label identifies specific VPLS peer within the VPLS instance for MAC
learning purposes.
As a consequence, a VSI with N peers requires N different Rx PW labels.

Modeling of VPLS (that includes 802.1-compliant bridge modules and VPLS
Forwarders) is discussed in some detail in
http://www.watersprings.org/pub/id/draft-ietf-l2vpn-vpls-bridge-interop-04.t
xt

My 2c,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: Monday, March 01, 2010 1:20 AM
To: 'Igor Bryskin'
Cc: [email-masked]
Subject: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was: RE:
PHBs and "ordered aggregates"]

Igor,

If I would put MPLS-SP and MPLS-TP in a layer stack figure, I get the
following:

----------------------------------------------
|  MPLS-SP (RFC5654 transport service layer) |
|  includes LDP-PWs, BGP-PWs, Service-LSPs   |
|  VPLS, VPNs, etc                           |
----------------------------------------------
|  MPLS-TP (RFC5654 transport path layer)    |
|  includes edge-to-edge-LSPs, ..            |
----------------------------------------------
|  Transmission Media layer (includes        |
|  section and physical media layers)        |
----------------------------------------------

MPLS-SP can then be read as 'MPLS Service Path' layer, which supports
'service paths'.
MPLS-TP can then be read as 'MPLS Transport Path' layer, which supports
'transport paths'.

	Note that the VPLS technology is Ethernet VLAN technology and that
the
	PW label identifies the VPLS/VLAN instance.

PW, Service-LSP and VPLS instances (the 'service path signals') are all
carried by a 'MPLS transport path' (i.e. edge-to-edge LSP) as illustrated in
the figure below.

            |<---- Pseudowire, Service LSP and VPLS/VLAN ---->|
            |      encapsulated packet "service paths"        |
            |                                                 |
            |                                                 |
            |   |<---edge-to-edge LSP1--->|    edge-to-edge   |
        AC  |   |    "transport path"     |    |<--LSP2-->|   |  AC
         |  V   V                         V    V          V   V  |
         | +----+              +-----+    +----+          +----+ |
   +---+ | |TPE1|===============\ P /=====|SPE1|==========|TPE2| | +---+
   |   |---|......PW1-Seg1.... |     | ......X...PW1-Seg2......|---|   |
   |CE | | |    |              |     |    |    |          |    | | |CE |
   |11 |---|......PW2-Seg1.... |     | ......X...PW2-Seg2......|---|21 |
   +---+ | |    |              |     |    |    |          |    | | +---+
   |   |---|.....SLSP1-Seg1... | \ / | ......X..SLSP1-Seg2.....|---|   |
   |CE | | |    |              |  X  |    |    |          |    | | |CE |
   |12 |---|.....SLSP2-Seg1... | / \ | ......X..SLSP2-Seg2.....|---|22 |
   +---+ | |    |              |     |    |    |          |    | | +---+
   |   |---|......VPLS1-Seg1.. |     | ......X..VPLS1-Seg2.....|---|   |
   |CE | | |    |              |     |    |    |          |    | | |CE |
   |13 |---|......VPLS2-Seg1.. |     | ......X..VPLS2-Seg2.....|---|23 |
   +---+ | |    |===============/   \=====|    |==========|    | | +---+
           +----+     ^        +-----+    +----+     ^    +----+   
                      |                              |             
                   TE LSP                         TE LSP           

             Figure - MPLS-TP edge-to-edge LSP transporting PW, Service-LSP
               and VPLS/VLAN 'service paths' (= RFC5654 transport service
		               layer transport path) signals

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Igor Bryskin
Sent: vrijdag 26 februari 2010 15:59
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] PHBs and "ordered aggregates"

Curtis,

I believe that one of our serious problems is that we keep calling MPLS-TP
MPLS transport profile, while in fact this is IMO nothing but MPLS traffic
engineered (controlled by GMPLS or NMS) transport layer providing services
to various clients and one of them is MPLS service layer (some people call
it MPLS-SP) that includes LDP-PWs, BGP-PWs, VPLS, VPNs, etc.). The two
layers (MPLS-TP and MPLS-SP) share the same data plane, but from the CP,
say, point of view they have quite literally nothing in common.

Cheers,
Ogor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Curtis Villamizar
Sent: Friday, February 26, 2010 12:14 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] PHBs and "ordered aggregates"

In message
<[email-masked]
t>
[email-masked] writes:
>  
> Hi Curtis....wow, long time no hear.  I know what you are saying here 
> but this is not what a transport network is supposed to be doing.  You 
> cannot apply what you say to any co-cs mode layer network controlled 
> by GMPLS...just a fact of the physics.
>  
> If we do not provide true transparency in MPLS-TP then that's OK, but 
> it also means that MPLS-TP should really stop claiming it is a 
> transport network.  In fact, I would argue that the mere fact MS PWs 
> still appear in MPLS-TP alone is a fairly obvious indication that it 
> has failed in its transport network aspirations.
>  
> This sort of technical accuracy seems not to matter any longer from 
> what I am observing....so be it, but there are also practical 
> implications of not grokking this anyway, I was merely pointing some 
> of these.  Caveat emptor now.
>  
> regards, Neil

Neil.

MPLS-TP is a "profile".  A given provider can in effect enable or disable
aspects of the profile if they prefer to do so for business reasons rather
than for sake of some notion of transport purity.

But lets not argue religion.

The specs have a lot of SHOULD so that providers still have choices.

Curtis

> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: 25 February 2010 03:53
> > To: Harrison,N,Neil,DKQ7 R
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [mpls-tp] PHBs and "ordered aggregates" 
> > 
> > 
> > Hi Neil.
> > 
> > AF service has more than one PHB per OA.  That is on purpose. 
> >  The rule is one PSC per OA, not one PHB.  The color marking affect 
> > only the drop preference.
> > 
> > All other defined diffserv services have one PHB per OA.
> > 
> > If you don't like AF, don't use it.
> > 
> > Re: "the server layer resources must not be overbooked".  In the 
> > event of a fault, a disconnected IP network is worse than a mildly 
> > congested one, particularly if diffserv is used and the only thing 
> > slowed down is the BE service.  To do that, you need to allow 
> > overbooking.  Hint:
> > use MPLS holding-pri with the Russian Dolls model and only overbook 
> > the priority containing BE.
> > 
> > MPLS doesn't need any changes to allow this.
> > 
> > Curtis
> > 
> > 
> > In message
> > <[email-masked]
> > .systemhost.net>
> > [email-masked] writes:
> > >  
> > > Hi Dave,
> > >  
> > > The deeper (G.800) architectural point you are getting at
> > here is one
> > > of transparency...which is THE key service that a server layer
> > > (transport) network needs to deliver to its clients.  What
> > this means
> > > practically is
> > > this:
> > > -	the server network must be based on single source connection
> > > constructs
> > > -	the server layer resources must not be overbooked 
> > > -	the server network must not try and impart any meaning to client
> > > layer symbols and for sure not change them.....in essence no 
> > > snooping/DPI
> > > -	a (parent) connection must not re-order its (child) traffic
> > > units...and the sting in the tail from this observation is that a 
> > > connection must only have a single traffic class....QoS
> > class if you
> > > like, but noting that urgency and importance are orthogonal
> > metrics of
> > > a message/file/stream client application that is external
> > to the TOS
> > > layer network, and some lower server layer network must not try 
> > > and infer dynamic meaning of these metrics from observing
> > client traffic
> > > unit flows.  This point becomes very important in practical 
> > > network interconnects that occur in a BOS network layer network.
> > >  
> > > We should also expand the problem statement below to take these 
> > > factors into account:
> > > -	Net Perf metrics/objectives only relate to the available state.
> > > -	Net Perf metrics/objectives apply independently to each
> > > direction of a bidirectional connection 
> > > -	For all bidirectional connections if one direction enters the
> > > unavailable state then the Net Perf SLA process must be suspended 
> > > in
> > > *both* directions.
> > >  
> > > The above is important in order to prevent Net Perf SLAs being 
> > > distorted by outage events.....though I would caution, from
> > practical
> > > measurements I did in transport networks when
> > mathematically modelling
> > > error/outage events, that a 10 second entry criteria for the 
> > > unavailable state is too long and short-break events (ie
> > outage events
> > > that terminate before 10s is reached) will also distort Net
> > Perf objectives.
> > >  
> > > The above creates some rather serious challenges wrt to
> > synchronising
> > > the start/stopping of Net Perf processes if one wants a
> > good degree of
> > > accuracy.....which is not trivial even at trail termination 
> > > points, let alone in any nested TCM sublayers, noting that on 
> > > failures we often need to re-route connections and so only the 
> > > trail
> > termination
> > > locations will remain invariant across such restoration event.
> > >  
> > > BTW - It should also be rather obvious from the above that
> > if one has
> > > multiple QoS (sic) classes in a connection then the handling of 
> > > entry/exit of unavailable events will become practically
> > intractable
> > > anyway, even at true trail termination points.
> > >  
> > > regards, Neil
> > >  
> > >  
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of David Allan I
> > > > Sent: 23 February 2010 21:41
> > > > To: [email-masked]
> > > > Subject: [mpls-tp] PHBs and "ordered aggregates"
> > > > 
> > > > Hi TPers
> > > > 
> > > > A question relating to the LM transaction.
> > > > 
> > > > Ideally an LM transaction can measure an ordered
> > aggregate as the LM
> > > > transactions benefit from the ordering guarantees and the counts 
> > > > therefore reflect packets in flight at the time the LM is issued.
> > > > 
> > > > The problem is having the OA correspond to something
> > useful that can
> > > > be identified in the LM such that it shares queing
> > discipline with
> > > > the OA (vs. simply microflow guarantees). A read of 3260 
> > > > suggests that a 1:1 correspondence between OA and PHB or PHB 
> > > > class
> > does not
> > > > necessarily exist but that the deltas in ordering
> > guarantees seems
> > > > to be at least partially on the basis (my inference) of 
> > > > arbitrary ECMP next hop selection criteria.
> > > > 
> > > > It strikes me that for TP we need a stake in the ground
> > that a PHB
> > > > on a transport path is an ordered aggregate, or we post a huge 
> > > > health warning on LM that "actual mileage may vary"....
> > > > 
> > > > WDYT?
> > > > Dave
> > > > _______________________________________________
> > > > mpls-tp mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/mpls-tp
> > > > 
> > > _______________________________________________
> > > mpls-tp mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 2 Mar 2010 18:02:44 +0200

Maarten,
Just a few short questions to pinpoint the difference in our views:

1. Do you consider flooding of Ethernet frames with broadcast DA by 802.1Q-compliant bridges as an essential part of the "data plane" construct for Ethernet VLAN? For the reference, I do.

2. Have you noticed that VPLS and 802.1Q flooding rules are different? For the reference, I have.

3. If the data plane constructs for 802.1Q and VPLS are different, what does it say from the point of view
Of "Ethernet layer networks"?

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, March 02, 2010 5:30 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was: RE: PHBs and "ordered aggregates"]

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: maandag 1 maart 2010 6:55
To: Maarten Vissers
Cc: [email-masked]; 'Igor Bryskin'; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Maarten (and all),

IMHO this incorrect:

My 2c,
     Sasha

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

Igor,

Regards,
Maarten

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

Curtis,

Cheers,
Ogor

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

In message

Neil.

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 03 Mar 2010 09:13:29 +0100

Sasha,

See inline for my answers... 

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: dinsdag 2 maart 2010 17:03
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Maarten,

1. Do you consider flooding of Ethernet frames with broadcast DA by
802.1Q-compliant bridges as an essential part of the "data plane" construct
for Ethernet VLAN? For the reference, I do.

[maarten] yes I do.

2. Have you noticed that VPLS and 802.1Q flooding rules are different? For
the reference, I have.

[maarten] No I don't have... There is a suggestion in the text that there
are differences, but there are not if you analyse it. In a VPLS every frame
with unknown unicast or multicast address and every frame with broadcast
address are flooded to all output ports of that VPLS when applied at one of
the input ports of that VPLS.

3. If the data plane constructs for 802.1Q and VPLS are different, what does
it say from the point of view Of "Ethernet layer networks"?

[maarten] I don't see a difference in data plane constructs between
'Ethernet transport service paths' and VPLS. Take for example a PBB-TE
domain and support over that domain a mp2mp Ethernet transport service path.
You will get in this case the same construct as you have in VPLS.

Regards,
Maarten

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, March 02, 2010 5:30 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: maandag 1 maart 2010 6:55
To: Maarten Vissers
Cc: [email-masked]; 'Igor Bryskin'; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Maarten (and all),

IMHO this incorrect:

My 2c,
     Sasha

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

Igor,

Regards,
Maarten

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

Curtis,

Cheers,
Ogor

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

In message

Neil.

Curtis

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 3 Mar 2010 10:37:05 +0200

Maarten,
Please take a look at Section 4.4 "Loop free VPLS" of RFC 4762. The relevant statement says:

<quote>
   a full mesh of PWs is established between PEs.  Since every
   PE is now directly connected to every other PE in the VPLS via a PW,
   there is no longer any need to relay packets, and we can instantiate
   a simpler loop-breaking rule: the "split horizon" rule, whereby a PE
   MUST NOT forward traffic from one PW to another in the same VPLS
   mesh.
<end quote>

Similar text can be found in Section 4.2.5 "Split Horizon Forwarding" of RFC 4761.

I wonder what kind of analysis results in disregarding it...

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Wednesday, March 03, 2010 10:13 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was: RE: PHBs and "ordered aggregates"]

Sasha,

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: dinsdag 2 maart 2010 17:03
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Maarten,

[maarten] yes I do.

Regards,
Maarten

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, March 02, 2010 5:30 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: maandag 1 maart 2010 6:55
To: Maarten Vissers
Cc: [email-masked]; 'Igor Bryskin'; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Maarten (and all),

IMHO this incorrect:

My 2c,
     Sasha

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

Igor,

Regards,
Maarten

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

Curtis,

Cheers,
Ogor

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

In message

Neil.

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 03 Mar 2010 10:48:35 +0100

Sasha,

I was aware of this text when I replied to you.

You have to look at the VPLS from its input and output ports on the PEs.
E.g. take a VPLS with 5 ports A,B,C,D,E of which each port is located on a
different PE, e.g. PE1, PE3, PE7, PE10 and PE25. 

When a frame with an unknown unicast/multicast address, or a broadcast
address is applied at input port A located on PE1, then this frame is output
at the ports B,C,D,E of the VPLS located on PE3/PE7/PE10/PE25. This
behavious is the same as in an Ethernet VLAN with 5 ports A, B, C, D and E.

The action in PE1 for this VPLS is that it will send a copy of this frame to
each of the four PWs supporting this VPLS. A PB node would do the same if it
has four 1GE ports connecting PB1 with VLAN port A to four other PB nodes
(e.g. PB3, PB7, PB10, PB25) having VLAN ports B, C, D and E resp.

PE3, PE7, PE10 and PE25 receiving this flooded frame will not send this
frame to any of the other PEs in the VPLS. 
PB3, PB7, PB10 and PB25 receiving this flooded frame will not send this
frame to any of the other PBs in the VLAN. 
I.e. same behaviour.

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: woensdag 3 maart 2010 9:37
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Maarten,
Please take a look at Section 4.4 "Loop free VPLS" of RFC 4762. The relevant
statement says:

<quote>

Similar text can be found in Section 4.2.5 "Split Horizon Forwarding" of RFC
4761.

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Wednesday, March 03, 2010 10:13 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Sasha,

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: dinsdag 2 maart 2010 17:03
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Maarten,

[maarten] yes I do.

Regards,
Maarten

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, March 02, 2010 5:30 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: maandag 1 maart 2010 6:55
To: Maarten Vissers
Cc: [email-masked]; 'Igor Bryskin'; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Maarten (and all),

IMHO this incorrect:

My 2c,
     Sasha

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

Igor,

Regards,
Maarten

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

Curtis,

Cheers,
Ogor

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

In message

Neil.

Curtis

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 3 Mar 2010 12:59:14 +0200

Maarten,
[[Sasha]] Correct.
[[Sasha] Incorrect. PB3 receiving this frame would not send it back to PB1, but would send it to PB7, PB10 and PB25 as well. IEEE 802.1ad ("Provider Bridges") did not introduce any change in treating broadcast frames relative to 802.1Q.

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Wednesday, March 03, 2010 11:49 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was: RE: PHBs and "ordered aggregates"]

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: woensdag 3 maart 2010 9:37
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Maarten,

<quote>

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Wednesday, March 03, 2010 10:13 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Sasha,

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: dinsdag 2 maart 2010 17:03
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Maarten,

[maarten] yes I do.

Regards,
Maarten

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, March 02, 2010 5:30 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: maandag 1 maart 2010 6:55
To: Maarten Vissers
Cc: [email-masked]; 'Igor Bryskin'; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Maarten (and all),

IMHO this incorrect:

My 2c,
     Sasha

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

Igor,

Regards,
Maarten

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

Curtis,

Cheers,
Ogor

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

In message

Neil.

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 03 Mar 2010 15:13:37 +0100

Sasha,

See inline... 

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: woensdag 3 maart 2010 11:59
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Maarten,
        PE3, PE7, PE10 and PE25 receiving this flooded frame will not send
this
        frame to any of the other PEs in the VPLS.
[[Sasha]] Correct.
        PB3, PB7, PB10 and PB25 receiving this flooded frame will not send
this
        frame to any of the other PBs in the VLAN.
[[Sasha] Incorrect. PB3 receiving this frame would not send it back to PB1,
but would send it to PB7, PB10 and PB25 as well. IEEE 802.1ad ("Provider
Bridges") did not introduce any change in treating broadcast frames relative
to 802.1Q.
[maarten] The 5-port VLAN does not have link connections on the 1GE links
between PB1 and PB3, PB1 and PB7, PB1 and PB10, PB1 and PB25. As such PB1
can not send the frame to PB3, PB7, PB10 and PB25. I.e. there is no 'full
mesh' of VLAN link connections in the PBN.

[maarten] The behaviour of the 5-port VLAN and the 5-port VPLS are the same
from the perspective of the input/output ports.

Regards,
Maarten

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Wednesday, March 03, 2010 11:49 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: woensdag 3 maart 2010 9:37
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Maarten,

<quote>

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Wednesday, March 03, 2010 10:13 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Sasha,

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: dinsdag 2 maart 2010 17:03
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Maarten,

[maarten] yes I do.

Regards,
Maarten

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, March 02, 2010 5:30 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: maandag 1 maart 2010 6:55
To: Maarten Vissers
Cc: [email-masked]; 'Igor Bryskin'; [email-masked]
Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was:
RE: PHBs and "ordered aggregates"]

Maarten (and all),

IMHO this incorrect:

My 2c,
     Sasha

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

Igor,

Regards,
Maarten

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

Curtis,

Cheers,
Ogor

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

In message

Neil.

Curtis