Subject: [mpls] A comment on draft-fbb-mpls-tp-ethernet-addressing-00 and draft-fbb-mpls-gach-adv

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 12 Nov 2011 10:47:47 +0200

Dan, Stewart, Matthew and all,
I have a comment on draft-fbb-mpls-tp-ethernet-addressing and draft-fbb-mpls-gach-adv. It stems from my reservations regarding the following text in the Section 2 "P2P Link Addressing" of  draft-fbb-mpls-tp-ethernet-addressing:

The approach which SHOULD be used, in view of these considerations,

is therefore to use as the destination MAC address an Ethernet
multicast address reserved for MPLS-TP for use over point-to-point
links.  The address allocated for this purpose by the Internet
Assigned Numbers Authority (IANA) is 01-00-5E-XX-XX-XX.  An MPLS-TP
implementation MUST process Ethernet frames received over a point-to-
point link with this destination MAC address by default.

The address allocated for this purpose by the Internet
Assigned Numbers Authority (IANA) is 01-00-5E-XX-XX-XX.  An MPLS-TP
implementation MUST process Ethernet frames received over a point-to-
point link with this destination MAC address by default.

The problem, as I see it, is that in certain cases the operator of the MPLS-TP node does not know whether the link in question is a P2P link or an MP2MP one. E.g., consider the case when several MPLS-TP islands are interconnected over an IP/MPLS core using an Ethernet service provided in this core. Further consider the case when the application for this interconnection requires only "hub-and-spoke" connectivity. s that the spoke NEs only see a single hub peer behind their (seemingly P2P) Ethernet link. However, the actual connectivity between the hub and the spokes could be provided by the operator of the IP/MPLS core in two different ways:

 *
As a bunch of P2P Ethernet PWs, each of them using a dedicated VLAN as its AC at the hub side, and the entire port as its AC at the spoke side
 *
As a single VPLS service using the entire port as its AC at each side.

It is worth noticing that the IP/MPLS core operator could change the type of connectivity it provides for interconnection of the MPLS-TP islands, and the spoke nodes should remain completely unaware of that fact - unless they have been using multicast Ethernet addressing for the traffic they have been sending to the hub node.

At the same time it is clear that MPLS-TP nodes MUST accept Ethernet frames with the reserved (well-known) multicast address for the G-ACh Advertisement Protocol (draft-fbb-mpls-gach-adv) to work properly.

Hence I would suggest the following changes to the two drafts:

 1.  Move the definition of the well-known multicast MAC Address for MPLS-TP from draft-fbb-mpls-tp-ethernet-addressing  to draft-fbb-mpls-gach-adv
 2.  Specify that G-ACH Advertisement protocol MUST use this address as the destination MAC address when it runs over Ethernet links
 3.  In draft-fbb-mpls-tp-ethernet-addressing:
    *   Indicate that using the well-known multicast MAC Address for MPLS-TP for the non-G-ACh traffic, while possible, is NOT RECOMMENDED due to the fragile nature of the P2P vs. P2MP link nature
    *   Indicate that support of the G-ACh Advertisement protocol is RECOMMENDED in MPLS-TP using Ethernet links
    *   Indicate that using the MAC address of the intended peer port (whether statically configured or discovered via any means including the G-ACh Advertisement protocol), in addition to being MANDATORY on MP2MP links is RECOMMENDED also on links presumed to be P2P.

Hopefully these notes will be useful.

Regards,

     Sasha

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Dan Frost <[email-masked]>
Date: Sun, 13 Nov 2011 15:56:00 +0000

Hi Sasha,

On Sat, Nov 12, 2011 at 10:47:47AM +0200, Alexander Vainshtein wrote:
> ...
> The problem, as I see it, is that in certain cases the operator of the
> MPLS-TP node does not know whether the link in question is a P2P link
> or an MP2MP one.

To quote Section 2 of the ethernet-addressing draft:

   The use of broadcast or multicast addressing is applicable only when
   the attached Ethernet link is known to be point-to-point.  If a link
   is not known to be point-to-point, these forms of addressing MUST NOT
   be used.

So in situations such as those you describe, where the operator is not
certain a link is and will remain point-to-point, it is considered
multipoint by default.

Cheers,

-d

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 13 Nov 2011 18:23:55 +0200

Dan,
Lots of thanks for a prompt response.

As I see it, there are two different aspects of Ethernet addressing for MPLS-TP:
- addressing used by the "transport applications"
- addressing used by various "helper protocols" (including G-ACh  Advertisement protocol).

With the two drafts as today this differentiation is not clear. E.g., suppose that the operator intends to run MPLS-TP over a link that is not known to be a P2P one, and cannot use ARP over this link to resolve MAC address(es) of the potential MPLS-TP peers reachable via this link.

The text from Section 2 which you quote says that multicast addressing MUST NOT be used with MPLS-TP. If interpreted strictly, this can be understood as a prohibition to use it also for the G-Ach-based advertisement protocol because it does not really differ from any other MPLS-TP traffic.

Hence the need (as I see it) to refactor the two drafts in such a way that the G-Ach advertisement protocol over Ethernet links would (if used) always use the well-known multicast address. In order to achieve that this address must be defined in the draft that defines the G-Ach advertisement protocol, and its usage with this protocol MUST be allowed on all types of links. 

When it comes to transport applications - IMHO and FWIW a link that has been a P2P one yesterday may easily become a P2MP link tomorrow.
Hence it seems useful to me to stress that while multicast addressing MAY be used by the transport applications on kinks known to be P2P, it is still NOT RECOMMENDED. 

Hopefully this clarifies my position.

Regards,
     Sasha

> -----Original Message-----
> From: Dan Frost [mailto:[email-masked]]
> Sent: Sunday, November 13, 2011 5:56 PM
> To: Alexander Vainshtein
> Cc: Stewart Bryant ([email-masked]); matthew.bocci@alcatel-
> lucent.com; [email-masked]; Mishael Wexler; Rotem Cohen; Gideon Agmon;
> Andrew Sergeev; Vladimir Kleiner; Yaniv Tsabari; Oded Mann
> Subject: Re: A comment on draft-fbb-mpls-tp-ethernet-addressing-00 and
> draft-fbb-mpls-gach-adv
> 
> Hi Sasha,
>

---

From: Dan Frost <[email-masked]>
Date: Sun, 13 Nov 2011 22:11:13 +0000

Hi Sasha,

On Sun, Nov 13, 2011 at 06:23:55PM +0200, Alexander Vainshtein wrote:
> With the two drafts as today this differentiation is not clear. E.g.,
> suppose that the operator intends to run MPLS-TP over a link that is
> not known to be a P2P one, and cannot use ARP over this link to
> resolve MAC address(es) of the potential MPLS-TP peers reachable via
> this link.
> 
> The text from Section 2 which you quote says that multicast addressing
> MUST NOT be used with MPLS-TP. If interpreted strictly, this can be
> understood as a prohibition to use it also for the G-Ach-based
> advertisement protocol because it does not really differ from any
> other MPLS-TP traffic.

That's not the intent.  The last paragraph of Section 2 is intended to
refer only to use of the multicast address defined in that section.  We
can certainly clarify this.

> Hence the need (as I see it) to refactor the two drafts in such a way
> that the G-Ach advertisement protocol over Ethernet links would (if
> used) always use the well-known multicast address. In order to achieve
> that this address must be defined in the draft that defines the G-Ach
> advertisement protocol, and its usage with this protocol MUST be
> allowed on all types of links. 

This is already the case.  Section 7 of the GAP draft defines the
Ethernet multicast address used by the GAP and places no restrictions on
the link type.

> When it comes to transport applications - IMHO and FWIW a link that
> has been a P2P one yesterday may easily become a P2MP link tomorrow.
> Hence it seems useful to me to stress that while multicast addressing
> MAY be used by the transport applications on kinks known to be P2P, it
> is still NOT RECOMMENDED. 

I'm not sure I'd state it quite this way, but I agree that it would at
least be good to stress this potential pitfall of the point-to-point
multicast address.

Cheers,

-d

> Regards, Sasha