Subject: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 7 Apr 2010 23:21:18 +0300

Hi,
I'd like to share with the list and, specifically, with the authors of the MPLS-TP Framework and MPLS-TP OAM Framework drafts my serious doubts regarding using the so-called "Section OAM" on Sections represented by LAN (MP2MP) interfaces. To the best of my understanding, such interfaces are allowed (or, at least, not prohibited) in MPLS-TP.

To the best of my understanding, LSP OAM packet insert GAL in the label stack immediately after the last label defining this LSP. Since MPLS-TP does not allow MP2P LSP (no merge), the label stack above GAL can be used by the node that receives an LSP OAM packet as data plane identification of the LSP to which this OAM packet belongs. This behavior is well known in MPLS, e.g., see  Section 4.4 "Receiving MPLS Echo Request" of RFC 4379 (both the interface and received label stack of the received LSP-Ping packet are stored as part of processing).

"Section OAM" uses GAL as the top (and only) label in the label stack. To me this means that an MPLS-TP node that receives a Section OAM packet from a LAN interface cannot identify the originating adjacent node based on the interface and received label stack (there is only one GAL!).

Of course the only LAN interfaces worth mentioning are Ethernet ones, and the receiving node can look at the source MAC address of the received packet, but this looks to me like a serious layer violation.

These notes  have been triggered by the resent thread on Section service initiated by Maarten.

Did I miss something important?

Regards,
     Sasha

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 7 Apr 2010 14:15:21 -0700

Dear Alexander,
I think that your concern can be addressed by ID(s) carried as ACH TLV. The
Proactive CV/CC for MPLS-TP in Figure 3 suggests that a MEP-ID that uniquely
identifies source of the BFP packet precedes the BFD Control packet. I think
that using MPLS-TP ID in ACH TLVs would be common case for MPLS-TP OAM.

Regards,
Greg

On Wed, Apr 7, 2010 at 1:21 PM, Alexander Vainshtein <
[email-masked]> wrote:

>  Hi,
>
> I’d like to share with the list and, specifically, with the authors of the
> MPLS-TP Framework and MPLS-TP OAM Framework drafts my serious doubts
> regarding using the so-called “Section OAM” on Sections represented by LAN
> (MP2MP) interfaces. To the best of my understanding, such interfaces are
> allowed (or, at least, not prohibited) in MPLS-TP.
>
>
>
> To the best of my understanding, LSP OAM packet insert GAL in the label
> stack immediately after the last label defining this LSP. Since MPLS-TP does
> not allow MP2P LSP (no merge), the label stack above GAL can be used by the
> node that receives an LSP OAM packet as data plane identification of the LSP
> to which this OAM packet belongs. This behavior is well known in MPLS, e.g.,
> see  Section 4.4 “Receiving MPLS Echo Request” of RFC 4379 (both the
> interface and received label stack of the received LSP-Ping packet are
> stored as part of processing).
>
>
>
> “Section OAM” uses GAL as the top (and only) label in the label stack. To
> me this means that an MPLS-TP node that receives a Section OAM packet from a
> LAN interface cannot identify the originating adjacent node based on the
> interface and received label stack (there is only one GAL!).
>
>
>
> Of course the only LAN interfaces worth mentioning are Ethernet ones, and
> the receiving node can look at the source MAC address of the received
> packet, but this looks to me like a serious layer violation.
>
>
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
>

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 7 Apr 2010 14:21:42 -0700

Hi Greg,

I have to agree with Sasha. The TLV solution is not attractive because TLVs are not HW friendly and this means HW can't process them. Also it still doesn't solve the problem of binding a BFD packet to its associated LSP.

Regards,
Shahram

From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Wednesday, April 07, 2010 2:15 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Dear Alexander,
I think that your concern can be addressed by ID(s) carried as ACH TLV. The Proactive CV/CC for MPLS-TP in Figure 3 suggests that a MEP-ID that uniquely identifies source of the BFP packet precedes the BFD Control packet. I think that using MPLS-TP ID in ACH TLVs would be common case for MPLS-TP OAM.

Regards,
Greg
On Wed, Apr 7, 2010 at 1:21 PM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
I'd like to share with the list and, specifically, with the authors of the MPLS-TP Framework and MPLS-TP OAM Framework drafts my serious doubts regarding using the so-called "Section OAM" on Sections represented by LAN (MP2MP) interfaces. To the best of my understanding, such interfaces are allowed (or, at least, not prohibited) in MPLS-TP.

Regards,
     Sasha

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

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 7 Apr 2010 14:33:51 -0700

Dear Shahram,
I didn't say that it is "lightweight" ;) I just point that whether we go
with BFD or Y.1731 we have additional ID(s) carried as ACH TLV. I believe
that input from vendors like Broadcom can help us compare two approaches in
regard of their relative friendliness towards HW for OAM in MPLS-TP. Since
pro-active CV/CC as well as PM rely on HW related scenarios can be explored
comparing efficiency of each approach.

Regards,
Greg

On Wed, Apr 7, 2010 at 2:21 PM, Shahram Davari <[email-masked]> wrote:

>  Hi Greg,
>
>
>
> I have to agree with Sasha. The TLV solution is not attractive because TLVs
> are not HW friendly and this means HW can’t process them. Also it still
> doesn’t solve the problem of binding a BFD packet to its associated LSP.
>
>
>
> Regards,
>
> Shahram
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Greg Mirsky
> *Sent:* Wednesday, April 07, 2010 2:15 PM
> *To:* Alexander Vainshtein
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN
> interfaces?
>
>
>
> Dear Alexander,

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 7 Apr 2010 14:38:40 -0700

Hi Greg,

>From HW/Chip perspective fixed location and fixed format of identifiers are important, specially for PM OAM packets which require line rate processing. That is also why I get worried when multiple identifiers (IETF and ITU) are introduced for the same object.

Thanks,
Shahram

From: Greg Mirsky [mailto:[email-masked]]
Sent: Wednesday, April 07, 2010 2:34 PM
To: Shahram Davari
Cc: Alexander Vainshtein; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Dear Shahram,
I didn't say that it is "lightweight" ;) I just point that whether we go with BFD or Y.1731 we have additional ID(s) carried as ACH TLV. I believe that input from vendors like Broadcom can help us compare two approaches in regard of their relative friendliness towards HW for OAM in MPLS-TP. Since pro-active CV/CC as well as PM rely on HW related scenarios can be explored comparing efficiency of each approach.

Regards,
Greg
On Wed, Apr 7, 2010 at 2:21 PM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Regards,
Shahram

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Greg Mirsky
Sent: Wednesday, April 07, 2010 2:15 PM
To: Alexander Vainshtein
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Dear Alexander,

Regards,
Greg

Regards,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 8 Apr 2010 08:49:01 +0300

Greg, Shahram and all,
Please note that the ACH TLV (regardless of how difficult or how simple is its processing) does not provide the data plane identification of the source node of the received packet. In the case of LSP OAM, the received label stack and ingress interface provide that.

In other words, the concept of treating (data link) Sections as "label-less LSPs" does not hold water: label stack of depth 0 cannot identify anything. It remains to be seen, to which extent this hole affects the MPLS-TP architecture.

As for references to Y.1731, please note that its OAM packets are not really fate-sharing with the user traffic (link trace is a well-known example). MPLS-TP has been trying to improve that: this is why its MIPs are based on TTL processing and not on, say, usage of Router Alert label.

At the same time, identifying MEPs and MIPs by their MAC addresses (inserted as source MAC addresses in the OAM packets) is perfectly valid in Ethernet - but, IMO, not in MPLS-TP.

My 2c,
     Sasha

________________________________
From: Greg Mirsky [[email-masked]]
Sent: Thursday, April 08, 2010 12:33 AM
To: Shahram Davari
Cc: Alexander Vainshtein; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Dear Shahram,

Regards,
Greg

I have to agree with Sasha. The TLV solution is not attractive because TLVs are not HW friendly and this means HW can’t process them. Also it still doesn’t solve the problem of binding a BFD packet to its associated LSP.

Regards,
Shahram

Dear Alexander,

Regards,
Greg
On Wed, Apr 7, 2010 at 1:21 PM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
I’d like to share with the list and, specifically, with the authors of the MPLS-TP Framework and MPLS-TP OAM Framework drafts my serious doubts regarding using the so-called “Section OAM” on Sections represented by LAN (MP2MP) interfaces. To the best of my understanding, such interfaces are allowed (or, at least, not prohibited) in MPLS-TP.

To the best of my understanding, LSP OAM packet insert GAL in the label stack immediately after the last label defining this LSP. Since MPLS-TP does not allow MP2P LSP (no merge), the label stack above GAL can be used by the node that receives an LSP OAM packet as data plane identification of the LSP to which this OAM packet belongs. This behavior is well known in MPLS, e.g., see  Section 4.4 “Receiving MPLS Echo Request” of RFC 4379 (both the interface and received label stack of the received LSP-Ping packet are stored as part of processing).

“Section OAM” uses GAL as the top (and only) label in the label stack. To me this means that an MPLS-TP node that receives a Section OAM packet from a LAN interface cannot identify the originating adjacent node based on the interface and received label stack (there is only one GAL!).

Regards,
     Sasha

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 08 Apr 2010 08:49:00 +0200

Sasha,
 
I have a serious doubt if a mp2mp physical LAN will be applied in MPLS-TP
networks. 
1000BASSE-X, 10GBASE-R, 40GBASE-R and 100GBASE-R physical interfaces do not
support such mp2mp LAN.
Only 100BASE-T ports would support it, but will such FE ports be used in a
mp2mp configuration?
Traffic engineering gets complex if we use mp2mp media.
 
Separate of the above question on supporting other then p2p media in
MPLS-TP, I would like to comment on the following consideration of you:
 
>  "Section OAM" uses GAL as the top (and only) label in the label stack. To
me this means that an
> MPLS-TP node that receives a Section OAM packet from a LAN interface
cannot identify the
> originating adjacent node based on the interface and received label stack
(there is only one GAL!).

> Of course the only LAN interfaces worth mentioning are Ethernet ones, and
the receiving node can

> look at the source MAC address of the received packet, but this looks to
me like a serious layer violation.

If one would use a mp2mp media to carry an MPLS-TP section layer signal
over, then the MPLS-TP section layer transport path may still be a p2p
transport path. For this case the Ethernet to MPLS-TP adaptation will insert
a unicast destination address on all the MPLS-TP packets. The receiving
Ethernet to MPLS-TP adaptation function will accept only ethernet frames
with one specific source address. Result is to the receiving port
(adaptation function) will only pass through MPLS-TP packets from one of the
input ports on the mp2mp medium. This is not a layer violation as you
suggest, it is a normal, required operation in the adaptation function.

By using MPLS-TP section-CC/CV OAM, necessary connectivity can be verified.

If one would use a mp2mp medium to support a full mesh of p2p section layer
transport paths between n ports on that medium, then  the Ethernet to
MPLS-TP adaptation will have n-1 input/output ports connected with n-1
MPLS-TP Section MEP functions. The MPLS-TP packets from each MEP will be
prepended by the ethernet header, including a unicast destination address. 

As in this case multiple MPLS-TP section (layer transport path) instances
(SIs) are multiplexed into one server layer signal, it is necessary to have
a MPLS-TP SI identifier. As long as there is only one section layer
transport path instance between any two ports on the n-port medium it is
possible and correct to use the source address as SI demultiplexer;
section-LSP label is <da,sa>. 

If there would be a need to carry multiple section instances between two
ports on this n-port medium it will be necessary to add an additional SI
identifier as the <da,sa> demultiplexer is not longer unique. This
additional SI identifier could be a label in an additional section LSP label
stack entry header, or could be a VLAN ID in a VLAN Tag. If you use the
latter you would have a PBB-TE ESP like label
<section-lsp-da,section-lsp-sa,section-lsp-vid> (instead of
<esp-da,esp-sa,esp-vid>). If you would use the former you could use a 'per
medium label space', or a 'per interface port label space'.

by using MPLS-TP section-CC/CV OAM, necessary connectivity can be verified.

Alternatively it is possible to replace the MPLS-TP Section layer by an
Ethernet Section layer and use Ethernet OAM to check the connectivity
between the n-ports.

But once again, is mp2mp media in MPLS-TP really used?

Regards,

Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: donderdag 8 april 2010 7:49
To: Greg Mirsky; Shahram Davari
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Greg, Shahram and all,
Please note that the ACH TLV (regardless of how difficult or how simple is
its processing) does not provide the data plane identification of the source
node of the received packet. In the case of LSP OAM, the received label
stack and ingress interface provide that.
 
In other words, the concept of treating (data link) Sections as "label-less
LSPs" does not hold water: label stack of depth 0 cannot identify anything.
It remains to be seen, to which extent this hole affects the MPLS-TP
architecture.
 
As for references to Y.1731, please note that its OAM packets are not really
fate-sharing with the user traffic (link trace is a well-known example).
MPLS-TP has been trying to improve that: this is why its MIPs are based on
TTL processing and not on, say, usage of Router Alert label.
 
At the same time, identifying MEPs and MIPs by their MAC addresses (inserted
as source MAC addresses in the OAM packets) is perfectly valid in Ethernet -
but, IMO, not in MPLS-TP.
 
My 2c,
     Sasha
 
  _____  

Dear Shahram,

Regards,
Greg

Hi Greg,

I have to agree with Sasha. The TLV solution is not attractive because TLVs
are not HW friendly and this means HW can't process them. Also it still
doesn't solve the problem of binding a BFD packet to its associated LSP.

Regards,

Shahram

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Greg Mirsky
Sent: Wednesday, April 07, 2010 2:15 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Dear Alexander,

Regards,
Greg

On Wed, Apr 7, 2010 at 1:21 PM, Alexander Vainshtein
<[email-masked]> wrote:

Hi,

I'd like to share with the list and, specifically, with the authors of the
MPLS-TP Framework and MPLS-TP OAM Framework drafts my serious doubts
regarding using the so-called "Section OAM" on Sections represented by LAN
(MP2MP) interfaces. To the best of my understanding, such interfaces are
allowed (or, at least, not prohibited) in MPLS-TP.

see  Section 4.4 "Receiving MPLS Echo Request" of RFC 4379 (both the

"Section OAM" uses GAL as the top (and only) label in the label stack. To me
this means that an MPLS-TP node that receives a Section OAM packet from a
LAN interface cannot identify the originating adjacent node based on the
interface and received label stack (there is only one GAL!).

These notes  have been triggered by the resent thread on Section service
initiated by Maarten. 

Regards,

     Sasha

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 08 Apr 2010 09:04:42 +0200

Hi Sasha,

You wrote:

> As for references to Y.1731, please note that its OAM packets are not
> really fate-sharing with the user traffic (link trace is a well-known
> example).

Would you please be so kind to explain this, why are Y.1731
PDUs not fate sharing and in particular link trace.

> MPLS-TP has been trying to improve that: this is why its MIPs
> are based on TTL processing and not on, say, usage of Router Alert label.

Why is there than an issue with instantiating two MIPs in the
same LSR?

Regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 8 Apr 2010 10:07:05 +0300

Maarten,
Lots of thanks for a prompt response. Please see inline below.

Regards,
     Sasha

From: Maarten Vissers [mailto:[email-masked]]
Sent: Thursday, April 08, 2010 9:49 AM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Sasha,

I have a serious doubt if a mp2mp physical LAN will be applied in MPLS-TP networks.
1000BASSE-X, 10GBASE-R, 40GBASE-R and 100GBASE-R physical interfaces do not support such mp2mp LAN.
Only 100BASE-T ports would support it, but will such FE ports be used in a mp2mp configuration?
Traffic engineering gets complex if we use mp2mp media.
[[[Sasha]]] LAN interfaces arise if you connect 3 or more MPLS-TP LSRs to a L2 switch which is not aware of MPLS-TP. So this is not a physical media issue.
AFAIK, using L2 switches for connecting multiple routers is quite common.

Separate of the above question on supporting other then p2p media in MPLS-TP, I would like to comment on the following consideration of you:

>  "Section OAM" uses GAL as the top (and only) label in the label stack. To me this means that an
> MPLS-TP node that receives a Section OAM packet from a LAN interface cannot identify the
> originating adjacent node based on the interface and received label stack (there is only one GAL!).
>
> Of course the only LAN interfaces worth mentioning are Ethernet ones, and the receiving node can
> look at the source MAC address of the received packet, but this looks to me like a serious layer violation.

If one would use a mp2mp media to carry an MPLS-TP section layer signal over, then the MPLS-TP section layer transport path may still be a p2p transport path. For this case the Ethernet to MPLS-TP adaptation will insert a unicast destination address on all the MPLS-TP packets. The receiving Ethernet to MPLS-TP adaptation function will accept only ethernet frames with one specific source address. Result is to the receiving port (adaptation function) will only pass through MPLS-TP packets from one of the input ports on the mp2mp medium. This is not a layer violation as you suggest, it is a normal, required operation in the adaptation function.
[[[Sasha]]] MPLS data plane does not require check of source MAC addresses, nor is it commonly implemented. And in any case relying on source MAC addresses would be a layer violation. Please compare this to usage of "context labels" in upstream label allocation (in RFC 5331),

If one would use a mp2mp medium to support a full mesh of p2p section layer transport paths between n ports on that medium, then  the Ethernet to MPLS-TP adaptation will have n-1 input/output ports connected with n-1 MPLS-TP Section MEP functions. The MPLS-TP packets from each MEP will be prepended by the ethernet header, including a unicast destination address.
[[[Sasha]]] Please see my previous comment about layer violation.

As in this case multiple MPLS-TP section (layer transport path) instances (SIs) are multiplexed into one server layer signal, it is necessary to have a MPLS-TP SI identifier. As long as there is only one section layer transport path instance between any two ports on the n-port medium it is possible and correct to use the source address as SI demultiplexer; section-LSP label is <da,sa>.

If there would be a need to carry multiple section instances between two ports on this n-port medium it will be necessary to add an additional SI identifier as the <da,sa> demultiplexer is not longer unique. This additional SI identifier could be a label in an additional section LSP label stack entry header, or could be a VLAN ID in a VLAN Tag. If you use the latter you would have a PBB-TE ESP like label <section-lsp-da,section-lsp-sa,section-lsp-vid> (instead of <esp-da,esp-sa,esp-vid>). If you would use the former you could use a 'per medium label space', or a 'per interface port label space'.
by using MPLS-TP section-CC/CV OAM, necessary connectivity can be verified.

Alternatively it is possible to replace the MPLS-TP Section layer by an Ethernet Section layer and use Ethernet OAM to check the connectivity between the n-ports.

Regards,
Maarten

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein

My 2c,
     Sasha

Regards,
Greg

Regards,
Shahram

Dear Alexander,

Regards,
Greg

Regards,
     Sasha

---

From: Mach Chen <[email-masked]>
Date: Thu, 08 Apr 2010 15:14:13 +0800

Hi Alexander,

--------------------------------------------------
From: "Alexander Vainshtein" <[email-masked]>
Sent: Thursday, April 08, 2010 1:49 PM
To: "Greg Mirsky" <[email-masked]>; "Shahram Davari" 
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Subject: Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

> its processing) does not provide the data plane identification of the 
> source node of the received packet. In the case of LSP OAM, the received 
> label stack and ingress interface provide that.
>

How about including the FEC TLV of that Section? (Just like RFC 4379 does 
for PHP, due to the impact of PHP, the egress also receives unlabeled 
packets, the situation is the same as this MPLS-TP Section OAM).

Best regards,
Mach

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 08 Apr 2010 09:36:24 +0200

Sasha,
 
See inline..

  _____  

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: donderdag 8 april 2010 9:07
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Maarten,

Regards,

     Sasha

Sasha,

[[[Sasha]]] LAN interfaces arise if you connect 3 or more MPLS-TP LSRs to a
L2 switch which is not aware of MPLS-TP. So this is not a physical media
issue.

[maarten] If you want to use L2 (Ethernet) switches to interconnect MPLS-TP
switches, then I do not understand the MPLS-TP architecture anylonger.
MPLS-TP switches are replacing L2 (Ethernet) Switches. But if you want to
interconnect two MPLS-TP subnetworks via an Ethernet based packet transport
network, then this E-PTN network will be very similar to MPLS-TP network (it
has an Ethernet transport service, Ethernet transport path and Ethernet
section layer). Ethernet p2p VLANs will be used to carry p2p MPLS-TP PWs,
service-LSPs, transport-LSPs and/or section-LSPs. But those MPLS-TP
transport path signals will not be carried over mp2mp VLANs. Let's hear what
other people think about this issue.

me this means that an

cannot identify the

the receiving node can

[[[Sasha]]] MPLS data plane does not require check of source MAC addresses,
nor is it commonly implemented. And in any case relying on source MAC
addresses would be a layer violation. Please compare this to usage of
"context labels" in upstream label allocation (in RFC 5331), 

[maarten] There is no layer violation. This check of source MAC address is
part of the ETH/MPLS-TP_A function, and functionally belongs to the ETH
layer processing.

[maarten] If there would be a need to support such check, then MPLS-TP NNI
ports would have to implement it. If there is no need, then this issue
disappears. No need may be due to no need to carry MPLS-TP section-LSP
signals over mp2mp LANs or VLANs, or due to use of 'per mp2mp LAN/VLAN'
labelled-section-LSPs.

Regards,

Maarten

Regards,

Maarten

  _____  

Greg, Shahram and all,

My 2c,

     Sasha

  _____  

Dear Shahram,

Regards,
Greg

Hi Greg,

Regards,

Shahram

Dear Alexander,

Regards,
Greg

Hi,

Regards,

     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 8 Apr 2010 11:38:05 +0300

Resending (the previous version was too big).
I have snipped parts of the thread to make it shorter.

Regards,
     Sasha

From: Alexander Vainshtein
Sent: Thursday, April 08, 2010 11:28 AM
To: 'Maarten Vissers'
Cc: [email-masked]
Subject: RE: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Maarten,
Lots of thanks for a prompt response. Please see more inline (bold purple).

Regards,
     Sasha

From: Maarten Vissers [mailto:[email-masked]]
Sent: Thursday, April 08, 2010 10:36 AM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Sasha,

See inline..

Regards,
     Sasha

Sasha,

.snipped...

[maarten] If you want to use L2 (Ethernet) switches to interconnect MPLS-TP switches, then I do not understand the MPLS-TP architecture any  longer.
[[[Sasha]]] Welcome to the club! I have been asking for months for clarification of this item, namely whether LAN interfaces (physically formed by interconnecting MPLS-TP LSRs via L2 switches) is or is not allowed in MPLS-TP. From the latest version of the MPLS-TP data plane draft<http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-data-plane/> it looks as if these interfaces are allowed, e.g., see Section 5.1.
 MPLS-TP switches are replacing L2 (Ethernet) Switches.
[[[Sasha]]] Please take a look at Section 5.1.2 of the MPLS-TP data plane draft. IMHO it explicitly suggests that interconnection of MPLS-LSRs via  L2 switches can be used for  P2MP LSPs.
... snipped ...
 Let's hear what other people think about this issue.[[[Sasha]]]  Sure
If one would use a mp2mp media to carry an MPLS-TP section layer signal over, then the MPLS-TP section layer transport path may still be a p2p transport path. For this case the Ethernet to MPLS-TP adaptation will insert a unicast destination address on all the MPLS-TP packets. The receiving Ethernet to MPLS-TP adaptation function will accept only ethernet frames with one specific source address. Result is to the receiving port (adaptation function) will only pass through MPLS-TP packets from one of the input ports on the mp2mp medium. This is not a layer violation as you suggest, it is a normal, required operation in the adaptation function.
[[[Sasha]]] MPLS data plane does not require check of source MAC addresses, nor is it commonly implemented. And in any case relying on source MAC addresses would be a layer violation. Please compare this to usage of "context labels" in upstream label allocation (in RFC 5331),
[maarten] There is no layer violation. This check of source MAC address is part of the ETH/MPLS-TP_A function, and functionally belongs to the ETH layer processing. [[[Sasha]]] Again: this check does not exist in the MPLS data plane. And , according to Requirement 1 in RFC 5654<http://datatracker.ietf.org/doc/rfc5654/>, MPLS-TP data plane MUST be the same as that of MPLS. Giving fancy names to some data plane elements does not change basics.
[maarten] If there would be a need to support such check, then MPLS-TP NNI ports would have to implement it. If there is no need, then this issue disappears. No need may be due to no need to carry MPLS-TP section-LSP signals over mp2mp LANs or VLANs, or due to use of 'per mp2mp LAN/VLAN' labeled-section-LSPs. [[[Sasha]]] Please see my comment above with the reference to Section 5.1.2 of the MPLS-TP data plane draft. IMHO it indicates that the need exists.
... snipped to the end ...

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 8 Apr 2010 12:05:25 +0300

Huub,

Please see some answers inline below. Hopefully they will be useful.

Regards,
     Sasha

-----Original Message-----
From: Huub van Helvoort [mailto:[email-masked]] 
Sent: Thursday, April 08, 2010 10:05 AM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Hi Sasha,

[[[Sasha]]] 802.1ag/Y.1731 Link Trace messages (LTM) are send with one of the well-known multicast destination MAC addresses ("All MEPs and MIPs at level x"). As a consequence, they are not forwarded to the destination by the Ethernet data plane, Instead, they are captured by each switch that contains a MEP or MIP at the specified level the ingress in, and their "real" destination address (in the body of the message) is looked up in the FDB. If FDB contains a single entry for this destination, the packet will be forwarded via the appropriate egress interface.
In other words, forwarding of the LTM messages involves some mechanisms on top of the regular Ethernet data plane processing. E.g., if the access of these mechanisms to the FDB produces wrong results (i.e., a HW problem), LTM may be dropped in the middle, follow a wrong path etc. What's more, if an LTM is received by a L2 switch that does not have any MIPs or MEPs at the given level (because nobody has configured them there), it will be probably flooded to multiple egress interfaces - and you may see several branches of link trace...

Why is there than an issue with instantiating two MIPs in the 
same LSR?
[[[Sasha]]] Do you refer to the proposal to implement MIPs at ingress and egress interfaces? If this is the case, the problem is that MPLS data plane performs the TTL check only once. If the check is done at ingress and says that the packet must not be forwarded, sending it to egress interface to be captured by the egress MIP is on top of the regular data plane forwarding (very similar to link trace in 802.1ag). And if the check is done at egress, you cannot have a MIP on the ingress interface.

Regards, Huub.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 8 Apr 2010 11:28:09 +0300

Maarten,

Regards,
     Sasha

Sasha,

See inline..

Regards,
     Sasha

Sasha,

[maarten] If you want to use L2 (Ethernet) switches to interconnect MPLS-TP switches, then I do not understand the MPLS-TP architecture any  longer.
[[[Sasha]]] Welcome to the club! I have been asking for months for clarification of this item, namely whether LAN interfaces (physically formed by interconnecting MPLS-TP LSRs via L2 switches) is or is not allowed in MPLS-TP. From the latest version of the MPLS-TP data plane draft<http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-data-plane/> it looks as if these interfaces are allowed, e.g., see Section 5.1.
 MPLS-TP switches are replacing L2 (Ethernet) Switches.
[[[Sasha]]] Please take a look at Section 5.1.2 of the MPLS-TP data plane draft. IMHO it explicitly suggests that interconnection of MPLS-LSRs via  L2 switches can be used for  P2MP LSPs.
But if you want to interconnect two MPLS-TP subnetworks via an Ethernet based packet transport network, then this E-PTN network will be very similar to MPLS-TP network (it has an Ethernet transport service, Ethernet transport path and Ethernet section layer). Ethernet p2p VLANs will be used to carry p2p MPLS-TP PWs, service-LSPs, transport-LSPs and/or section-LSPs. But those MPLS-TP transport path signals will not be carried over mp2mp VLANs.
[[[Sasha]]] This is not the case I am dealing with, so let's skip it.
 Let's hear what other people think about this issue.[[[Sasha]]]  Sure

Regards,
Maarten

Regards,
Maarten

My 2c,
     Sasha

Regards,
Greg

Regards,
Shahram

Dear Alexander,

Regards,
Greg

Regards,
     Sasha

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 9 Apr 2010 09:11:00 +0200

> But once again, is mp2mp media in MPLS-TP really used?

Good question.

As you pointed out, running MPLS-TP over mp2mp media is going to defeat MPLS-TP traffic engineering so I doubt this will be really used in properly TE networks.

However, Sasha is right in claiming that this is not precluded.

What is the problem to restrict MPLS-TP Section OAM to only p2p and p2mp media?

Thanks, Italo

P.S. Please note my new email address, [email-masked], effective since 1 November 2009.

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
	Sent: giovedì 8 aprile 2010 8.49
	To: 'Alexander Vainshtein'
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

	Sasha,

	 

	Regards,

	Maarten

	Greg, Shahram and all,

	 
	 
	My 2c,
	     Sasha

	Dear Shahram,
	
	Regards,
	Greg

		Hi Greg,

		Regards,

		Shahram

		Dear Alexander,
		
		Regards,
		Greg

		On Wed, Apr 7, 2010 at 1:21 PM, Alexander Vainshtein <[email-masked]> wrote:

		Hi,

		Regards,

		     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 9 Apr 2010 13:51:04 +0300

Italo,
Lots of thanks for the input.

One minor point: I do not think that p2mp media exists. It is either p2p or mp2mp.

Regarding restrictions:

If we restrict MPLS-TP to P2P media, many technical issues will become non-relevant (my example with the Section OAM is, IMHO, just the top of an iceberg). But such a restriction must be explicit, it cannot be left at the level of "Don't worry, nobody will ever do such a thing". Because somebody will do it.

My 2c,
     Sasha

________________________________
From: BUSI ITALO [[email-masked]]
Sent: Friday, April 09, 2010 10:11 AM
To: Maarten Vissers; Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Good question.

Thanks, Italo

Sasha,

Separate of the above question on supporting other then p2p media in MPLS-TP, I would like to comment on the following consideration of you:

>  “Section OAM” uses GAL as the top (and only) label in the label stack. To me this means that an

Regards,
Maarten

Greg, Shahram and all,

My 2c,
     Sasha

Dear Shahram,

Regards,
Greg

Regards,
Shahram

Dear Alexander,

Regards,
Greg

Regards,
     Sasha

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 9 Apr 2010 13:11:28 +0200

Sasha,
 
thanks for your reply.
 
Regarding p2mp media, how would you consider a scenario where MPLS-TP is running over p2mp SDH VC?
 
I understood the rough consensus is not to preclude running MPLS-TP over mp2mp media.
 
If my understanding regarding the rough consensus is correct, I agree with you that we need to document/resolve all the associated technical issues.
 
On my side, if would be fine to clearly state that MPLS-TP Section OAM MUST NOT be used on mp2mp media.
 
If my understanding regarding the rough consensus in incorrect, I agree with you that we need to explicity document that MPLS-TP MUST NOT run over mp2mp media.
 
Italo

 

	From: Alexander Vainshtein [mailto:[email-masked]] 
	Sent: venerdì 9 aprile 2010 12.51
	To: BUSI ITALO
	Cc: [email-masked]; Maarten Vissers
	Subject: RE: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

	Italo,

	Regarding restrictions: 

	My 2c,
	     Sasha

	Good question.

	Thanks, Italo

	 

		Sasha,

		 

		Regards,

		Maarten

		Greg, Shahram and all,

		 
		 
		My 2c,
		     Sasha

		Dear Shahram,
		
		Regards,
		Greg

			Hi Greg,

			Regards,

			Shahram

			Dear Alexander,
			
			Regards,
			Greg

			Hi,

			Regards,

			     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 10 Apr 2010 18:07:01 +0300

Italo,
Lots of thanks for a prompt response and a very useful input..

Your example for p2mp media looks valid. I must admit that I have never considered it. I think that actually using such a media as an MPLS-TP Section could be highly problematic, but this is another issue.

Regarding running MPLS-TP over mp2mp media: you may be quite right regarding the rough (in both senses of the word!) consensus that it is allowed. But IMO this point should be explicitly raised on the list because, as Maarten's messages show, there are some people that vigorously object to it. 

Assuming that consensus supports MPLS-TP over mp2mp media: stating that Section OAM MUST NOT be used on MP2MP media would resolve one specific issue. 

My 2c,
     Sasha

From: BUSI ITALO [[email-masked]]
Sent: Friday, April 09, 2010 2:11 PM
To: Alexander Vainshtein
Cc: [email-masked]; Maarten Vissers
Subject: RE: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Sasha,

thanks for your reply.

Italo

Italo,

Regarding restrictions: 

My 2c,
     Sasha

Good question.

Thanks, Italo

Sasha,

Regards,
Maarten

Greg, Shahram and all,

My 2c,
     Sasha

Dear Shahram,

Regards,
Greg

Hi Greg,

Regards,
Shahram

Dear Alexander,

Regards,
Greg

Regards,
     Sasha

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 11 Apr 2010 01:06:34 -0400

In message <[email-masked]>
> One minor point: I do not think that p2mp media exists. It is either

p2mp media exists and it is being used for video distribution.

> Regarding restrictions:
>  
> If we restrict MPLS-TP to P2P media, many technical issues will become non-=
> relevant (my example with the Section OAM is, IMHO, just the top of an iceb=
> erg). But such a restriction must be explicit, it cannot be left at the lev=
> el of "Don't worry, nobody will ever do such a thing". Because somebody wil=
> l do it.

Somebody already has.

> As you pointed out, running MPLS-TP over mp2mp media is going to defeat MPL=
> S-TP traffic engineering so I doubt this will be really used in properly TE=
>  networks.
>  
>  
>  
> What is the problem to restrict MPLS-TP Section OAM to only p2p and p2mp me=
> dia?
>  
>  
>  
> Thanks, Italo
>  
>  
> P.S. Please note my new email address, [email-masked], effec=
> tive since 1 November 2009.
>  
>  
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf =
> Of Maarten Vissers
> Sent: gioved=EC 8 aprile 2010 8.49
> I have a serious doubt if a mp2mp physical LAN will be applied in MPLS-TP n=
> etworks.
> 1000BASSE-X, 10GBASE-R, 40GBASE-R and 100GBASE-R physical interfaces do not=
>  support such mp2mp LAN.
> Only 100BASE-T ports would support it, but will such FE ports be used in a =
> mp2mp configuration?
> Separate of the above question on supporting other then p2p media in MPLS-T=
> P, I would like to comment on the following consideration of you:
>  
> >  =93Section OAM=94 uses GAL as the top (and only) label in the label stac=
> k. To me this means that an
> > MPLS-TP node that receives a Section OAM packet from a LAN interface cann=
> ot identify the
> > originating adjacent node based on the interface and received label stack=
> > Of course the only LAN interfaces worth mentioning are Ethernet ones, and=
>  the receiving node can
> > look at the source MAC address of the received packet, but this looks to =
> If one would use a mp2mp media to carry an MPLS-TP section layer signal ove=
> r, then the MPLS-TP section layer transport path may still be a p2p transpo=
> rt path. For this case the Ethernet to MPLS-TP adaptation will insert a uni=
> cast destination address on all the MPLS-TP packets. The receiving Ethernet=
>  to MPLS-TP adaptation function will accept only ethernet frames with one s=
> pecific source address. Result is to the receiving port (adaptation functio=
> n) will only pass through MPLS-TP packets from one of the input ports on th=
> e mp2mp medium. This is not a layer violation as you suggest, it is a norma=
> l, required operation in the adaptation function.
> If one would use a mp2mp medium to support a full mesh of p2p section layer=
>  transport paths between n ports on that medium, then  the Ethernet to MPLS=
> -TP adaptation will have n-1 input/output ports connected with n-1 MPLS-TP =
> Section MEP functions. The MPLS-TP packets from each MEP will be prepended =
> by the ethernet header, including a unicast destination address.
>  
> As in this case multiple MPLS-TP section (layer transport path) instances (=
> SIs) are multiplexed into one server layer signal, it is necessary to have =
> a MPLS-TP SI identifier. As long as there is only one section layer transpo=
> rt path instance between any two ports on the n-port medium it is possible =
> and correct to use the source address as SI demultiplexer; section-LSP labe=
> l is <da,sa>.
>  
> If there would be a need to carry multiple section instances between two po=
> rts on this n-port medium it will be necessary to add an additional SI iden=
> tifier as the <da,sa> demultiplexer is not longer unique. This additional S=
> I identifier could be a label in an additional section LSP label stack entr=
> y header, or could be a VLAN ID in a VLAN Tag. If you use the latter you wo=
> uld have a PBB-TE ESP like label <section-lsp-da,section-lsp-sa,section-lsp=
> -vid> (instead of <esp-da,esp-sa,esp-vid>). If you would use the former you=
>  could use a 'per medium label space', or a 'per interface port label space=
> '.
> Alternatively it is possible to replace the MPLS-TP Section layer by an Eth=
> ernet Section layer and use Ethernet OAM to check the connectivity between =
> the n-ports.
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf =
> Of Alexander Vainshtein
> Please note that the ACH TLV (regardless of how difficult or how simple is =
> its processing) does not provide the data plane identification of the sourc=
> e node of the received packet. In the case of LSP OAM, the received label s=
> tack and ingress interface provide that.
>  
> In other words, the concept of treating (data link) Sections as "label-less=
>  LSPs" does not hold water: label stack of depth 0 cannot identify anything=
> . It remains to be seen, to which extent this hole affects the MPLS-TP arch=
> itecture.
>  
> As for references to Y.1731, please note that its OAM packets are not reall=
> y fate-sharing with the user traffic (link trace is a well-known example). =
> MPLS-TP has been trying to improve that: this is why its MIPs are based on =
> At the same time, identifying MEPs and MIPs by their MAC addresses (inserte=
> d as source MAC addresses in the OAM packets) is perfectly valid in Etherne=
> t - but, IMO, not in MPLS-TP.
>  
> My 2c,
>      Sasha
>  
> I didn't say that it is "lightweight" ;) I just point that whether we go wi=
> th BFD or Y.1731 we have additional ID(s) carried as ACH TLV. I believe tha=
> t input from vendors like Broadcom can help us compare two approaches in re=
> gard of their relative friendliness towards HW for OAM in MPLS-TP. Since pr=
> o-active CV/CC as well as PM rely on HW related scenarios can be explored c=
> omparing efficiency of each approach.
>  
> Regards,
> Greg
>  
> On Wed, Apr 7, 2010 at 2:21 PM, Shahram Davari <[email-masked]<mailto:=
> [email-masked]>> wrote:
> Hi Greg,
>  
> I have to agree with Sasha. The TLV solution is not attractive because TLVs=
>  are not HW friendly and this means HW can=92t process them. Also it still =
> doesn=92t solve the problem of binding a BFD packet to its associated LSP.
>  
> Regards,
> Shahram
>  
> From: [email-masked]<mailto:[email-masked]> [mailto:mpl=
> [email-masked]<mailto:[email-masked]>] On Behalf Of Greg M=
> irsky
> Cc: [email-masked]<mailto:[email-masked]>; mp=
> [email-masked]<mailto:[email-masked]>
> I think that your concern can be addressed by ID(s) carried as ACH TLV. The=
>  Proactive CV/CC for MPLS-TP in Figure 3 suggests that a MEP-ID that unique=
> ly identifies source of the BFP packet precedes the BFD Control packet. I t=
> hink that using MPLS-TP ID in ACH TLVs would be common case for MPLS-TP OAM=
> .
>  
> Regards,
> Greg
> On Wed, Apr 7, 2010 at 1:21 PM, Alexander Vainshtein <Alexander.Vainshtein@=
> ecitele.com<mailto:[email-masked]>> wrote:
> Hi,
> I=92d like to share with the list and, specifically, with the authors of th=
> e MPLS-TP Framework and MPLS-TP OAM Framework drafts my serious doubts rega=
> rding using the so-called =93Section OAM=94 on Sections represented by LAN =
> (MP2MP) interfaces. To the best of my understanding, such interfaces are al=
> lowed (or, at least, not prohibited) in MPLS-TP.
>  
> To the best of my understanding, LSP OAM packet insert GAL in the label sta=
> ck immediately after the last label defining this LSP. Since MPLS-TP does n=
> ot allow MP2P LSP (no merge), the label stack above GAL can be used by the =
> node that receives an LSP OAM packet as data plane identification of the LS=
> P to which this OAM packet belongs. This behavior is well known in MPLS, e.=
> g., see  Section 4.4 =93Receiving MPLS Echo Request=94 of RFC 4379 (both th=
> e interface and received label stack of the received LSP-Ping packet are st=
> ored as part of processing).
>  
> =93Section OAM=94 uses GAL as the top (and only) label in the label stack. =
> To me this means that an MPLS-TP node that receives a Section OAM packet fr=
> om a LAN interface cannot identify the originating adjacent node based on t=
> he interface and received label stack (there is only one GAL!).
>  
> Of course the only LAN interfaces worth mentioning are Ethernet ones, and t=
> he receiving node can look at the source MAC address of the received packet=
> , but this looks to me like a serious layer violation.
>  
> These notes  have been triggered by the resent thread on Section service in=
> itiated by Maarten.
>  
> --_000_A3C5DF08D38B6049839A6F553B331C76C1080D0065ILPTMAIL02eci_
> Content-Type: text/html; charset="Windows-1252"
> Content-Transfer-Encoding: quoted-printable
>  
> <html dir=3D"ltr"><head>
> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
> 252">
> <style id=3D"owaTempEditStyle"></style><style title=3D"owaParaStyle"><!--P =
> {
> 	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
> }
> --></style>
> <meta content=3D"MSHTML 6.00.6000.17023" name=3D"GENERATOR">
> </head>
> <body ocsi=3D"x">
> <div style=3D"FONT-SIZE: 16px; COLOR: #000000; DIRECTION: ltr; FONT-FAMILY:=
>  Times New Roman">
> <div dir=3D"ltr"><font face=3D"Times New Roman" color=3D"#000000" size=3D"3=
> "><a></a><font face=3D"Times New Roman" color=3D"#000000" size=3D"3">Italo<=
> a></a></font>,</font></div>
> <div dir=3D"ltr"><font face=3D"times new roman">Lots of thanks for the inpu=
> t.</font></div>
> <div dir=3D"ltr"><font face=3D"times new roman"></font>&nbsp;</div>
> <div dir=3D"ltr"><font face=3D"times new roman">One minor point: I do not t=
> hink that p2mp media exists. It is either p2p or mp2mp.</font></div>
> <div dir=3D"ltr"><font face=3D"times new roman"></font>&nbsp;</div>
> <div dir=3D"ltr"><font face=3D"times new roman">Regarding restrictions: </f=
> ont></div>
> <div dir=3D"ltr"><font face=3D"times new roman"></font>&nbsp;</div>
> <div dir=3D"ltr"><font face=3D"times new roman">If we restrict MPLS-TP to P=
> 2P media, many technical issues will become non-relevant (my example with t=
> he Section OAM is, IMHO, just the top of an iceberg). But such a&nbsp;restr=
> iction<a></a> must be explicit, it cannot
>  be left at the level of &quot;Don't worry, nobody will ever do such a thin=
> g&quot;. Because somebody will do it.</font></div>
> <div dir=3D"ltr"><font face=3D"times new roman"></font>&nbsp;</div>
> <div dir=3D"ltr"><font face=3D"times new roman">My 2c,</font></div>
> <div dir=3D"ltr"><font face=3D"times new roman">&nbsp;&nbsp;&nbsp;&nbsp; Sa=
> sha</font></div>
> <div dir=3D"ltr"><font face=3D"times new roman"></font>&nbsp;</div>
> <div id=3D"divRpF99395" style=3D"DIRECTION: ltr">
> <hr tabindex=3D"-1">
> <font face=3D"Tahoma" color=3D"#000000" size=3D"2"><b>From:</b> BUSI ITALO =
> [[email-masked]]<br>
> <b>Sent:</b> Friday, April 09, 2010 10:11 AM<br>
> <b>To:</b> Maarten Vissers; Alexander Vainshtein<br>
> <b>Cc:</b> [email-masked]<br>
> <b>Subject:</b> RE: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interf=
> aces?<br>
> </font><br>
> </div>
> <div></div>
> <div>
> <div dir=3D"ltr" align=3D"left"><font color=3D"#0000ff"><span lang=3D"EN">
> <p><font face=3D"Arial" size=3D"2">&gt; But once again, is mp2mp media in M=
> PLS-TP really used?</font></p>
> <p><font face=3D"Arial" size=3D"2"></font>&nbsp;</p>
> <p><span class=3D"398193720-08042010"><font face=3D"Arial" color=3D"#000000=
> " size=3D"2">Good question.</font></span></p>
> <p><span class=3D"398193720-08042010"><font face=3D"Arial" color=3D"#000000=
> " size=3D"2"></font></span>&nbsp;</p>
> <p><span class=3D"398193720-08042010"><font face=3D"Arial" color=3D"#000000=
> " size=3D"2">As you pointed out, running MPLS-TP over mp2mp media is going =
> to defeat MPLS-TP traffic engineering so I doubt this will be really used i=
> n properly TE networks.</font></span></p>
> <p><span class=3D"398193720-08042010"><font face=3D"Arial" color=3D"#000000=
> " size=3D"2"></font></span>&nbsp;</p>
> <p><span class=3D"398193720-08042010"><font face=3D"Arial" color=3D"#000000=
> " size=3D"2">However, Sasha is right in claiming that this is not precluded=
> .</font></span></p>
> <p><span class=3D"398193720-08042010"><font face=3D"Arial" color=3D"#000000=
> " size=3D"2"></font></span>&nbsp;</p>
> <p><span class=3D"398193720-08042010"><font face=3D"Arial" color=3D"#000000=
> " size=3D"2">What is the problem to restrict MPLS-TP Section OAM to only p2=
> p and p2mp media?</font></span></p>
> <p><span class=3D"398193720-08042010"><font face=3D"Arial" color=3D"#000000=
> " size=3D"2"></font></span>&nbsp;</p>
> <p><span class=3D"398193720-08042010"><font face=3D"Arial" color=3D"#000000=
> " size=3D"2">Thanks, Italo</font></span></span></font></p>
> </div>
> <br>
> <p><font size=3D"2">P.S. Please note my new email address, Italo.Busi@alcat=
> el-lucent.com, effective since 1 November 2009.<br>
> </font></p>
> <div>&nbsp;</div>
> <br>
> <blockquote dir=3D"ltr" style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDE=
> R-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
> <div class=3D"OutlookMessageHeader" lang=3D"en-us" dir=3D"ltr" align=3D"lef=
> t">
> <hr tabindex=3D"-1">
> <font face=3D"Tahoma" size=3D"2"><b>From:</b> [email-masked] [mai=
> lto:[email-masked]]
> <b>On Behalf Of </b>Maarten Vissers<br>
> <b>Sent:</b> gioved=EC 8 aprile 2010 8.49<br>
> <b>To:</b> 'Alexander Vainshtein'<br>
> <b>Cc:</b> [email-masked]<br>
> <b>Subject:</b> Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interf=
> aces?<br>
> </font><br>
> </div>
> <div></div>
> <div dir=3D"ltr" align=3D"left"><span class=3D"203460606-08042010"><font fa=
> ce=3D"Arial" color=3D"#0000ff" size=3D"2">Sasha,</font></span></div>
> <div dir=3D"ltr" align=3D"left"><span class=3D"203460606-08042010"><font fa=
> ce=3D"Arial" color=3D"#0000ff" size=3D"2"></font></span>&nbsp;</div>
> <div dir=3D"ltr" align=3D"left"><span class=3D"203460606-08042010"><font fa=
> ce=3D"Arial" color=3D"#0000ff" size=3D"2">I have a serious doubt if a mp2mp=
>  physical&nbsp;LAN will be applied in MPLS-TP networks.
> </font></span></div>
> <div dir=3D"ltr" align=3D"left"><span class=3D"203460606-08042010"><font fa=
> ce=3D"Arial" color=3D"#0000ff" size=3D"2">1000BASSE-X, 10GBASE-R, 40GBASE-R=
>  and 100GBASE-R physical interfaces&nbsp;do not support such mp2mp LAN.</fo=
> nt></span></div>
> <div dir=3D"ltr" align=3D"left"><span class=3D"203460606-08042010"><font fa=
> ce=3D"Arial" color=3D"#0000ff" size=3D"2">Only 100BASE-T ports would suppor=
> t it, but will such FE ports be used in a mp2mp configuration?</font></span=
> ></div>
> <div dir=3D"ltr" align=3D"left"><span class=3D"203460606-08042010"><font fa=
> ce=3D"Arial" color=3D"#0000ff" size=3D"2">Traffic engineering gets complex =
> if we use mp2mp media.</font></span></div>
> <div dir=3D"ltr" align=3D"left"><span class=3D"203460606-08042010"><font fa=
> ce=3D"Arial" color=3D"#0000ff" size=3D"2"></font></span>&nbsp;</div>
> <div dir=3D"ltr" align=3D"left"><span class=3D"203460606-08042010"><font fa=
> ce=3D"Arial" color=3D"#0000ff" size=3D"2">Separate of the above question on=
>  supporting other then p2p media in MPLS-TP, I would like to comment on the=
>  following consideration of you:</font></span></div>
> <div dir=3D"ltr" align=3D"left"><span class=3D"203460606-08042010"><font fa=
> ce=3D"Arial" color=3D"#0000ff" size=3D"2"></font></span>&nbsp;</div>
> <div dir=3D"ltr" align=3D"left"><span class=3D"203460606-08042010"><font fa=
> ce=3D"Arial" color=3D"#0000ff" size=3D"2">&gt;&nbsp; =93Section OAM=94 uses=
>  GAL as the top (and only) label in the label stack. To me this means that =
> an</font></span></div>
> <div dir=3D"ltr" align=3D"left"><span class=3D"203460606-08042010"><font fa=
> ce=3D"Arial" color=3D"#0000ff" size=3D"2">&gt;&nbsp;MPLS-TP node that recei=
> ves a Section OAM packet from a LAN interface cannot identify the</font></s=
> pan></div>
> <div dir=3D"ltr" align=3D"left"><span class=3D"203460606-08042010"><font fa=
> ce=3D"Arial" color=3D"#0000ff" size=3D"2">&gt;&nbsp;originating adjacent no=
> de based on the interface and received label stack (there is only one GAL!)=
> .</font></span></div>
> <div dir=3D"ltr" align=3D"left"><span class=3D"203460606-08042010"><font fa=
> ce=3D"Arial" color=3D"#0000ff" size=3D"2">&gt;</font></div>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><span class=3D"203460606-=
> 08042010"><font face=3D"Arial" color=3D"#0000ff" size=3D"2">&gt;
> </font></span><font face=3D"Arial" color=3D"#0000ff" size=3D"2">Of course t=
> he only LAN interfaces worth mentioning are Ethernet ones, and the receivin=
> g node can</font></p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial"><fon=
> t color=3D"#0000ff"><font size=3D"2"><span class=3D"203460606-08042010">&gt=
> ;</span>&nbsp;look at the source MAC address of the received packet, but th=
> is looks to me like a serious layer violation.</font></font></font></p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"></font>&nbsp;</p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010">If one would us=
> e a mp2mp media to carry an MPLS-TP section layer signal over, then the MPL=
> S-TP section layer transport path may still be
>  a p2p transport path. </span></font><font face=3D"Arial" color=3D"#0000ff"=
>  size=3D"2"><span class=3D"203460606-08042010">For this case the Ethernet t=
> o MPLS-TP adaptation will insert a unicast destination address on all the M=
> PLS-TP packets.
> </span></font><font face=3D"Arial" color=3D"#0000ff" size=3D"2"><span class=
> =3D"203460606-08042010">The receiving Ethernet to MPLS-TP adaptation functi=
> on will accept only ethernet frames with one specific source address.
> </span></font><font face=3D"Arial" color=3D"#0000ff" size=3D"2"><span class=
> =3D"203460606-08042010">Result is to the receiving port (adaptation functio=
> n) will only pass through MPLS-TP packets from one of the input ports on th=
> e mp2mp medium. This is not a layer violation
>  as you suggest, it is a normal, required operation in the adaptation funct=
> ion.</span></font></p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010">By using&nbsp;M=
> PLS-TP section-CC/CV OAM, necessary connectivity can be verified.</span></f=
> ont></p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010"></span></font>&=
> nbsp;</p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010">If one would us=
> e a mp2mp medium to support a full mesh of p2p section layer transport path=
> s between n ports on that medium, then&nbsp; the Ethernet
>  to MPLS-TP adaptation will have n-1 input/output ports connected with n-1 =
> MPLS-TP Section MEP functions. The MPLS-TP packets from each MEP will be pr=
> epended by the ethernet header, including a unicast destination address.
> </span></font></p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010"></span></font>&=
> nbsp;</p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010"></span></font><=
> font face=3D"Arial" color=3D"#0000ff" size=3D"2"><span class=3D"203460606-0=
> 8042010">As in this case multiple MPLS-TP section (layer
>  transport path) instances (SIs) are multiplexed into one server layer sign=
> al,&nbsp;it is necessary to have a MPLS-TP SI identifier. As long as there =
> is only one section layer transport path instance between any two ports on =
> the n-port medium it is possible and
>  correct to use the source address as SI demultiplexer; section-LSP label i=
> s &lt;da,sa&gt;.
> </span></font></p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010"></span></font>&=
> nbsp;</p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010">If there would =
> be a need to carry multiple section instances between two ports on this n-p=
> ort medium it will be necessary to add an additional&nbsp;SI
>  identifier as the &lt;da,sa&gt; demultiplexer is not longer unique. This a=
> dditional SI identifier&nbsp;could be a label in an additional&nbsp;section=
>  LSP label stack entry header, or could be a&nbsp;VLAN ID&nbsp;in a VLAN Ta=
> g. If you use the latter you would have a PBB-TE ESP like
>  label &lt;section-lsp-da,section-lsp-sa,section-lsp-vid&gt; (instead of &l=
> t;esp-da,esp-sa,esp-vid&gt;). If you would use the former you could use a '=
> per medium label space', or a 'per interface port label space'.</span></fon=
> t></p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010">by using MPLS-T=
> P section-CC/CV OAM, necessary connectivity can be verified.</span></font><=
> /p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010"></span></font>&=
> nbsp;</p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010">Alternatively i=
> t is possible to replace the MPLS-TP Section layer by an Ethernet Section l=
> ayer and use Ethernet OAM to check the connectivity
>  between the n-ports.</span></font></p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010"></span></font>&=
> nbsp;</p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010">But once again,=
>  is mp2mp media in MPLS-TP really used?</span></font></p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010"></span></font>&=
> nbsp;</p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010">Regards,</span>=
> </font></p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" colo=
> r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010">Maarten</span><=
> /font></p>
> </span><br>
> <div class=3D"OutlookMessageHeader" lang=3D"en-us" dir=3D"ltr" align=3D"lef=
> t">
> <hr tabindex=3D"-1">
> <font face=3D"Tahoma" size=3D"2"><b>From:</b> [email-masked] [mai=
> lto:[email-masked]]
> <b>On Behalf Of </b>Alexander Vainshtein<br>
> <b>Sent:</b> donderdag 8 april 2010 7:49<br>
> <b>To:</b> Greg Mirsky; Shahram Davari<br>
> <b>Cc:</b> [email-masked]; [email-masked]<br>
> <b>Subject:</b> Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interf=
> aces?<br>
> </font><br>
> </div>
> <div></div>
> <div style=3D"FONT-SIZE: 16px; COLOR: #000000; DIRECTION: ltr; FONT-FAMILY:=
>  Times New Roman">
> <div></div>
> <div dir=3D"ltr"><font face=3D"Times New Roman" color=3D"#000000" size=3D"3=
> ">Greg,&nbsp;Shahram<a></a><a></a> and all,</font></div>
> <div dir=3D"ltr"><font face=3D"times new roman">Please note that the ACH TL=
> V (regardless of how&nbsp;difficult<a></a> or how&nbsp;simple<a></a> is its=
>  processing<a></a>) does not provide the
> <em>data plane</em> identification of the source node of the&nbsp;received =
> packet. In the case of LSP OAM, the received label stack and&nbsp;ingress<a=
> ></a> interface provide that.</font></div>
> <div dir=3D"ltr"><font face=3D"times new roman"></font>&nbsp;</div>
> <div dir=3D"ltr"><font face=3D"times new roman">In other words, the concept=
>  of treating (data link) Sections as &quot;label-less LSPs&quot; does not h=
> old water: label stack of depth 0 cannot identify anything. It remains to b=
> e seen, to which extent this hole affects the
>  MPLS-TP architecture.</font></div>
> <div dir=3D"ltr"><font face=3D"times new roman"></font>&nbsp;</div>
> <div dir=3D"ltr"><font face=3D"times new roman">As for references to Y.1731=
> , please note that its OAM packets are not really fate-sharing with the use=
> r traffic (link trace is a well-known example). MPLS-TP has been trying to =
> improve that<a></a>: this is why its
>  MIPs are based on TTL processing and not on, say, usage of Router Alert la=
> bel.</font></div>
> <div dir=3D"ltr"><font face=3D"times new roman"></font>&nbsp;</div>
> <div dir=3D"ltr"><font face=3D"times new roman">At the same time, identifyi=
> ng MEPs and MIPs by their MAC addresses (inserted&nbsp;as source<a></a> MAC=
> &nbsp;addresses<a></a> in the OAM packets) is perfectly valid in Ethernet -=
>  but, IMO, not in MPLS-TP.</font></div>
> <div dir=3D"ltr"><font face=3D"times new roman"></font>&nbsp;</div>
> <div dir=3D"ltr"><font face=3D"times new roman">My 2c,</font></div>
> <div dir=3D"ltr"><font face=3D"times new roman">&nbsp;&nbsp;&nbsp;&nbsp; Sa=
> sha</font></div>
> <div dir=3D"ltr"><font face=3D"times new roman"></font>&nbsp;</div>
> <div id=3D"divRpF69836" style=3D"DIRECTION: ltr">
> <hr tabindex=3D"-1">
> <font face=3D"Tahoma" color=3D"#000000" size=3D"2"><b>From:</b> Greg Mirsky=
>  [[email-masked]]<br>
> <b>Sent:</b> Thursday, April 08, 2010 12:33 AM<br>
> <b>To:</b> Shahram Davari<br>
> <b>Cc:</b> Alexander Vainshtein; [email-masked]; mpls-tp@iet=
> f.org<br>
> <b>Subject:</b> Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interf=
> aces?<br>
> </font><br>
> </div>
> <div></div>
> <div>Dear Shahram,<br>
> I didn't say that it is &quot;lightweight&quot; ;) I just point that whethe=
> r we go with BFD or Y.1731 we have additional ID(s) carried as ACH TLV. I b=
> elieve that input from vendors like Broadcom can help us compare two approa=
> ches in regard of their relative friendliness
>  towards HW for OAM in MPLS-TP. Since pro-active CV/CC as well as PM rely o=
> n HW related scenarios can be explored comparing efficiency of each approac=
> h.<br>
> <br>
> Regards,<br>
> Greg<br>
> <br>
> <div class=3D"gmail_quote">On Wed, Apr 7, 2010 at 2:21 PM, Shahram Davari <=
> span dir=3D"ltr">
> &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</spa=
> n> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0=
> pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
> <div lang=3D"EN-US">
> <div>
> <p class=3D"MsoNormal"><span style=3D"FONT-SIZE: 11pt; COLOR: rgb(31,73,125=
> )">Hi Greg,</span></p>
> <p class=3D"MsoNormal"><span style=3D"FONT-SIZE: 11pt; COLOR: rgb(31,73,125=
> )"></span>&nbsp;</p>
> <p class=3D"MsoNormal"><span style=3D"FONT-SIZE: 11pt; COLOR: rgb(31,73,125=
> )">I have to agree with Sasha. The TLV solution is not attractive because T=
> LVs are not HW friendly and this means HW can=92t process them. Also it sti=
> ll doesn=92t solve the problem of binding
>  a BFD packet to its associated LSP.</span></p>
> <p class=3D"MsoNormal"><span style=3D"FONT-SIZE: 11pt; COLOR: rgb(31,73,125=
> )"></span>&nbsp;</p>
> <p class=3D"MsoNormal"><span style=3D"FONT-SIZE: 11pt; COLOR: rgb(31,73,125=
> )">Regards,</span></p>
> <p class=3D"MsoNormal"><span style=3D"FONT-SIZE: 11pt; COLOR: rgb(31,73,125=
> )">Shahram</span></p>
> <p class=3D"MsoNormal"><span style=3D"FONT-SIZE: 11pt; COLOR: rgb(31,73,125=
> )"></span>&nbsp;</p>
> <div style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: 1p=
> t solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; =
> PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
> <p class=3D"MsoNormal"><b><span style=3D"FONT-SIZE: 10pt">From:</span></b><=
> span style=3D"FONT-SIZE: 10pt">
> <a href=3D"mailto:[email-masked]">[email-masked]</a> [m=
> ailto:<a href=3D"mailto:[email-masked]">[email-masked]<=
> /a>]
> <b>On Behalf Of </b>Greg Mirsky<br>
> <b>Sent:</b> Wednesday, April 07, 2010 2:15 PM<br>
> <b>To:</b> Alexander Vainshtein<br>
> <b>Cc:</b> <a href=3D"mailto:[email-masked]">Italo.Busi@alca=
> tel-lucent.com</a>;
> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <b>Subject:</b> Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interf=
> aces?</span></p>
> </div>
> <div>
> <div></div>
> <div class=3D"h5">
> <p class=3D"MsoNormal">&nbsp;</p>
> <p class=3D"MsoNormal" style=3D"MARGIN-BOTTOM: 12pt">Dear Alexander,<br>
> I think that your concern can be addressed by ID(s) carried as ACH TLV. The=
>  Proactive CV/CC for MPLS-TP in Figure 3 suggests that a MEP-ID that unique=
> ly identifies source of the BFP packet precedes the BFD Control packet. I t=
> hink that using MPLS-TP ID in ACH
>  TLVs would be common case for MPLS-TP OAM.<br>
> <br>
> Regards,<br>
> Greg</p>
> <div>
> <p class=3D"MsoNormal">On Wed, Apr 7, 2010 at 1:21 PM, Alexander Vainshtein=
>  &lt;<a href=3D"mailto:[email-masked]">Alexander.Vainshte=
> [email-masked]</a>&gt; wrote:</p>
> <div>
> <div>
> <p class=3D"MsoNormal">Hi,</p>
> <p class=3D"MsoNormal">I=92d like to share with the list and, specifically,=
>  with the authors of the MPLS-TP Framework and MPLS-TP OAM Framework drafts=
>  my serious doubts regarding using the so-called =93Section OAM=94 on Secti=
> ons represented by LAN (MP2MP) interfaces.
>  To the best of my understanding, such interfaces are allowed (or, at least=
> , not prohibited) in MPLS-TP.</p>
> <p class=3D"MsoNormal">&nbsp;</p>
> <p class=3D"MsoNormal">To the best of my understanding, LSP OAM packet inse=
> rt GAL in the label stack immediately after the last label defining this LS=
> P. Since MPLS-TP does not allow MP2P LSP (no merge), the label stack above =
> GAL can be used by the node that receives
>  an LSP OAM packet as data plane identification of the LSP to which this OA=
> M packet belongs. This behavior is well known in MPLS, e.g., see &nbsp;Sect=
> ion 4.4 =93Receiving MPLS Echo Request=94 of RFC 4379 (both the interface a=
> nd received label stack of the received LSP-Ping
>  packet are stored as part of processing).</p>
> <p class=3D"MsoNormal">&nbsp;</p>
> <p class=3D"MsoNormal">=93Section OAM=94 uses GAL as the top (and only) lab=
> el in the label stack. To me this means that an MPLS-TP node that receives =
> a Section OAM packet from a LAN interface cannot identify the originating a=
> djacent node based on the interface and
>  received label stack (there is only one GAL!).</p>
> <p class=3D"MsoNormal">&nbsp;</p>
> <p class=3D"MsoNormal">Of course the only LAN interfaces worth mentioning a=
> re Ethernet ones, and the receiving node can look at the source MAC address=
>  of the received packet, but this looks to me like a serious layer violatio=
> n.</p>
> <p class=3D"MsoNormal">&nbsp;</p>
> <p class=3D"MsoNormal">These notes &nbsp;have been triggered by the resent =
> thread on Section service initiated by Maarten.
> </p>
> <p class=3D"MsoNormal">&nbsp;</p>
> <p class=3D"MsoNormal">Did I miss something important?</p>
> <p class=3D"MsoNormal">&nbsp;</p>
> <p class=3D"MsoNormal">Regards,</p>
> <p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; Sasha</p>
> <p class=3D"MsoNormal">&nbsp;</p>
> </div>
> </div>
> <p class=3D"MsoNormal" style=3D"MARGIN-BOTTOM: 12pt"><br>
> _______________________________________________<br>
> mpls-tp mailing list<br>
> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls-tp" target=3D"_blank"=
> >https://www.ietf.org/mailman/listinfo/mpls-tp</a></p>
> </div>
> <p class=3D"MsoNormal">&nbsp;</p>
> </div>
> </div>
> </div>
> </div>
> </blockquote>
> </div>
> <br>
> </div>
> </div>
> </blockquote>
> </div>
> </div>
> </body>
> </html>
>  
> --_000_A3C5DF08D38B6049839A6F553B331C76C1080D0065ILPTMAIL02eci_--
>  
> --===============1344314766==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>  
> --===============1344314766==--
>

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 11 Apr 2010 01:08:14 -0400

In message <[email-masked]>
"BUSI ITALO" writes:
>  
>  
> Sasha,
> =20
> thanks for your reply.
> =20
> Regarding p2mp media, how would you consider a scenario where MPLS-TP is =
> running over p2mp SDH VC?
> =20
> I understood the rough consensus is not to preclude running MPLS-TP over =
> mp2mp media.
> =20
> If my understanding regarding the rough consensus is correct, I agree =
> with you that we need to document/resolve all the associated technical =
> issues.
> =20
> On my side, if would be fine to clearly state that MPLS-TP Section OAM =
> MUST NOT be used on mp2mp media.
> =20
> If my understanding regarding the rough consensus in incorrect, I agree =
> with you that we need to explicity document that MPLS-TP MUST NOT run =
> over mp2mp media.
> =20
> Italo
>  
>  
> P.S. Please note my new email address, [email-masked], =
> effective since 1 November 2009.

My read of the framework is that mp2mp is not forbidden but is out of
scope for MPLS-TP.  That puts it in the realm of possible future work.

Curtis

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 11 Apr 2010 10:00:02 +0300

Curtis,
Lots of thanks for an important input.

Could you possibly point to a specific part of the framework draft that suggests that mp2mp interfaces are out of scope of MPLS-TP?

My read of the data plane draft (e.g., the discussion of using well-known multicast address on Ethernet  links which is explicitly restricted to p2p) is that the alternative is in scope as well.

But, again, this is a personal impression, and IMO we need a clear resolution - one way or another. Because, as you've stated in your previous email, somebody already uses mp2mp media in MPLS-TP... Or did I read this wrong?

Regards,
     Sasha

________________________________________
From: [email-masked] [[email-masked]]
Sent: Sunday, April 11, 2010 8:08 AM
To: BUSI ITALO
Cc: Alexander Vainshtein; [email-masked]
Subject: Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 12 Apr 2010 11:47:26 +0200

Sasha, Italo,

I have changed the subject line as we seem to be addressing the types of
media over which MPLS-TP can be run.

I think that we have to be very explicit over which media we assume to run
MPLS-TP over. E.g.:
- p2p 802.3 LAN (10M, 100M, 1G, 10G, 40G, 100G)
- mp2mp 802.3 CSMA/CD LAN (10M, 100M)
- p2p VLAN
- p2mp VLAN
- rmp VLAN
- mp2mp VLAN
- p2p SDH VC-n
- p2mp SDH VC-n
- p2p OTN ODUk
- p2mp OTN ODUk

The VLANs, VC-n's and ODUk's can be used as Section layer signals replacing
the MPLS-TP Section layer signal, or can be carrying (as a physical media
layer signal) the MPLS-TP Section layer signal.

In the first case there is no MPLS-TP Section layer; instead the MPLS-TP
Transport Path layer signals are directly supported by a VLAN/VC-n/ODUk type
of Section layer.

In the second case there is a MPLS-TP Section layer on top of a
VLAN/VC-n/ODUk type of physical media layer.

Section 5 in the data plane draft could be extended with e.g. SDH and OTN
Media subsections 5.2 and 5.3 in which the detailed mapping specifications
are presented (e.g. MPLS-TP LSP and PW via GFP-F into VC-n and ODUk,
management and control plane information via MPLS-TP SCC/MCC) and the type
of VC-n and ODUk (p2p, p2mp) that are supported. In here it is then also
possible to specify what Section layer technology is used (MPLS-TP Section
or VC-n or ODUk type sections).

Section 5.1 could be extended with a list of LAN and VLAN types (see above)
that are supported as MPLS-TP media. In here it is then also possible to
specify what Section layer technology is used (MPLS-TP Section or Ethernet
VLAN type section), and how management and control plane information is
carried.

Regards,
Maarten
PS. Note that the VLANs, VC-n's and ODUk's may also be used as Transport
Path layer signals replacing the MPLS-TP Transport Path layer signal. I have
ignored that above.

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: zaterdag 10 april 2010 17:07
To: BUSI ITALO
Cc: [email-masked]; Maarten Vissers
Subject: RE: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Italo,

Your example for p2mp media looks valid. I must admit that I have never
considered it. I think that actually using such a media as an MPLS-TP
Section could be highly problematic, but this is another issue.

Regarding running MPLS-TP over mp2mp media: you may be quite right regarding
the rough (in both senses of the word!) consensus that it is allowed. But
IMO this point should be explicitly raised on the list because, as Maarten's
messages show, there are some people that vigorously object to it. 

Assuming that consensus supports MPLS-TP over mp2mp media: stating that
Section OAM MUST NOT be used on MP2MP media would resolve one specific
issue. 

My 2c,
     Sasha

Sasha,

thanks for your reply.

Regarding p2mp media, how would you consider a scenario where MPLS-TP is
running over p2mp SDH VC?

I understood the rough consensus is not to preclude running MPLS-TP over
mp2mp media.

If my understanding regarding the rough consensus is correct, I agree with
you that we need to document/resolve all the associated technical issues.

On my side, if would be fine to clearly state that MPLS-TP Section OAM MUST
NOT be used on mp2mp media.

If my understanding regarding the rough consensus in incorrect, I agree with
you that we need to explicity document that MPLS-TP MUST NOT run over mp2mp
media.

Italo

P.S. Please note my new email address, [email-masked],
effective since 1 November 2009.

Italo,

One minor point: I do not think that p2mp media exists. It is either p2p or
mp2mp.

Regarding restrictions: 

If we restrict MPLS-TP to P2P media, many technical issues will become
non-relevant (my example with the Section OAM is, IMHO, just the top of an
iceberg). But such a restriction must be explicit, it cannot be left at the
level of "Don't worry, nobody will ever do such a thing". Because somebody
will do it.

My 2c,
     Sasha

Good question.

As you pointed out, running MPLS-TP over mp2mp media is going to defeat
MPLS-TP traffic engineering so I doubt this will be really used in properly
TE networks.

What is the problem to restrict MPLS-TP Section OAM to only p2p and p2mp
media?

Thanks, Italo

P.S. Please note my new email address, [email-masked],
effective since 1 November 2009.

Sasha,

me this means that an
cannot identify the
the receiving node can

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 12 Apr 2010 12:00:32 +0200

Curtis,

I agree with you that p2mp media exist (e.g. p2mp SDH VC-n) and is being
used for video distribution. I am involved in the development of p2mp OTN
ODUk solution (e.g. p2mp ODU0 carrying a 1GE signal with IPTV channels). I.e
I am aware of this without MPLS(-TP) in the stack; are you referring to
those cases or are you referring to cases with MPLS(-TP) included?

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Curtis Villamizar
Sent: zondag 11 april 2010 7:07
To: Alexander Vainshtein
Cc: BUSI ITALO; [email-masked]
Subject: Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

In message
<[email-masked]>

> non-= relevant (my example with the Section OAM is, IMHO, just the top 
> of an iceb= erg). But such a restriction must be explicit, it cannot 
> be left at the lev= el of "Don't worry, nobody will ever do such a 
> thing". Because somebody wil= l do it.

Somebody already has.

> As you pointed out, running MPLS-TP over mp2mp media is going to 
> defeat MPL= S-TP traffic engineering so I doubt this will be really 
> used in properly TE=  networks.
>  
>  
>  
> What is the problem to restrict MPLS-TP Section OAM to only p2p and 
> p2mp me= dia?
>  
>  
>  
> Thanks, Italo
>  
>  
> effec= tive since 1 November 2009.
>  
>  
>  
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf = Of Maarten Vissers
> I have a serious doubt if a mp2mp physical LAN will be applied in 
> MPLS-TP n= etworks.
> 1000BASSE-X, 10GBASE-R, 40GBASE-R and 100GBASE-R physical interfaces 
> do not=  support such mp2mp LAN.
> Only 100BASE-T ports would support it, but will such FE ports be used 
> in a = mp2mp configuration?
> MPLS-T= P, I would like to comment on the following consideration of you:
>  
> > cann=
> If one would use a mp2mp media to carry an MPLS-TP section layer 
> signal ove= r, then the MPLS-TP section layer transport path may still 
> be a p2p transpo= rt path. For this case the Ethernet to MPLS-TP 
> adaptation will insert a uni= cast destination address on all the 
> MPLS-TP packets. The receiving Ethernet=  to MPLS-TP adaptation 
> function will accept only ethernet frames with one s= pecific source 
> address. Result is to the receiving port (adaptation functio=
> n) will only pass through MPLS-TP packets from one of the input ports 
> on th= e mp2mp medium. This is not a layer violation as you suggest, 
> it is a norma= l, required operation in the adaptation function.
> If one would use a mp2mp medium to support a full mesh of p2p section 
> layer=  transport paths between n ports on that medium, then  the 
> Ethernet to MPLS= -TP adaptation will have n-1 input/output ports 
> connected with n-1 MPLS-TP = Section MEP functions. The MPLS-TP 
> packets from each MEP will be prepended = by the ethernet header,
including a unicast destination address.
> SIs) are multiplexed into one server layer signal, it is necessary to 
> have = a MPLS-TP SI identifier. As long as there is only one section 
> layer transpo= rt path instance between any two ports on the n-port 
> medium it is possible = and correct to use the source address as SI 
> demultiplexer; section-LSP labe= l is <da,sa>.
>  
> If there would be a need to carry multiple section instances between 
> two po= rts on this n-port medium it will be necessary to add an 
> additional SI iden= tifier as the <da,sa> demultiplexer is not longer 
> unique. This additional S= I identifier could be a label in an 
> additional section LSP label stack entr= y header, or could be a VLAN 
> ID in a VLAN Tag. If you use the latter you wo= uld have a PBB-TE ESP 
> like label <section-lsp-da,section-lsp-sa,section-lsp=
> -vid> (instead of <esp-da,esp-sa,esp-vid>). If you would use the 
> -vid> former you=
>  could use a 'per medium label space', or a 'per interface port label 
> space= '.
> Alternatively it is possible to replace the MPLS-TP Section layer by 
> an Eth= ernet Section layer and use Ethernet OAM to check the 
> connectivity between = the n-ports.
>  
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf = Of Alexander Vainshtein
> Please note that the ACH TLV (regardless of how difficult or how 
> simple is = its processing) does not provide the data plane 
> identification of the sourc= e node of the received packet. In the 
> case of LSP OAM, the received label s= tack and ingress interface provide
that.
>  
> In other words, the concept of treating (data link) Sections as 
> "label-less=  LSPs" does not hold water: label stack of depth 0 cannot 
> identify anything= . It remains to be seen, to which extent this hole 
> affects the MPLS-TP arch= itecture.
>  
> reall= y fate-sharing with the user traffic (link trace is a 
> well-known example). = MPLS-TP has been trying to improve that: this 
> is why its MIPs are based on = TTL processing and not on, say, usage of
Router Alert label.
>  
> At the same time, identifying MEPs and MIPs by their MAC addresses 
> (inserte= d as source MAC addresses in the OAM packets) is perfectly 
> valid in Etherne= t - but, IMO, not in MPLS-TP.
>  
> My 2c,
>      Sasha
>  
> I didn't say that it is "lightweight" ;) I just point that whether we 
> go wi= th BFD or Y.1731 we have additional ID(s) carried as ACH TLV. I 
> believe tha= t input from vendors like Broadcom can help us compare 
> two approaches in re= gard of their relative friendliness towards HW 
> for OAM in MPLS-TP. Since pr= o-active CV/CC as well as PM rely on HW 
> related scenarios can be explored c= omparing efficiency of each approach.
>  
> Regards,
> Greg
>  
> On Wed, Apr 7, 2010 at 2:21 PM, Shahram Davari 
> <[email-masked]<mailto:= [email-masked]>> wrote:
> Hi Greg,
>  
> I have to agree with Sasha. The TLV solution is not attractive because 
> TLVs=  are not HW friendly and this means HW can=92t process them. 
> Also it still = doesn=92t solve the problem of binding a BFD packet to its
associated LSP.
>  
> Regards,
> Shahram
>  
> From: [email-masked]<mailto:[email-masked]> 
> [mailto:mpl= [email-masked]<mailto:[email-masked]>] 
> On Behalf Of Greg M= irsky
> Cc: 
> [email-masked]<mailto:[email-masked]>; 
> mp= [email-masked]<mailto:[email-masked]>
> I think that your concern can be addressed by ID(s) carried as ACH 
> TLV. The=  Proactive CV/CC for MPLS-TP in Figure 3 suggests that a 
> MEP-ID that unique= ly identifies source of the BFP packet precedes 
> the BFD Control packet. I t= hink that using MPLS-TP ID in ACH TLVs 
> would be common case for MPLS-TP OAM= .
>  
> Regards,
> Greg
> <Alexander.Vainshtein@=
ecitele.com<mailto:[email-masked]>> wrote:
> Hi,
> I=92d like to share with the list and, specifically, with the authors 
> of th= e MPLS-TP Framework and MPLS-TP OAM Framework drafts my serious 
> doubts rega= rding using the so-called =93Section OAM=94 on Sections 
> represented by LAN =
> (MP2MP) interfaces. To the best of my understanding, such interfaces 
> are al= lowed (or, at least, not prohibited) in MPLS-TP.
>  
> To the best of my understanding, LSP OAM packet insert GAL in the 
> label sta= ck immediately after the last label defining this LSP. 
> Since MPLS-TP does n= ot allow MP2P LSP (no merge), the label stack 
> above GAL can be used by the = node that receives an LSP OAM packet as 
> data plane identification of the LS= P to which this OAM packet 
> belongs. This behavior is well known in MPLS, e.= g., see  Section 4.4 
> =93Receiving MPLS Echo Request=94 of RFC 4379 (both th= e interface 
> and received label stack of the received LSP-Ping packet are st= ored as
part of processing).
>  
> =93Section OAM=94 uses GAL as the top (and only) label in the label 
> stack. = To me this means that an MPLS-TP node that receives a Section 
> OAM packet fr= om a LAN interface cannot identify the originating 
> adjacent node based on t= he interface and received label stack (there is
only one GAL!).
>  
> Of course the only LAN interfaces worth mentioning are Ethernet ones, 
> and t= he receiving node can look at the source MAC address of the 
> received packet= , but this looks to me like a serious layer violation.
>  
> These notes  have been triggered by the resent thread on Section 
> service in= itiated by Maarten.
>  
> <meta http-equiv=3D"Content-Type" content=3D"text/html; 
> charset=3DWindows-1= 252"> <style 
> id=3D"owaTempEditStyle"></style><style title=3D"owaParaStyle"><!--P = 
> {
> <meta content=3D"MSHTML 6.00.6000.17023" name=3D"GENERATOR"> </head> 
> <body ocsi=3D"x"> <div style=3D"FONT-SIZE: 16px; COLOR: #000000; 
> DIRECTION: ltr; FONT-FAMILY:=  Times New Roman"> <div 
> dir=3D"ltr"><font face=3D"Times New Roman" color=3D"#000000" 
> size=3D"3= "><a></a><font face=3D"Times New Roman" color=3D"#000000" 
> size=3D"3">Italo<=
> <div dir=3D"ltr"><font face=3D"times new roman">Lots of thanks for the 
> inpu= t.</font></div> <div dir=3D"ltr"><font face=3D"times new 
> roman"></font>&nbsp;</div> <div dir=3D"ltr"><font face=3D"times new 
> roman">One minor point: I do not t= hink that p2mp media exists. It is 
> either p2p or mp2mp.</font></div> <div dir=3D"ltr"><font face=3D"times 
> new roman"></font>&nbsp;</div> <div dir=3D"ltr"><font face=3D"times 
> new roman">Regarding restrictions: </f=
> ont></div>
> <div dir=3D"ltr"><font face=3D"times new roman">If we restrict MPLS-TP 
> to P= 2P media, many technical issues will become non-relevant (my 
> example with t= he Section OAM is, IMHO, just the top of an iceberg). 
> But such a&nbsp;restr= iction<a></a> must be explicit, it cannot  be 
> left at the level of &quot;Don't worry, nobody will ever do such a 
> thin= g&quot;. Because somebody will do it.</font></div> <div 
> dir=3D"ltr"><font face=3D"times new roman"></font>&nbsp;</div> <div 
> dir=3D"ltr"><font face=3D"times new roman">My 2c,</font></div> <div 
> dir=3D"ltr"><font face=3D"times new roman">&nbsp;&nbsp;&nbsp;&nbsp; 
> Sa= sha</font></div> <div dir=3D"ltr"><font face=3D"times new 
> roman"></font>&nbsp;</div> <div id=3D"divRpF99395" style=3D"DIRECTION: 
> ltr"> <hr tabindex=3D"-1"> <font face=3D"Tahoma" color=3D"#000000" 
> size=3D"2"><b>From:</b> BUSI ITALO = 
> <b>Sent:</b> Friday, April 09, 2010 10:11 AM<br> <b>To:</b> Maarten 
> Vissers; Alexander Vainshtein<br> <b>Cc:</b> [email-masked]<br> 
> <b>Subject:</b> RE: [mpls-tp] Can MPLS-TP Section OAM be used on LAN 
> interf= aces?<br> </font><br> </div> <div></div> <div> <div 
> dir=3D"ltr" align=3D"left"><font color=3D"#0000ff"><span lang=3D"EN"> 
> <p><font face=3D"Arial" size=3D"2">&gt; But once again, is mp2mp media 
> in M= PLS-TP really used?</font></p> <p><font face=3D"Arial" 
> size=3D"2"></font>&nbsp;</p> <p><span 
> class=3D"398193720-08042010"><font face=3D"Arial" color=3D"#000000= " 
> size=3D"2">Good question.</font></span></p> <p><span 
> class=3D"398193720-08042010"><font face=3D"Arial" color=3D"#000000= " 
> size=3D"2"></font></span>&nbsp;</p>
> <p><span class=3D"398193720-08042010"><font face=3D"Arial" 
> color=3D"#000000= " size=3D"2">As you pointed out, running MPLS-TP 
> over mp2mp media is going = to defeat MPLS-TP traffic engineering so I 
> doubt this will be really used i= n properly TE 
> networks.</font></span></p> <p><span 
> class=3D"398193720-08042010"><font face=3D"Arial" color=3D"#000000= " 
> size=3D"2"></font></span>&nbsp;</p>
> <p><span class=3D"398193720-08042010"><font face=3D"Arial" 
> color=3D"#000000= " size=3D"2">However, Sasha is right in claiming 
> that this is not precluded= .</font></span></p> <p><span 
> class=3D"398193720-08042010"><font face=3D"Arial" color=3D"#000000= " 
> size=3D"2"></font></span>&nbsp;</p>
> <p><span class=3D"398193720-08042010"><font face=3D"Arial" 
> color=3D"#000000= " size=3D"2">What is the problem to restrict MPLS-TP 
> Section OAM to only p2= p and p2mp media?</font></span></p> <p><span 
> class=3D"398193720-08042010"><font face=3D"Arial" color=3D"#000000= " 
> size=3D"2"></font></span>&nbsp;</p>
> <p><span class=3D"398193720-08042010"><font face=3D"Arial" 
> color=3D"#000000= " size=3D"2">Thanks, 
> Italo</font></span></span></font></p>
> </div>
> <br>
> <p><font size=3D"2">P.S. Please note my new email address, 
> Italo.Busi@alcat= el-lucent.com, effective since 1 November 2009.<br> 
> </font></p> <div>&nbsp;</div> <br> <blockquote dir=3D"ltr" 
> style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDE=
> R-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"> <div 
> class=3D"OutlookMessageHeader" lang=3D"en-us" dir=3D"ltr" 
> align=3D"lef= t"> <hr tabindex=3D"-1"> <font face=3D"Tahoma" 
> size=3D"2"><b>From:</b> [email-masked] [mai= 
> lto:[email-masked]] <b>On Behalf Of </b>Maarten Vissers<br> 
> <b>Sent:</b> gioved=EC 8 aprile 2010 8.49<br> <b>To:</b> 'Alexander 
> Vainshtein'<br> <b>Cc:</b> [email-masked]<br> <b>Subject:</b> Re: 
> [mpls-tp] Can MPLS-TP Section OAM be used on LAN interf= aces?<br> 
> </font><br> </div> <div></div> <div dir=3D"ltr" align=3D"left"><span 
> class=3D"203460606-08042010"><font fa= ce=3D"Arial" color=3D"#0000ff" 
> size=3D"2">Sasha,</font></span></div>
> <div dir=3D"ltr" align=3D"left"><span 
> class=3D"203460606-08042010"><font fa= ce=3D"Arial" color=3D"#0000ff" 
> size=3D"2"></font></span>&nbsp;</div>
> <div dir=3D"ltr" align=3D"left"><span 
> class=3D"203460606-08042010"><font fa= ce=3D"Arial" color=3D"#0000ff" 
> size=3D"2">I have a serious doubt if a mp2mp=  physical&nbsp;LAN will be
applied in MPLS-TP networks.
> </font></span></div>
> <div dir=3D"ltr" align=3D"left"><span 
> class=3D"203460606-08042010"><font fa= ce=3D"Arial" color=3D"#0000ff" 
> size=3D"2">1000BASSE-X, 10GBASE-R, 40GBASE-R=  and 100GBASE-R physical 
> interfaces&nbsp;do not support such mp2mp LAN.</fo=
> nt></span></div>
> <div dir=3D"ltr" align=3D"left"><span 
> class=3D"203460606-08042010"><font fa= ce=3D"Arial" color=3D"#0000ff" 
> size=3D"2">Only 100BASE-T ports would suppor= t it, but will such FE 
> ports be used in a mp2mp configuration?</font></span=
> ></div>
> <div dir=3D"ltr" align=3D"left"><span 
> class=3D"203460606-08042010"><font fa= ce=3D"Arial" color=3D"#0000ff" 
> size=3D"2">Traffic engineering gets complex = if we use mp2mp 
> media.</font></span></div> <div dir=3D"ltr" align=3D"left"><span 
> class=3D"203460606-08042010"><font fa= ce=3D"Arial" color=3D"#0000ff" 
> size=3D"2"></font></span>&nbsp;</div>
> <div dir=3D"ltr" align=3D"left"><span 
> class=3D"203460606-08042010"><font fa= ce=3D"Arial" color=3D"#0000ff" 
> size=3D"2">Separate of the above question on=  supporting other then 
> p2p media in MPLS-TP, I would like to comment on the=  following 
> consideration of you:</font></span></div> <div dir=3D"ltr" 
> align=3D"left"><span class=3D"203460606-08042010"><font fa= 
> <div dir=3D"ltr" align=3D"left"><span 
> class=3D"203460606-08042010"><font fa= ce=3D"Arial" color=3D"#0000ff" 
> size=3D"2">&gt;&nbsp; =93Section OAM=94 uses=  GAL as the top (and 
> only) label in the label stack. To me this means that = 
> an</font></span></div> <div dir=3D"ltr" align=3D"left"><span 
> class=3D"203460606-08042010"><font fa= ce=3D"Arial" color=3D"#0000ff" 
> size=3D"2">&gt;&nbsp;MPLS-TP node that recei= ves a Section OAM packet 
> from a LAN interface cannot identify the</font></s=
> pan></div>
> <div dir=3D"ltr" align=3D"left"><span 
> class=3D"203460606-08042010"><font fa= ce=3D"Arial" color=3D"#0000ff" 
> size=3D"2">&gt;&nbsp;originating adjacent no= de based on the 
> interface and received label stack (there is only one GAL!)= 
> .</font></span></div> <div dir=3D"ltr" align=3D"left"><span 
> class=3D"203460606-08042010"><font fa= ce=3D"Arial" color=3D"#0000ff" 
> size=3D"2">&gt;</font></div> <p class=3D"MsoNormal" dir=3D"ltr" 
> align=3D"left"><span class=3D"203460606-= 08042010"><font 
> face=3D"Arial" color=3D"#0000ff" size=3D"2">&gt; </font></span><font 
> face=3D"Arial" color=3D"#0000ff" size=3D"2">Of course t= he only LAN 
> interfaces worth mentioning are Ethernet ones, and the receivin= g 
> node can</font></p> <p class=3D"MsoNormal" dir=3D"ltr" 
> align=3D"left"><font face=3D"Arial"><fon= t color=3D"#0000ff"><font 
> size=3D"2"><span class=3D"203460606-08042010">&gt= ;</span>&nbsp;look 
> at the source MAC address of the received packet, but th= is looks to 
> me like a serious layer violation.</font></font></font></p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" 
> colo= r=3D"#0000ff" size=3D"2"></font>&nbsp;</p> <p 
> class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" 
> colo= r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010">If 
> one would us= e a mp2mp media to carry an MPLS-TP section layer signal 
> over, then the MPL= S-TP section layer transport path may still be  a 
> p2p transport path. </span></font><font face=3D"Arial" 
> color=3D"#0000ff"=  size=3D"2"><span class=3D"203460606-08042010">For 
> this case the Ethernet t= o MPLS-TP adaptation will insert a unicast 
> destination address on all the M= PLS-TP packets.
> </span></font><font face=3D"Arial" color=3D"#0000ff" size=3D"2"><span 
> class= =3D"203460606-08042010">The receiving Ethernet to MPLS-TP 
> adaptation functi= on will accept only ethernet frames with one specific
source address.
> </span></font><font face=3D"Arial" color=3D"#0000ff" size=3D"2"><span 
> class= =3D"203460606-08042010">Result is to the receiving port 
> (adaptation functio=
> n) will only pass through MPLS-TP packets from one of the input ports 
> on th= e mp2mp medium. This is not a layer violation  as you suggest, 
> it is a normal, required operation in the adaptation funct= 
> ion.</span></font></p> <p class=3D"MsoNormal" dir=3D"ltr" 
> align=3D"left"><font face=3D"Arial" colo= r=3D"#0000ff" 
> size=3D"2"><span class=3D"203460606-08042010">By using&nbsp;M= PLS-TP 
> section-CC/CV OAM, necessary connectivity can be verified.</span></f=
> ont></p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" 
> colo= r=3D"#0000ff" size=3D"2"><span 
> class=3D"203460606-08042010"></span></font>&=
> nbsp;</p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" 
> colo= r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010">If 
> one would us= e a mp2mp medium to support a full mesh of p2p section 
> layer transport path= s between n ports on that medium, then&nbsp; the 
> Ethernet  to MPLS-TP adaptation will have n-1 input/output ports 
> connected with n-1 = MPLS-TP Section MEP functions. The MPLS-TP 
> packets from each MEP will be pr= epended by the ethernet header,
including a unicast destination address.
> </span></font></p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" 
> colo= r=3D"#0000ff" size=3D"2"><span 
> class=3D"203460606-08042010"></span></font>&=
> nbsp;</p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" 
> colo= r=3D"#0000ff" size=3D"2"><span 
> class=3D"203460606-08042010"></span></font><=
> font face=3D"Arial" color=3D"#0000ff" size=3D"2"><span 
> class=3D"203460606-0= 8042010">As in this case multiple MPLS-TP 
> section (layer  transport path) instances (SIs) are multiplexed into 
> one server layer sign= al,&nbsp;it is necessary to have a MPLS-TP SI 
> identifier. As long as there = is only one section layer transport 
> path instance between any two ports on = the n-port medium it is 
> section-LSP label i= s &lt;da,sa&gt;.
> </span></font></p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" 
> colo= r=3D"#0000ff" size=3D"2"><span 
> class=3D"203460606-08042010"></span></font>&=
> nbsp;</p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" 
> colo= r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010">If 
> there would = be a need to carry multiple section instances between 
> two ports on this n-p= ort medium it will be necessary to add an 
> additional&nbsp;SI  identifier as the &lt;da,sa&gt; demultiplexer is 
> not longer unique. This a= dditional SI identifier&nbsp;could be a 
> label in an additional&nbsp;section=  LSP label stack entry header, or 
> could be a&nbsp;VLAN ID&nbsp;in a VLAN Ta= g. If you use the latter 
> you would have a PBB-TE ESP like  label 
> &lt;section-lsp-da,section-lsp-sa,section-lsp-vid&gt; (instead of &l= 
> t;esp-da,esp-sa,esp-vid&gt;). If you would use the former you could 
> use a '= per medium label space', or a 'per interface port label 
> space'.</span></fon=
> t></p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" 
> colo= r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010">by 
> using MPLS-T= P section-CC/CV OAM, necessary connectivity can be 
> verified.</span></font><= /p> <p class=3D"MsoNormal" dir=3D"ltr" 
> align=3D"left"><font face=3D"Arial" colo= r=3D"#0000ff" 
> size=3D"2"><span class=3D"203460606-08042010"></span></font>&=
> nbsp;</p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" 
> colo= r=3D"#0000ff" size=3D"2"><span 
> class=3D"203460606-08042010">Alternatively i= t is possible to replace 
> the MPLS-TP Section layer by an Ethernet Section l= ayer and use 
> Ethernet OAM to check the connectivity  between the 
> n-ports.</span></font></p> <p class=3D"MsoNormal" dir=3D"ltr" 
> align=3D"left"><font face=3D"Arial" colo= r=3D"#0000ff" 
> size=3D"2"><span class=3D"203460606-08042010"></span></font>&=
> nbsp;</p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" 
> colo= r=3D"#0000ff" size=3D"2"><span class=3D"203460606-08042010">But 
> once again,=  is mp2mp media in MPLS-TP really used?</span></font></p> 
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" 
> colo= r=3D"#0000ff" size=3D"2"><span 
> class=3D"203460606-08042010"></span></font>&=
> nbsp;</p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" 
> colo= r=3D"#0000ff" size=3D"2"><span 
> class=3D"203460606-08042010">Regards,</span>=
> </font></p>
> <p class=3D"MsoNormal" dir=3D"ltr" align=3D"left"><font face=3D"Arial" 
> colo= r=3D"#0000ff" size=3D"2"><span 
> class=3D"203460606-08042010">Maarten</span><=
> /font></p>
> </span><br>
> <div class=3D"OutlookMessageHeader" lang=3D"en-us" dir=3D"ltr" 
> align=3D"lef= t"> <hr tabindex=3D"-1"> <font face=3D"Tahoma" 
> size=3D"2"><b>From:</b> [email-masked] [mai= 
> lto:[email-masked]] <b>On Behalf Of </b>Alexander 
> Vainshtein<br> <b>Sent:</b> donderdag 8 april 2010 7:49<br> <b>To:</b> 
> Greg Mirsky; Shahram Davari<br> <b>Cc:</b> 
> [email-masked]; [email-masked]<br> <b>Subject:</b> 
> Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interf= aces?<br> 
> </font><br> </div> <div></div> <div style=3D"FONT-SIZE: 16px; COLOR: 
> #000000; DIRECTION: ltr; FONT-FAMILY:=  Times New Roman"> <div></div> 
> <div dir=3D"ltr"><font face=3D"Times New Roman" color=3D"#000000" 
> size=3D"3= ">Greg,&nbsp;Shahram<a></a><a></a> and all,</font></div> 
> <div dir=3D"ltr"><font face=3D"times new roman">Please note that the 
> ACH TL= V (regardless of how&nbsp;difficult<a></a> or 
> how&nbsp;simple<a></a> is its=
>  processing<a></a>) does not provide the <em>data plane</em> 
> identification of the source node of the&nbsp;received = packet. In 
> the case of LSP OAM, the received label stack and&nbsp;ingress<a=
> <div dir=3D"ltr"><font face=3D"times new roman">In other words, the 
> concept=  of treating (data link) Sections as &quot;label-less 
> LSPs&quot; does not h= old water: label stack of depth 0 cannot 
> identify anything. It remains to b= e seen, to which extent this hole 
> affects the  MPLS-TP architecture.</font></div> <div dir=3D"ltr"><font 
> face=3D"times new roman"></font>&nbsp;</div> <div dir=3D"ltr"><font 
> face=3D"times new roman">As for references to Y.1731= , please note 
> that its OAM packets are not really fate-sharing with the use= r 
> traffic (link trace is a well-known example). MPLS-TP has been trying 
> to = improve that<a></a>: this is why its  MIPs are based on TTL 
> processing and not on, say, usage of Router Alert la= 
> bel.</font></div> <div dir=3D"ltr"><font face=3D"times new 
> roman"></font>&nbsp;</div> <div dir=3D"ltr"><font face=3D"times new 
> roman">At the same time, identifyi= ng MEPs and MIPs by their MAC 
> addresses (inserted&nbsp;as source<a></a> MAC= &nbsp;addresses<a></a> 
> in the OAM packets) is perfectly valid in Ethernet -=  but, IMO, not 
> in MPLS-TP.</font></div> <div dir=3D"ltr"><font face=3D"times new 
> roman"></font>&nbsp;</div> <div dir=3D"ltr"><font face=3D"times new 
> roman">My 2c,</font></div> <div dir=3D"ltr"><font face=3D"times new 
> roman">&nbsp;&nbsp;&nbsp;&nbsp; Sa= sha</font></div> <div 
> dir=3D"ltr"><font face=3D"times new roman"></font>&nbsp;</div> <div 
> id=3D"divRpF69836" style=3D"DIRECTION: ltr"> <hr tabindex=3D"-1"> 
> <font face=3D"Tahoma" color=3D"#000000" size=3D"2"><b>From:</b> Greg 
> Mirsky=  [[email-masked]]<br> <b>Sent:</b> Thursday, April 08, 
> 2010 12:33 AM<br> <b>To:</b> Shahram Davari<br> <b>Cc:</b> Alexander 
> Vainshtein; [email-masked]; mpls-tp@iet= f.org<br> 
> <b>Subject:</b> Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN 
> interf= aces?<br> </font><br> </div> <div></div> <div>Dear 
> Shahram,<br> I didn't say that it is &quot;lightweight&quot; ;) I just 
> point that whethe= r we go with BFD or Y.1731 we have additional ID(s) 
> carried as ACH TLV. I b= elieve that input from vendors like Broadcom 
> can help us compare two approa= ches in regard of their relative 
> friendliness  towards HW for OAM in MPLS-TP. Since pro-active CV/CC as 
> well as PM rely o= n HW related scenarios can be explored comparing 
> efficiency of each approac= h.<br> <br> Regards,<br> Greg<br> <br> 
> <div class=3D"gmail_quote">On Wed, Apr 7, 2010 at 2:21 PM, Shahram 
> Davari <= span dir=3D"ltr"> &lt;<a 
> href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</spa=
> n> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 
> 0pt 0= pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"> <div 
> lang=3D"EN-US"> <div> <p class=3D"MsoNormal"><span style=3D"FONT-SIZE: 
> 11pt; COLOR: rgb(31,73,125= )">Hi Greg,</span></p> <p 
> class=3D"MsoNormal"><span style=3D"FONT-SIZE: 11pt; COLOR: 
> rgb(31,73,125= )"></span>&nbsp;</p> <p class=3D"MsoNormal"><span 
> style=3D"FONT-SIZE: 11pt; COLOR: rgb(31,73,125= )">I have to agree 
> with Sasha. The TLV solution is not attractive because T= LVs are not 
> HW friendly and this means HW can=92t process them. Also it sti= ll 
> doesn=92t solve the problem of binding  a BFD packet to its associated 
> LSP.</span></p> <p class=3D"MsoNormal"><span style=3D"FONT-SIZE: 11pt; 
> COLOR: rgb(31,73,125= )"></span>&nbsp;</p> <p 
> class=3D"MsoNormal"><span style=3D"FONT-SIZE: 11pt; COLOR: 
> rgb(31,73,125= )">Regards,</span></p> <p class=3D"MsoNormal"><span 
> style=3D"FONT-SIZE: 11pt; COLOR: rgb(31,73,125= )">Shahram</span></p> 
> <p class=3D"MsoNormal"><span style=3D"FONT-SIZE: 11pt; COLOR: 
> rgb(31,73,125= )"></span>&nbsp;</p> <div style=3D"BORDER-RIGHT: medium 
> none; PADDING-RIGHT: 0in; BORDER-TOP: 1p= t solid; PADDING-LEFT: 0in; 
> PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; =
> PADDING-TOP: 3pt; BORDER-BOTTOM: medium none"> <p 
> class=3D"MsoNormal"><b><span style=3D"FONT-SIZE: 
> 10pt">From:</span></b><= span style=3D"FONT-SIZE: 10pt"> <a 
> href=3D"mailto:[email-masked]">[email-masked]</a> 
> [m= ailto:<a 
> href=3D"mailto:[email-masked]">[email-masked]<=
> /a>]
> <b>Sent:</b> Wednesday, April 07, 2010 2:15 PM<br> <b>To:</b> 
> Alexander Vainshtein<br> <b>Cc:</b> <a 
> href=3D"mailto:[email-masked]">Italo.Busi@alca=
> tel-lucent.com</a>;
> <b>Subject:</b> Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN 
> interf= aces?</span></p> </div> <div> <div></div> <div class=3D"h5"> 
> <p class=3D"MsoNormal">&nbsp;</p> <p class=3D"MsoNormal" 
> style=3D"MARGIN-BOTTOM: 12pt">Dear Alexander,<br> I think that your 
> concern can be addressed by ID(s) carried as ACH TLV. The=  Proactive 
> CV/CC for MPLS-TP in Figure 3 suggests that a MEP-ID that unique= ly 
> identifies source of the BFP packet precedes the BFD Control packet. I 
> t= hink that using MPLS-TP ID in ACH  TLVs would be common case for 
> MPLS-TP OAM.<br> <br> Regards,<br> Greg</p> <div> <p 
> class=3D"MsoNormal">On Wed, Apr 7, 2010 at 1:21 PM, Alexander 
> Vainshtein=  &lt;<a 
> href=3D"mailto:[email-masked]">Alexander.Vainshte=
> <p class=3D"MsoNormal">I=92d like to share with the list and, 
> specifically,=  with the authors of the MPLS-TP Framework and MPLS-TP 
> OAM Framework drafts=  my serious doubts regarding using the so-called 
> =93Section OAM=94 on Secti= ons represented by LAN (MP2MP) interfaces.
>  To the best of my understanding, such interfaces are allowed (or, at 
> least= , not prohibited) in MPLS-TP.</p> <p 
> class=3D"MsoNormal">&nbsp;</p> <p class=3D"MsoNormal">To the best of 
> my understanding, LSP OAM packet inse= rt GAL in the label stack 
> immediately after the last label defining this LS= P. Since MPLS-TP 
> does not allow MP2P LSP (no merge), the label stack above = GAL can be 
> used by the node that receives  an LSP OAM packet as data plane 
> identification of the LSP to which this OA= M packet belongs. This 
> behavior is well known in MPLS, e.g., see &nbsp;Sect= ion 4.4 
> =93Receiving MPLS Echo Request=94 of RFC 4379 (both the interface a= 
> nd received label stack of the received LSP-Ping  packet are stored as 
> part of processing).</p> <p class=3D"MsoNormal">&nbsp;</p> <p 
> class=3D"MsoNormal">=93Section OAM=94 uses GAL as the top (and only) 
> lab= el in the label stack. To me this means that an MPLS-TP node that 
> receives = a Section OAM packet from a LAN interface cannot identify 
> the originating a= djacent node based on the interface and  received 
> label stack (there is only one GAL!).</p> <p 
> class=3D"MsoNormal">&nbsp;</p> <p class=3D"MsoNormal">Of course the 
> only LAN interfaces worth mentioning a= re Ethernet ones, and the 
> receiving node can look at the source MAC address=  of the received 
> packet, but this looks to me like a serious layer violatio= n.</p> <p 
> class=3D"MsoNormal">&nbsp;</p> <p class=3D"MsoNormal">These notes 
> &nbsp;have been triggered by the resent = thread on Section service 
> initiated by Maarten.
> </p>
> <p class=3D"MsoNormal">Did I miss something important?</p> <p 
> class=3D"MsoNormal">&nbsp;</p> <p class=3D"MsoNormal">Regards,</p> <p 
> class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; Sasha</p> <p 
> class=3D"MsoNormal">&nbsp;</p> </div> </div> <p class=3D"MsoNormal" 
> style=3D"MARGIN-BOTTOM: 12pt"><br>

---

From: <[email-masked]>
Date: Mon, 12 Apr 2010 12:52:41 +0100

Maarten,

The topology (links) of layer network N are provided by layer N-1 network connections.  This recurses to the BOS section-layer/duct network.  What this means is that the performance experienced by a given layer network X will be the sum of (i) its own performance impairments and (ii) the performance impairments it inherits from all the lower layer networks down to the duct.....and of course when considering availability performance, the disjoint connectivity of any layer network cannot be greater that that of the duct graph.

If MPLS-TP is supposed to be providing a transport capability (of which client transparency is the critical service) then it must be able to provide performance isolation between its clients....which means:
-	it must use proper connections (necessary)
-	it should not overbook its resources (full sufficiency)...a corollary of which is that a connection can only have a single QoS class.

...or put somewhat simpler, the performance client Y experiences should not be a function of the traffic behaviour of any other client. 

Note that this also applies to *all* networks below MPLS-TP too...if it does not then there was no point in imbuing MPLS-TP with transport behaviour in the first place as we would have just compromised this.

Aside=> If the above is not a goal of MPLS-TP then I do wonder why we are bothering with MPLS-TP at all?

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: 12 April 2010 10:47
> To: 'Alexander Vainshtein'; 'BUSI ITALO'
> Cc: [email-masked]
> Subject: [mpls-tp] MPLS-TP media types [was: RE: Can MPLS-TP 
> Section OAM be used on LAN interfaces?]
> 
> Sasha, Italo,
> 
> I have changed the subject line as we seem to be addressing 
> the types of media over which MPLS-TP can be run.
> 
> I think that we have to be very explicit over which media we 
> assume to run MPLS-TP over. E.g.:
> The VLANs, VC-n's and ODUk's can be used as Section layer 
> signals replacing the MPLS-TP Section layer signal, or can be 
> carrying (as a physical media layer signal) the MPLS-TP 
> Section layer signal.
> 
> In the first case there is no MPLS-TP Section layer; instead 
> the MPLS-TP Transport Path layer signals are directly 
> supported by a VLAN/VC-n/ODUk type of Section layer.
> 
> In the second case there is a MPLS-TP Section layer on top of 
> a VLAN/VC-n/ODUk type of physical media layer.
> 
> Section 5 in the data plane draft could be extended with e.g. 
> SDH and OTN Media subsections 5.2 and 5.3 in which the 
> detailed mapping specifications are presented (e.g. MPLS-TP 
> LSP and PW via GFP-F into VC-n and ODUk, management and 
> control plane information via MPLS-TP SCC/MCC) and the type 
> of VC-n and ODUk (p2p, p2mp) that are supported. In here it 
> is then also possible to specify what Section layer 
> technology is used (MPLS-TP Section or VC-n or ODUk type sections).
> 
> Section 5.1 could be extended with a list of LAN and VLAN 
> types (see above) that are supported as MPLS-TP media. In 
> here it is then also possible to specify what Section layer 
> technology is used (MPLS-TP Section or Ethernet VLAN type 
> section), and how management and control plane information is carried.
> 
> Regards,
> Maarten
> PS. Note that the VLANs, VC-n's and ODUk's may also be used 
> as Transport Path layer signals replacing the MPLS-TP 
> Transport Path layer signal. I have ignored that above.
> 
> 
> 
>  
> 
> Your example for p2mp media looks valid. I must admit that I 
> have never considered it. I think that actually using such a 
> media as an MPLS-TP Section could be highly problematic, but 
> this is another issue.
> 
> Regarding running MPLS-TP over mp2mp media: you may be quite 
> right regarding the rough (in both senses of the word!) 
> consensus that it is allowed. But IMO this point should be 
> explicitly raised on the list because, as Maarten's messages 
> show, there are some people that vigorously object to it. 
> 
> Assuming that consensus supports MPLS-TP over mp2mp media: 
> stating that Section OAM MUST NOT be used on MP2MP media 
> would resolve one specific issue. 
> 
> My 2c,
>      Sasha
> 
> 
> 
> If my understanding regarding the rough consensus is correct, 
> I agree with you that we need to document/resolve all the 
> associated technical issues.
> 
> On my side, if would be fine to clearly state that MPLS-TP 
> Section OAM MUST NOT be used on mp2mp media.
> 
> If my understanding regarding the rough consensus in 
> incorrect, I agree with you that we need to explicity 
> document that MPLS-TP MUST NOT run over mp2mp media.
> 
> Italo
> 
> 
> P.S. Please note my new email address, 
> [email-masked], effective since 1 November 2009.
> 
> 
> 
> 
> 
> 
> If we restrict MPLS-TP to P2P media, many technical issues 
> will become non-relevant (my example with the Section OAM is, 
> IMHO, just the top of an iceberg). But such a restriction 
> must be explicit, it cannot be left at the level of "Don't 
> worry, nobody will ever do such a thing". Because somebody will do it.
> 
> My 2c,
>      Sasha
> 
> 
> 
> As you pointed out, running MPLS-TP over mp2mp media is going 
> to defeat MPLS-TP traffic engineering so I doubt this will be 
> really used in properly TE networks.
> 
> P.S. Please note my new email address, 
> [email-masked], effective since 1 November 2009.
> 
> 
> 
> 
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> 1000BASSE-X, 10GBASE-R, 40GBASE-R and 100GBASE-R physical 
> interfaces do not support such mp2mp LAN.
> Separate of the above question on supporting other then p2p 
> media in MPLS-TP, I would like to comment on the following 
> consideration of you:
> 
> > and
> > look at the source MAC address of the received packet, but 
> this looks 
> > to
> If one would use a mp2mp media to carry an MPLS-TP section 
> layer signal over, then the MPLS-TP section layer transport 
> path may still be a p2p transport path. For this case the 
> Ethernet to MPLS-TP adaptation will insert a unicast 
> destination address on all the MPLS-TP packets. The receiving 
> Ethernet to MPLS-TP adaptation function will accept only 
> ethernet frames with one specific source address. Result is 
> to the receiving port (adaptation function) will only pass 
> through MPLS-TP packets from one of the input ports on the 
> mp2mp medium. This is not a layer violation as you suggest, 
> it is a normal, required operation in the adaptation function.
> If one would use a mp2mp medium to support a full mesh of p2p 
> section layer transport paths between n ports on that medium, 
> then  the Ethernet to MPLS-TP adaptation will have n-1 
> input/output ports connected with n-1 MPLS-TP Section MEP 
> functions. The MPLS-TP packets from each MEP will be 
> (SIs) are multiplexed into one server layer signal, it is 
> necessary to have a MPLS-TP SI identifier. As long as there 
> is only one section layer transport path instance between any 
> two ports on the n-port medium it is possible and correct to 
> use the source address as SI demultiplexer; section-LSP label 
> is <da,sa>. 
> 
> If there would be a need to carry multiple section instances 
> between two ports on this n-port medium it will be necessary 
> to add an additional SI identifier as the <da,sa> 
> demultiplexer is not longer unique. This additional SI 
> identifier could be a label in an additional section LSP 
> label stack entry header, or could be a VLAN ID in a VLAN 
> Tag. If you use the latter you would have a PBB-TE ESP like 
> label <section-lsp-da,section-lsp-sa,section-lsp-vid> 
> (instead of <esp-da,esp-sa,esp-vid>). If you would use the 
> former you could use a 'per medium label space', or a 'per 
> interface port label space'.
> Alternatively it is possible to replace the MPLS-TP Section 
> layer by an Ethernet Section layer and use Ethernet OAM to 
> check the connectivity between the n-ports.
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 13 Apr 2010 08:26:16 +0300

Maarten,
I agree that "we have to be very explicit over which media we assume to run MPLS-TP over".

IMO, this issue is addressed (to some extent) by Requirement 31 in RFC 5654:

<quote>
   31  A generic and extensible solution MUST be provided to support the
       transport of MPLS-TP transport paths over one or more server
       layer networks (such as MPLS-TP, Ethernet, SONET/SDH, OTN, etc.).
       Requirements for bandwidth management within a server layer
       network are outside the scope of this document.
<end quote>

However, the problems of the server layer for MPLS-TP goes beyond the physical media. It is also about
the functionality provided by the intermediate devices that are specific to this or that server layer and
unaware of MPLS-TP.

E.g., Italo's example of p2mp SONET/SDH trail as p2mp media means, IMO, that SONET/SDH switches interconnecting MPLS-TP LSRs provide for replication of MPLS-TP packets without being aware of 
MPLS-TP.  It seems like this functionality can be beneficial for certain p2mp applications, e.g., IPTV.

Similar to that, I would assume that Ethernet switches interconnecting MPLS-TP LSRs while
remaining unaware of MPLS-TP can provide useful functionality for multiple applications. One example 
includes traffic aggregation and replication e.g., for the same IPTV application which in many cases combines p2mp and p2p traffic over the same physical media. MPLS-TP LSRs interconnected by such switches (and
(of course, unaware of their existence) would be logically connected by mp2mp, a.k.a. LAN interfaces. 

Of course, IP/MPLS handles LAN interfaces form Day 1 and provides special extensions (e.g., context labels introduced in RFC 5331) where required. 

MPLS-TP experiences certain problems with LAN interfaces. Defining unicast Destination MAC address for
sending MPLS-TP packets on p2p LSPs is one such problem. Running Section OAM is another one. And there may be more.
 
IMHO and FWIW we have one "bad" and  two "good" options for dealing with these problems:

1. (Good): We can explicitly prohibit usage of LAN interfaces in MPLS-TP. This, of course, would eliminate 
    all the related problems - but the price (in the terms of applicability of MPLS-TP, especially, to 
    existing deployments) may be prohibitive. Taking such a course requires, IMO, strong explicit consensus

2. (Good) We can explicitly allow usage of LAN interfaces in MPLS-TP and address (one by one) all the 
     involved problems. I believe that this is doable, but requires some effort. 

3. (Bad) We can let the sleeping dogs lie - and face the consequences later.

The last (bad) option includes IMHO ignoring the difference between media (which could be p2p, p2mp or
mp2mp) and interfaces (which, in the IETF parlance, can be p2p, LAN or NBMA).  

In other words, "MPLS-TP media types" and "MPLS-TP over LAN interfaces" are two different (even if interrelated) subjects.

My 2c,
     Sasha

________________________________________
From: Maarten Vissers [[email-masked]]
Sent: Monday, April 12, 2010 12:47 PM
To: Alexander Vainshtein; 'BUSI ITALO'
Cc: [email-masked]
Subject: MPLS-TP media types [was: RE: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?]

Sasha, Italo,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: zaterdag 10 april 2010 17:07
To: BUSI ITALO
Cc: [email-masked]; Maarten Vissers
Subject: RE: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Italo,

My 2c,
     Sasha

Sasha,

thanks for your reply.

Italo

Italo,

Regarding restrictions:

My 2c,
     Sasha

Good question.

Thanks, Italo

Sasha,

me this means that an
cannot identify the
the receiving node can

Regards,
Maarten

---

From: <[email-masked]>
Date: Tue, 13 Apr 2010 08:04:44 +0100

Sasha,  Did you see my mail of yesterday? The key point I was making in that mail was that it is not sufficient to simply get the MPLS-TP architecture right (I wish!) in order to provide MPLS-TP clients with a transparent transport service, but one must also ensure all the server layers (right down to the duct) also provide a transparent transport service, else the effort on MPLS-TP is wasted.  I often refer to this issue as 'performance inheritance' due to the recursive nature of client/server layer network topology construction. 

This issue is especially crucial for MPLS-TP because it cannot be Bottom-Of-Stack, ie it does not of itself have a physical/section-layer specification but must always use a server layer network technology that has.  If the server layer(s) (to the duct) is(are) co-cs then there will be no problem.

Of course we can always ignore this issue (effectively your 'bad' option 3 below) and face the consequences later.   I think operators should careful thought to this point, because what is ultimately at stake here is any service requirement from their customers/clients for a transparent transport, ie the performance customer/client X sees is not a function of the behaviour of other customers/clients of the server layer.....in other words the server layer performance transfer function is not a function of its traffic load.

Now some customers will demand this (especially parties such as operators who wish to build/control their own networks above transport capacity they are leasing from other parties) whereas other may not....and wrt to the former point here, this is why I keep saying it is a very important to ensure that MPLS-TP provides a good MPLS-TPoverMPLS-TP client/server solution if it is to be successful.

I do not think it difficult to allow MPLS-TP to provide this transparent transport capability (or not as required), but the areas that need careful attention IMO are:

-	layering vs sublayering.....there is still no clarity here IMO.  A MPLS-TP transport network does not need sublayering IMO (ie trad S bit usage in MPLS), a TTL loop mitigation function nor should it spawn a PW layer network above it.  Many areas are indirectly impacted by this, such as:  clarity of layer network addressing (of access points), MPLS-TPoverMPLS-TP client/server relationship, no need for E-NNIs;

-	Temporal (QoS) urgency vs survivability importance.....I can already foresee a huge amount of effort/cost being expended on this area and IMO most of it will be in vain....if real networks spend a significant amount of time in the congestion region (which is the only place QoS will transiently manifest itself is a highly non-linear fashion) then the capacity planning design is already broken IMO.  A transport network must make no QoS/survivability judgement-call on the ultimate TOS external message/file/stream clients....it must simply treat all bits (ie the atomic unit of information) equally.  Put yourself in the position of an operator building a network and leasing capacity from a server party.  Would you really want the server party to make judgement calls of the QoS/importance of TOS applications of customers using your network that are unlikely to be even evident to the server party (nor would you want such snooping behaviour anyway)?!

regards, Neil

> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> Sent: 13 April 2010 06:26
> To: Maarten Vissers
> Cc: 'BUSI ITALO'; [email-masked]
> Subject: Re: [mpls-tp] MPLS-TP media types [was: RE: Can 
> MPLS-TP Section OAM be used on LAN interfaces?]
> 
> Maarten,
> However, the problems of the server layer for MPLS-TP goes 
> beyond the physical media. It is also about the functionality 
> provided by the intermediate devices that are specific to 
> this or that server layer and unaware of MPLS-TP.
> 
> E.g., Italo's example of p2mp SONET/SDH trail as p2mp media 
> means, IMO, that SONET/SDH switches interconnecting MPLS-TP 
> LSRs provide for replication of MPLS-TP packets without being 
> aware of MPLS-TP.  It seems like this functionality can be 
> beneficial for certain p2mp applications, e.g., IPTV.
> 
> Similar to that, I would assume that Ethernet switches 
> interconnecting MPLS-TP LSRs while remaining unaware of 
> MPLS-TP can provide useful functionality for multiple 
> applications. One example includes traffic aggregation and 
> replication e.g., for the same IPTV application which in many 
> cases combines p2mp and p2p traffic over the same physical 
> media. MPLS-TP LSRs interconnected by such switches (and (of 
> course, unaware of their existence) would be logically 
> connected by mp2mp, a.k.a. LAN interfaces. 
> 
> Of course, IP/MPLS handles LAN interfaces form Day 1 and 
> provides special extensions (e.g., context labels introduced 
> in RFC 5331) where required. 
> 
> MPLS-TP experiences certain problems with LAN interfaces. 
> Defining unicast Destination MAC address for sending MPLS-TP 
> packets on p2p LSPs is one such problem. Running Section OAM 
> is another one. And there may be more.
>  
> 1. (Good): We can explicitly prohibit usage of LAN interfaces 
> in MPLS-TP. This, of course, would eliminate 
>     existing deployments) may be prohibitive. Taking such a 
> course requires, IMO, strong explicit consensus
> 
> The last (bad) option includes IMHO ignoring the difference 
> between media (which could be p2p, p2mp or
> In other words, "MPLS-TP media types" and "MPLS-TP over LAN 
> interfaces" are two different (even if interrelated) subjects.
> 
> My 2c,
>      Sasha
> 
> 
> 
>

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 13 Apr 2010 09:36:11 +0200

Sasha,

My choice is your option 2.

In my list I consider the 
- p2p 802.3 LAN (10M, 100M, 1G, 10G, 40G, 100G)
- mp2mp 802.3 CSMA/CD LAN (10M, 100M)
interfaces as a pure physical layer thing with MPLS-TP processing at each
end. 

Important for those interfaces is to define how the mp2mp CSMA/CD LAN is
used (if it is used, which I doubt).
Furthermore, important to define is how MP and CP information is carried
over those interfaces; e.g. via MPLS-TP Section SCC/MCC channels (assuming
that the MPLS-TP Section layer is present). If MPLS-TP Section layer is not
present we need to define how MP/CP information is carried.

The other items in my list 
- p2p VLAN
- p2mp VLAN
[- rmp VLAN]
[- mp2mp VLAN]
- p2p SDH VC-n
- p2mp SDH VC-n
- p2p OTN ODUk
- p2mp OTN ODUk
allow to carry the encapsulated MPLS-TP signal(s) through an Ethernet, SDH
or OTN network.

I doubt if there is a real use for rmp and mp2mp VLANs...

Also here we have to define how the MP/CP infromation is carried over those
interfaces; if there is a MPLS-TP Section layer present, then it can be
carried over Section MCC/SCC channels. If there is no Section layer, then
for e.g. OTN it can be carried in the ODUk GCC1/GCC2 channels. When the ODUk
set up and possible modification (e.g. for case of ODUflex) is possible via
OTN GMPLS, then the OTN CP information can be carried in the OTUk GCC0
channel.

There is another approach thatt we have to consider as well. In this case
the OTN ODUk does not terminate in the MPLS-TP node, it terminates in the
OTN node connected with the MPLS-TP node. The mapping of MPLS-TP into OTN
ODUks is now performed in the OTN node. Mapping could be of one or more
Transport-LSPs into an ODUk (e.g. k=flex). How to transport MPLS-TP CP/MP
information has to be defined; e.g. via Transport-LSP SCC/MCC channels or
ODU GCC1/GCC2 channels.

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: dinsdag 13 april 2010 7:26
To: Maarten Vissers
Cc: [email-masked]; 'BUSI ITALO'
Subject: RE: MPLS-TP media types [was: RE: [mpls-tp] Can MPLS-TP Section OAM
be used on LAN interfaces?]

Maarten,
I agree that "we have to be very explicit over which media we assume to run
MPLS-TP over".

<quote>

However, the problems of the server layer for MPLS-TP goes beyond the
physical media. It is also about the functionality provided by the
intermediate devices that are specific to this or that server layer and
unaware of MPLS-TP.

E.g., Italo's example of p2mp SONET/SDH trail as p2mp media means, IMO, that
SONET/SDH switches interconnecting MPLS-TP LSRs provide for replication of
MPLS-TP packets without being aware of MPLS-TP.  It seems like this
functionality can be beneficial for certain p2mp applications, e.g., IPTV.

Similar to that, I would assume that Ethernet switches interconnecting
MPLS-TP LSRs while remaining unaware of MPLS-TP can provide useful
functionality for multiple applications. One example includes traffic
aggregation and replication e.g., for the same IPTV application which in
many cases combines p2mp and p2p traffic over the same physical media.
MPLS-TP LSRs interconnected by such switches (and (of course, unaware of
their existence) would be logically connected by mp2mp, a.k.a. LAN
interfaces. 

Of course, IP/MPLS handles LAN interfaces form Day 1 and provides special
extensions (e.g., context labels introduced in RFC 5331) where required. 

MPLS-TP experiences certain problems with LAN interfaces. Defining unicast
Destination MAC address for sending MPLS-TP packets on p2p LSPs is one such
problem. Running Section OAM is another one. And there may be more.
 
IMHO and FWIW we have one "bad" and  two "good" options for dealing with
these problems:

1. (Good): We can explicitly prohibit usage of LAN interfaces in MPLS-TP.
This, of course, would eliminate 
    all the related problems - but the price (in the terms of applicability
of MPLS-TP, especially, to 
    existing deployments) may be prohibitive. Taking such a course requires,
IMO, strong explicit consensus

2. (Good) We can explicitly allow usage of LAN interfaces in MPLS-TP and
address (one by one) all the 
     involved problems. I believe that this is doable, but requires some
effort. 

The last (bad) option includes IMHO ignoring the difference between media
(which could be p2p, p2mp or
mp2mp) and interfaces (which, in the IETF parlance, can be p2p, LAN or
NBMA).  

In other words, "MPLS-TP media types" and "MPLS-TP over LAN interfaces" are
two different (even if interrelated) subjects.

My 2c,
     Sasha

Subject: MPLS-TP media types [was: RE: [mpls-tp] Can MPLS-TP Section OAM be
used on LAN interfaces?]

Sasha, Italo,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: zaterdag 10 april 2010 17:07
To: BUSI ITALO
Cc: [email-masked]; Maarten Vissers
Subject: RE: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

Italo,

My 2c,
     Sasha

Sasha,

thanks for your reply.

Italo

Italo,

Regarding restrictions:

My 2c,
     Sasha

Good question.

Thanks, Italo

Sasha,

me this means that an
cannot identify the
the receiving node can

Regards,
Maarten=

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 13 Apr 2010 10:08:29 +0200

Neil,

> Put yourself in the position of an operator building a network
> and leasing capacity from a server party.  Would you really want
> the server party to make judgement calls of the QoS/importance
> of TOS applications of customers using your network that are
> unlikely to be even evident to the server party (nor would you
> want such snooping behaviour anyway)?!

The operator who is leasing capacity from a server party is in full control
in my understanding. It is the operator's decision to lease either a packet
line service, or a circuit line service. 

If the latter is leased, then it is the operator's choice to have the
circuit line (e.g. ODUk) end in his node, or in the server party's node. If
the latter is the case, then it is the operator's choice to send his traffic
within the bandwidht limits of the circuit line service (CIR+EIR<=circuit
(e.g. ODUk) bandwidth), or exceeding those limits. If the former is the
case, then everything is in the hands of the operator itself.

If the former is leased, then it is the operator's choice to use a CIR only,
CIR+EIR, or EIR only type packet line (e.g. VLAN or MPLS-TP LSP) service.
One of the applications where such VLAN service is used is to connect with
remote Network Termination devices, located behind the network of a third
party operator. This third party operator is offering then a wholesale
ethernet access service (WEAS).

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 13 april 2010 9:05
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MPLS-TP media types [was: RE: Can MPLS-TP Section OAM

Sasha,  Did you see my mail of yesterday? The key point I was making in that
mail was that it is not sufficient to simply get the MPLS-TP architecture
right (I wish!) in order to provide MPLS-TP clients with a transparent
transport service, but one must also ensure all the server layers (right
down to the duct) also provide a transparent transport service, else the
effort on MPLS-TP is wasted.  I often refer to this issue as 'performance
inheritance' due to the recursive nature of client/server layer network
topology construction. 

This issue is especially crucial for MPLS-TP because it cannot be
Bottom-Of-Stack, ie it does not of itself have a physical/section-layer
specification but must always use a server layer network technology that
has.  If the server layer(s) (to the duct) is(are) co-cs then there will be
no problem.

Of course we can always ignore this issue (effectively your 'bad' option 3
below) and face the consequences later.   I think operators should careful
thought to this point, because what is ultimately at stake here is any
service requirement from their customers/clients for a transparent
transport, ie the performance customer/client X sees is not a function of
the behaviour of other customers/clients of the server layer.....in other
words the server layer performance transfer function is not a function of
its traffic load.

Now some customers will demand this (especially parties such as operators
who wish to build/control their own networks above transport capacity they
are leasing from other parties) whereas other may not....and wrt to the
former point here, this is why I keep saying it is a very important to
ensure that MPLS-TP provides a good MPLS-TPoverMPLS-TP client/server
solution if it is to be successful.

I do not think it difficult to allow MPLS-TP to provide this transparent
transport capability (or not as required), but the areas that need careful
attention IMO are:

-	layering vs sublayering.....there is still no clarity here IMO.  A
MPLS-TP transport network does not need sublayering IMO (ie trad S bit usage
in MPLS), a TTL loop mitigation function nor should it spawn a PW layer
network above it.  Many areas are indirectly impacted by this, such as:
clarity of layer network addressing (of access points), MPLS-TPoverMPLS-TP
client/server relationship, no need for E-NNIs;

-	Temporal (QoS) urgency vs survivability importance.....I can already
foresee a huge amount of effort/cost being expended on this area and IMO
most of it will be in vain....if real networks spend a significant amount of
time in the congestion region (which is the only place QoS will transiently
manifest itself is a highly non-linear fashion) then the capacity planning
design is already broken IMO.  A transport network must make no
QoS/survivability judgement-call on the ultimate TOS external
message/file/stream clients....it must simply treat all bits (ie the atomic
unit of information) equally.  Put yourself in the position of an operator
building a network and leasing capacity from a server party.  Would you
really want the server party to make judgement calls of the QoS/importance
of TOS applications of customers using your network that are unlikely to be
even evident to the server party (nor would you want such snooping behaviour
anyway)?!

regards, Neil

> Subject: Re: [mpls-tp] MPLS-TP media types [was: RE: Can MPLS-TP 
> intermediate devices that are specific to this or that server layer 
> and unaware of MPLS-TP.
> 
> E.g., Italo's example of p2mp SONET/SDH trail as p2mp media means, 
> IMO, that SONET/SDH switches interconnecting MPLS-TP LSRs provide for 
> replication of MPLS-TP packets without being aware of MPLS-TP.  It 
> seems like this functionality can be beneficial for certain p2mp 
> applications, e.g., IPTV.
> 
> aggregation and replication e.g., for the same IPTV application which 
> in many cases combines p2mp and p2p traffic over the same physical 
> media. MPLS-TP LSRs interconnected by such switches (and (of course, 
> unaware of their existence) would be logically connected by mp2mp, 
> a.k.a. LAN interfaces.
> 
> Of course, IP/MPLS handles LAN interfaces form Day 1 and provides 
> special extensions (e.g., context labels introduced in RFC 5331) where 
> required.
> 
> Defining unicast Destination MAC address for sending MPLS-TP packets 
> on p2p LSPs is one such problem. Running Section OAM is another one. 
> And there may be more.
>  
> 1. (Good): We can explicitly prohibit usage of LAN interfaces in 
> MPLS-TP. This, of course, would eliminate
> I have changed the subject line as we seem to be addressing the types 
> of media over which MPLS-TP can be run.
> 
> I think that we have to be very explicit over which media we assume to 
> run MPLS-TP over. E.g.:
> The VLANs, VC-n's and ODUk's can be used as Section layer signals 
> replacing the MPLS-TP Section layer signal, or can be carrying (as a 
> physical media layer signal) the MPLS-TP Section layer signal.
> 
> In the first case there is no MPLS-TP Section layer; instead the 
> MPLS-TP Transport Path layer signals are directly supported by a 
> VLAN/VC-n/ODUk type of Section layer.
> 
> SDH and OTN Media subsections 5.2 and 5.3 in which the detailed 
> mapping specifications are presented (e.g. MPLS-TP LSP and PW via 
> GFP-F into VC-n and ODUk, management and control plane information via 
> MPLS-TP SCC/MCC) and the type of VC-n and ODUk (p2p, p2mp) that are 
> supported. In here it is then also possible to specify what Section 
> layer technology is used (MPLS-TP Section or VC-n or ODUk type 
> sections).
> 
> Section 5.1 could be extended with a list of LAN and VLAN types (see 
> above) that are supported as MPLS-TP media. In here it is then also 
> possible to specify what Section layer technology is used (MPLS-TP 
> Section or Ethernet VLAN type section), and how management and control 
> plane information is carried.
> 
> Regards,
> Maarten
> PS. Note that the VLANs, VC-n's and ODUk's may also be used as 
> Transport Path layer signals replacing the MPLS-TP Transport Path 
> layer signal. I have ignored that above.
> 
> 
> 
> 
> 
> Your example for p2mp media looks valid. I must admit that I have 
> never considered it. I think that actually using such a media as an 
> MPLS-TP Section could be highly problematic, but this is another 
> issue.
> 
> Regarding running MPLS-TP over mp2mp media: you may be quite right 
> regarding the rough (in both senses of the word!) consensus that it is 
> allowed. But IMO this point should be explicitly raised on the list 
> because, as Maarten's messages show, there are some people that 
> vigorously object to it.
> 
> stating that Section OAM MUST NOT be used on MP2MP media would resolve 
> one specific issue.
> 
> My 2c,
>      Sasha
> 
> 
> 
> If my understanding regarding the rough consensus is correct, I agree 
> with you that we need to document/resolve all the associated technical 
> issues.
> 
> If my understanding regarding the rough consensus in incorrect, I 
> agree with you that we need to explicity document that MPLS-TP MUST 
> NOT run over mp2mp media.
> 
> Italo
> 
> 
> non-relevant (my example with the Section OAM is, IMHO, just the top 
> of an iceberg). But such a restriction must be explicit, it cannot be 
> left at the level of "Don't worry, nobody will ever do such a thing". 
> Because somebody will do it.
> 
> My 2c,
>      Sasha
> 
> 
> 
> defeat MPLS-TP traffic engineering so I doubt this will be really used 
> in properly TE networks.
> 
> p2mp media?
> MPLS-TP networks.
> do not support such mp2mp LAN.
> in a mp2mp configuration?
> signal over, then the MPLS-TP section layer transport path may still 
> be a p2p transport path. For this case the Ethernet to MPLS-TP 
> adaptation will insert a unicast destination address on all the 
> MPLS-TP packets. The receiving Ethernet to MPLS-TP adaptation function 
> will accept only ethernet frames with one specific source address. 
> Result is to the receiving port (adaptation function) will only pass 
> through MPLS-TP packets from one of the input ports on the mp2mp 
> medium. This is not a layer violation as you suggest, it is a normal, 
> required operation in the adaptation function.
> layer transport paths between n ports on that medium, then  the 
> connected with n-1 MPLS-TP Section MEP functions. The MPLS-TP packets 
> from each MEP will be prepended by the ethernet header, including a 
> unicast destination address.
> 
> (SIs) are multiplexed into one server layer signal, it is necessary to 
> have a MPLS-TP SI identifier. As long as there is only one section 
> layer transport path instance between any two ports on the n-port 
> medium it is possible and correct to use the source address as SI 
> demultiplexer; section-LSP label is <da,sa>.
> 
> two ports on this n-port medium it will be necessary to add an 
> additional SI identifier as the <da,sa> demultiplexer is not longer 
> unique. This additional SI identifier could be a label in an 
> additional section LSP label stack entry header, or could be a VLAN ID 
> in a VLAN Tag. If you use the latter you would have a PBB-TE ESP like 
> (instead of <esp-da,esp-sa,esp-vid>). If you would use the former you 
> space'.
> an Ethernet Section layer and use Ethernet OAM to check the 
> connectivity between the n-ports.
>

---

From: <[email-masked]>
Date: Tue, 13 Apr 2010 10:17:13 +0100

Thanks Maarten,  Please see one remark in-line: 

Maarten wrote 13 April 2010 09:08
> To: Harrison,N,Neil,DKQ7 R; [email-masked]
> Subject: RE: [mpls-tp] MPLS-TP media types [was: RE: Can 
> > Put yourself in the position of an operator building a network and 
> > leasing capacity from a server party.  Would you really want the 
> > server party to make judgement calls of the QoS/importance of TOS 
> > applications of customers using your network that are 
> unlikely to be 
> > even evident to the server party (nor would you want such snooping 
> > behaviour anyway)?!
> 
> The operator who is leasing capacity from a server party is 
> in full control in my understanding. 

NH=> Not necessarily.  This is only possibly true if (i) the server party then owns all the layers to the duct and (ii) is the only server party to that customer in a given geographic area.  The latter point here is related to 'control' of disjoint connectivity.  One of the first/key questions any customer who is creating their own layer network using leased server transport services asks is 'can you guarantee me that a new server layer transport connection you provide me with is disjoint from the other transport connections you provided me with in the past?'  Now if the customer has leased capacity from different server parties within the same geographic span then it will usually not be possible to provide any assurance of disjoint connectivity.

This issue (relating to availability and resilience design in the customer's network) is separate from the transport transfer performance topic I discussed in the mail below.  Both however, are very important to many customers of transport network services.

regards, Neil

It is the operator's 
> decision to lease either a packet line service, or a circuit 
> line service. 
> 
> If the latter is leased, then it is the operator's choice to 
> have the circuit line (e.g. ODUk) end in his node, or in the 
> server party's node. If the latter is the case, then it is 
> the operator's choice to send his traffic within the 
> bandwidht limits of the circuit line service 
> (CIR+EIR<=circuit (e.g. ODUk) bandwidth), or exceeding those 
> limits. If the former is the case, then everything is in the 
> hands of the operator itself.
> 
> One of the applications where such VLAN service is used is to 
> connect with remote Network Termination devices, located 
> behind the network of a third party operator. This third 
> party operator is offering then a wholesale ethernet access 
> service (WEAS).
> 
> Regards,
> Maarten
>  
> 
> Subject: RE: [mpls-tp] MPLS-TP media types [was: RE: Can 
> Sasha,  Did you see my mail of yesterday? The key point I was 
> making in that mail was that it is not sufficient to simply 
> get the MPLS-TP architecture right (I wish!) in order to 
> provide MPLS-TP clients with a transparent transport service, 
> but one must also ensure all the server layers (right down to 
> the duct) also provide a transparent transport service, else 
> the effort on MPLS-TP is wasted.  I often refer to this issue 
> as 'performance inheritance' due to the recursive nature of 
> client/server layer network topology construction. 
> 
> This issue is especially crucial for MPLS-TP because it 
> cannot be Bottom-Of-Stack, ie it does not of itself have a 
> physical/section-layer specification but must always use a 
> server layer network technology that has.  If the server 
> layer(s) (to the duct) is(are) co-cs then there will be no problem.
> 
> thought to this point, because what is ultimately at stake 
> here is any service requirement from their customers/clients 
> for a transparent transport, ie the performance 
> customer/client X sees is not a function of the behaviour of 
> other customers/clients of the server layer.....in other 
> words the server layer performance transfer function is not a 
> function of its traffic load.
> 
> Now some customers will demand this (especially parties such 
> as operators who wish to build/control their own networks 
> above transport capacity they are leasing from other parties) 
> whereas other may not....and wrt to the former point here, 
> this is why I keep saying it is a very important to ensure 
> that MPLS-TP provides a good MPLS-TPoverMPLS-TP client/server 
> I do not think it difficult to allow MPLS-TP to provide this 
> transparent transport capability (or not as required), but 
> the areas that need careful attention IMO are:
> 
> MPLS-TP transport network does not need sublayering IMO (ie 
> trad S bit usage in MPLS), a TTL loop mitigation function nor 
> should it spawn a PW layer network above it.  Many areas are 
> indirectly impacted by this, such as:
> clarity of layer network addressing (of access points), 
> MPLS-TPoverMPLS-TP client/server relationship, no need for E-NNIs;
> 
> foresee a huge amount of effort/cost being expended on this 
> area and IMO most of it will be in vain....if real networks 
> spend a significant amount of time in the congestion region 
> (which is the only place QoS will transiently manifest itself 
> is a highly non-linear fashion) then the capacity planning 
> design is already broken IMO.  A transport network must make 
> no QoS/survivability judgement-call on the ultimate TOS 
> external message/file/stream clients....it must simply treat 
> all bits (ie the atomic unit of information) equally.  Put 
> yourself in the position of an operator building a network 
> and leasing capacity from a server party.  Would you really 
> want the server party to make judgement calls of the 
> QoS/importance of TOS applications of customers using your 
> network that are unlikely to be even evident to the server 
> party (nor would you want such snooping behaviour anyway)?!
> 
> regards, Neil
> 
> > I agree that "we have to be very explicit over which media 
> we assume 
> > to run MPLS-TP over".
> > 
> >    31  A generic and extensible solution MUST be provided 
> to support 
> > the
> beyond the 
> interconnecting 
> > 2. (Good) We can explicitly allow usage of LAN interfaces 
> in MPLS-TP 
> > and address (one by one) all the
> > 3. (Bad) We can let the sleeping dogs lie - and face the 
> consequences 
> > later.
> > 
> > Subject: MPLS-TP media types [was: RE: [mpls-tp] Can 
> MPLS-TP Section 
> > Regarding p2mp media, how would you consider a scenario 
> where MPLS-TP 
> > is running over p2mp SDH VC?
> > 
> > One minor point: I do not think that p2mp media exists. It 
> is either 
> > p2p or mp2mp.
> > 
> > Regarding restrictions:
> > 
> will become 
> media in 
> > > originating adjacent node based on the interface and 
> received label 
> > > stack
> necessary to 
> former you 
> layer by

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Apr 2010 01:29:05 -0400

In message <[email-masked]>

Sasha,

Here are two places that explicitly exclude mp2p and mp2mp.

Re "... somebody already uses mp2mp media in MPLS-TP".
You definitely have that wrong.

Curtis

draft-ietf-mpls-tp-framework-11.txt

   This document describes an architectural framework for the
   application of MPLS to the construction of packet-switched transport
   networks.  It specifies the common set of protocol functions that
   meet the requirements in [RFC5654], and that together constitute the
   MPLS Transport Profile (MPLS-TP) for point-to-point transport paths.
   The remaining MPLS-TP functions, applicable specifically to point-to-
   multipoint transport paths, are outside the scope of this document.

[ ... much later ... ]

1.3.4.  MPLS-TP Label Switched Path

   An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a
   subset of the capabilities of an MPLS LSP in order to meet the
   requirements of an MPLS transport network as set out in [RFC5654].
   The characteristics of an MPLS-TP LSP are primarily that it:

   1.  Uses a subset of the MPLS OAM tools defined as described in
       [I-D.ietf-mpls-tp-oam-framework].

   2.  Supports 1+1, 1:1, and 1:N protection functions.

   3.  Is traffic engineered.

   4.  May be established and maintained via the management plane, or
       using GMPLS protocols when a control plane is used.

   5.  Is either point-to-point or point-to-multipoint.  Multipoint-to-
       point and multipoint-to-multipoint LSPs are not supported.

[ ... much later ... ]

3.2.  Scope of the MPLS Transport Profile

   Figure 1 illustrates the scope of MPLS-TP.  MPLS-TP solutions are
   primarily intended for packet transport applications.  MPLS-TP is a
   strict subset of MPLS, and comprises only those functions that are
   necessary to meet the requirements of [RFC5654].  This includes MPLS
   functions that were defined prior to [RFC5654] but that meet the
   requirements of [RFC5654], together with additional functions defined
   to meet those requirements.  Some MPLS functions defined before
   [RFC5654] such as Equal Cost Multi-Path, LDP signaling used in such a
   way that it creates multipoint-to-point LSPs, and IP forwarding in
   the data plane are explicitly excluded from MPLS-TP by that
   requirements specification.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 14 Apr 2010 09:00:09 +0300

Curtis,
Lots of thanks for the clarification.

I must admit that I do not read the two text fragments that you're quoting as prohibiting LAN (mp2mp) interfaces in MPLS-TP. They only exclude "transport paths". And RFC 5654 states that:
<quote>
   Transport Path: A network connection as defined in G.805
   [ITU.G805.2000].  In an MPLS-TP environment, a transport path
   corresponds to an LSP or a PW.
<end quote>

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 14, 2010 8:29 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; BUSI ITALO
Subject: Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces? 

Sasha,

Curtis

[ ... much later ... ]

[ ... much later ... ]

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Apr 2010 02:09:17 -0400

In message <[email-masked]>
> those cases or are you referring to cases with MPLS(-TP) included?

No MPLS(-TP) in this case.

> > > stac=

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 14 Apr 2010 10:46:56 +0200

Curtis,

Are we mixing up the type of media (p2p, p2mp, mp2mp) with the type of
MPLS-TP transport paths (p2p, p2mp only) that can run over the media?

The following combinations are possible:

1) p2p MPLS-TP transport path over p2p media
2) p2p MPLS-TP transport path over p2mp media (not bandwidth efficient
however)
3) p2p MPLS-TP transport path over mp2mp media
4) p2mp MPLS-TP transport path over p2p media (multiple instances)
5) p2mp MPLS-TP transport path over p2mp media
6) p2mp MPLS-tp transport path over mp2mp media.

mp2mp media is either an n-port (n>=3) 802.3 CSMA/CD LAN or mp2mp VLAN.

1,2,4,5 are applicable combinations in my understanding.
I do not understand the rationale to deploy 3 or 6 in a MPLS-TP network.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Curtis Villamizar
Sent: woensdag 14 april 2010 7:29
To: Alexander Vainshtein
Cc: [email-masked]; BUSI ITALO
Subject: Re: [mpls-tp] Can MPLS-TP Section OAM be used on LAN interfaces?

In message
<[email-masked]>
Alexander Vainshtein writes:
> Could you possibly point to a specific part of the framework draft that
suggests that mp2mp interfaces are out of scope of MPLS-TP?
>  
> My read of the data plane draft (e.g., the discussion of using well-known
multicast address on Ethernet  links which is explicitly restricted to p2p)
is that the alternative is in scope as well.
>  
> But, again, this is a personal impression, and IMO we need a clear
resolution - one way or another. Because, as you've stated in your previous
email, somebody already uses mp2mp media in MPLS-TP... Or did I read this
wrong?

Sasha,

Curtis

[ ... much later ... ]

[ ... much later ... ]

> <[email-masked]
> om>
> "BUSI ITALO" writes:
> >
> >
> > Sasha,
> > =20
> > thanks for your reply.
> > =20
> > Regarding p2mp media, how would you consider a scenario where 
> > MPLS-TP is = running over p2mp SDH VC?
> > =20
> > I understood the rough consensus is not to preclude running MPLS-TP 
> > over = mp2mp media.
> > =20
> > If my understanding regarding the rough consensus is correct, I 
> > agree = with you that we need to document/resolve all the associated 
> > technical = issues.
> > =20
> > On my side, if would be fine to clearly state that MPLS-TP Section 
> > OAM = MUST NOT be used on mp2mp media.
> > =20
> > agree = with you that we need to explicity document that MPLS-TP 
> > MUST NOT run = over mp2mp media.
> > =20
> > Italo
> >
> >
> > [email-masked], = effective since 1 November 2009.
>  
>  
>

---

From: <[email-masked]>
Date: Wed, 14 Apr 2010 10:33:43 +0100

I agree with you Maarten.  If one wants MPLS-TP to provide a
deterministic resource management transport service then it must only
serve its clients with p2p and p2mp constructs (this is a necessary
condition, there is a further sufficiency condition on overbooking of
resource).

However, because MPLS-TP is not Bottom-Of-Stack it cannot 'run on the
wire', and so it requires a further server network technology that
can...like SDH, OTN or even Ethernet.  But we must also note that from
performance inheritance considerations unless all server layer networks
below MPLS-TP are co-cs or co-ps mode (co-cs emulation) in nature then
this will undermine the whole point of restricting MPLS-TP to p2p and
p2mp constructs in the first place!

So if one runs MPLS-TP over mp2p or mp2mp server layer networks, as
Curtis suggests some folks already do, then one might as well not bother
doing MPLS-TP at all.

regards, Neil

> Sent: 14 April 2010 09:47
> To: [email-masked]; 'Alexander Vainshtein'
> Are we mixing up the type of media (p2p, p2mp, mp2mp) with 
> the type of MPLS-TP transport paths (p2p, p2mp only) that can 
> run over the media?
> 
> [mailto:[email-masked]] On Behalf Of Curtis Villamizar
> multicast address on Ethernet  links which is explicitly 
> restricted to p2p) is that the alternative is in scope as well.
> >  
> resolution - one way or another. Because, as you've stated in 
> your previous email, somebody already uses mp2mp media in 
> MPLS-TP... Or did I read this wrong?
> >  
> > Regards,
> >      Sasha
> 
> 
> Sasha,
>

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 15 Apr 2010 22:43:38 -0400

In message <[email-masked]>

Sasha,

TE on an Ethernet with more than two LSR has always been problematic.

Also an RFC4448 Ethernet PW is strictly point to point.

  RFC4448:

         Figure 1: PWE3 Ethernet/VLAN Interface Reference Configuration

   The "emulated service" shown in Figure 1 is, strictly speaking, a
   bridged LAN; the PEs have MAC interfaces, consume MAC control frames,
   etc.  However, the procedures specified herein only support the case
   in which there are two CEs on the "emulated LAN".  Hence we refer to
   this service as "emulated point-to-point Ethernet".  Specification of
   the procedures for using pseudowires to emulate LANs with more than
   two CEs are out of the scope of the current document.

Of course out of scope for RFC4448 may be in scope for L2VPN, or L3VPN
work.  RFC4448 behaviour is often specified for core with the stuff
like VPLS specified for edge.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 15 Apr 2010 22:57:08 -0400

In message <[email-masked]>
[email-masked] writes:
> Curtis suggests some folks already do, then one might as well not
> bother doing MPLS-TP at all.
>  
> regards, Neil

I have made no such suggestion.

Curtis

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 16 Apr 2010 09:59:16 +0300

Curtis,
Lots of thanks for a prompt response.

I think we are discussing two somewhat different questions:

1. Do MPLS-TP standards allow or prohibit running MPLS-TP over  mp2mp (LAN) interfaces?
    And, in the case they do not prohibit this, do they fully address the resulting issues?
    IMHO and FWIW, there is no explicit prohibition, while certain related issues remain unresolved.

2. Does it make operational sense to deploy MPLS-TP over mp2mp (LAN) interfaces
    (assuming hat the standards do not explicitly prohibit this)?
    I agree with you that this makes TE problematic. At the same time, there are
    potential not-so-technical advantages (reuse of existing infrastructure, cost of aggregation
    and replication etc.) .  And, IMHO and FWIW, as long as this remains a gray area from the point
    of view of the standard, there will be attempts to do exactly that - and the theoretical open 
    issues mentioned in my Item 1 above will become very practical ones. (Of course, there is a
    good chance some people will do it even if the standards explicitly prohibit that, but at least, they
    would be warned that they are doing something not kosher.)

I am simply trying to resolve (one way or another) the first issue. 

My 2c,
     Sasha

Sent: Friday, April 16, 2010 5:43 AM

Sasha,

  RFC4448:

Curtis

---

From: <[email-masked]>
Date: Fri, 16 Apr 2010 10:42:54 +0100

Thanks Curtis for clarifying....I picked this up from Sasha's mail.
regards, Neil 

> Sent: 16 April 2010 03:57
> To: Harrison,N,Neil,DKQ7 R
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; 
> [email-masked]; [email-masked]
> <[email-masked]
> .systemhost.net>

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 22 Apr 2010 12:44:39 +0200

Sasha, Curtis,

thanks a lot for this useful discussion.

I agree that we need to resolve the two questions in Sasha's mail below.

I think it would be useful to get some SP input about the need to run MPLS-TP over LAN interfaces.

Thanks, Italo

> Sent: venerdì 16 aprile 2010 8.59
> To: [email-masked]
>     IMHO and FWIW, there is no explicit prohibition, while 
> certain related issues remain unresolved.
> 
>     good chance some people will do it even if the standards 
> explicitly prohibit that, but at least, they
> <[email-masked]>
> > I must admit that I do not read the two text fragments that 
> you're quoting as prohibiting LAN (mp2mp) interfaces in 
> MPLS-TP. They only exclude "transport paths". And RFC 5654 
> states that:
> > <quote>
> Of course out of scope for RFC4448 may be in scope for L2VPN, 
> or L3VPN work.  RFC4448 behaviour is often specified for core 
> with the stuff like VPLS specified for edge.
> 
> Curtis
> 
> 
> > > Could you possibly point to a specific part of the 
> framework draft that suggests that mp2mp interfaces are out 
> of scope of MPLS-TP?
> > >
> > > My read of the data plane draft (e.g., the discussion of 
> using well-known multicast address on Ethernet  links which 
> is explicitly restricted to p2p) is that the alternative is 
> in scope as well.
> > >
> > > But, again, this is a personal impression, and IMO we 
> need a clear resolution - one way or another. Because, as 
> you've stated in your previous email, somebody already uses 
> mp2mp media in MPLS-TP... Or did I read this wrong?
> > >
> > > Regards,
> > >      Sasha
> >
> >
> > Sasha,
> >
> <[email-masked]
> > > .com>
> > > "BUSI ITALO" writes:
> > > >
> > > >
> > > > Sasha,
> > > > =20
> > > > thanks for your reply.
> > > > =20
> > > > I understood the rough consensus is not to preclude running 
> > > > MPLS-TP over = mp2mp media.
> > > > =20
> > > > agree = with you that we need to document/resolve all the 
> > > > associated technical = issues.
> > > > =20
> incorrect, I 
> > > My read of the framework is that mp2mp is not forbidden 
> but is out 
> > > of scope for MPLS-TP.  That puts it in the realm of 
> possible future work.
> > >
> > > Curtis