Re: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00

Alexander Vainshtein wrote:
> Stewart, Dan, Matthew and all,
> First of all I'd like to say that the need for clear-cut definition of 
> the MPLS-TP data plane architecture has been quite clear to me.
> The draft is clearly the necessary first step in the right direction, 
> and I thank you for producing it.
>  
> That said, I think that quite a few issues have been left undecided in 
> this -00 version of the draft.
>  
> I will make a (hopefully, short) list of items that IMHO require 
> additional clarification and, eventually, codification.
>  
>
>    1. *LSP Merge*:
>           * In MPLS, nothing prevents LSPs from merging at some point:
>                 o One well-known usage of LSP merge is FRR
>                 o PHP can be considered as a special case of LSP merge
>           * One of the often repeated mantras of MPLS-TP is that its
>             LSPs cannot be merge. 
>           * It is not clear (at least, to me):
>                 o Whether this limitation has to be respected at the
>                   data plane level, and if yes, then how
>                 o Whether it means that FRR cannot be used in MPLS-TP
>           * Status of this topic in the -00 draft: not mentioned at all
>
The anti-merging requirement is not explicitly called out in RFC5654. 
However a number of the requirements imply that this is not a supported 
behavior in MPLS-TP.
Merge prevention is not something that can be enforced in the 
data-plane. Indeed the insertion of OAM at an intermediate node is a 
form of merge.

We think all the data-plane specification needs to do is to list the 
supported LSP types and not restrictions on PHP (which is already in the 
text). The control plane / management plane must take responsibility for 
not deliberately creating a merged LSP. The OAM must take responsibility 
for detecting an inadvertent merge.

>    1. *Per-Interface Label Space*:
>           * The draft states that per-interface label space MAY be
>             used in MPLS-TP
>           * AFAIK, in MPLS:
>                 o This referred to data links (including bundles,
>                   e.g., produced by LAG). As a consequence, the number
>                   of label contexts has been reasonably low
>                 o This has been only allowed on P2P links
>           * One of the problems with MPLS-TP is that in many cases it
>             does not differentiate between data links and lower layer
>             LSPs (see also my notes regarding Sections). As a
>             consequence, it is not clear (to me) whether per-interface
>             label space may become a label space per lower layer LSP.
>             (To the best of my understanding this is explicitly
>             prohibited by RFC 3031).
>           * Status of this topic in the -00 draft: requires
>             clarification, preferably aligned with RFC 3031.
>
See the responses to the next set of questions.

>    1. *Sections*:
>           * The draft states that Sections could be data links (level
>             0 sections) or LSPs with N labels (level N Sections).
>           * The following is not clear to me:
>                 o Can LAN-like data links be Sections in MPLS-TP (The
>                   Editors ask this question themselves when they
>                   discuss MAC addresses)
>
Yes, but the LSP can require certain semantics from the LAN data link.
For example a p2p LSP can require p2p semantics from the LAN. How this 
achieved outside the scope of MPLS-TP, but one could imagine that this 
was provided through the use of unicast addresses, or through a port to 
port cross connect, in which case p2p connectivity is provided even when 
m/c data link addresses are used.

In the case of a p2mp LSP, this map be serviced by  replication in the 
upstream LSR in conjunction with some number of p2p sections, or through 
the use of a p2mp section such as that provided through the use of 
multicast data link addresses. Again although MPLS-TP may specify a type 
of service from the LAN, how this service is provided is outside the 
scope of MPLS-TP.

We will add some text to this effect to the draft.
>
>                 o Which types of LSPs can be Sections (e.g., can a P2P
>                   unidirectional LSP be a Section? Can an associated
>                   bi-directional LSP be a section? etc.).
>
A section must provide the service required by the client LSP. The 
services that a client may require of the section layer are:

- p2p bi-directional
- p2p unidirectional
- p2mp unidirectional

i.e. any LSP can provide section layer connectivity provided that it 
delivers the service that the client requires.
>
>                 o If associated bi-directional LSPs can be Sections,
>                   can we treat the LSPs rumming over these Sections as
>                   co-routed bidirectional?
>
Yes, because co-routed is a requirement pertaining to the client layer 
and says nothing about the internals of the server layer.
>
>                 o Per-data link (interface) label space is supported
>                   in MPLS. Does MPLS-Tp allow per-Section label space
>                   (see above)?
>
It is neither required nor is it precluded.
>
>           * Status of this topic in the -00 draft: requires
>             clarification, one aspect already recognized as such by
>             the Editors. IMHO and FWIW preferred resolution would
>             be to equate Sections with data links
>

>    1. *Label Allocation Schemes*:
>           * MPLS recognizes two label allocation schemes, each with
>             its own area of applicability:
>                 o Downstream label allocation as per RFC 3031
>                 o Upstream label allocation as per RFC 5331
>           * IMHO the label allocation scheme is essentially a data
>             plane issue:
>                 o Label allocation scheme is reflected in the
>                   Ethertype in the case of Ethernet encapsulation etc.
>                 o Packets with invalid labels must be silently
>                   discarded etc.
>           * It is not clear to me, which label allocation schemes can
>             be used in MPLS-TP.
>
Any MPLS label allocation scheme may be used. We assume that RFC3031 
schemes will be used for p2p and RFC5331 schemes will be used for p2mp.

>          *
>
>
>                 o This includes applicability of these schemes, e.g.,
>                   can we use upstream label allocation
>                 o This issue is closely related to proposed usage of a
>                   well-known multicast MAC destination address for P2P
>                   LSPs)
>
Yes, we will get to that next.
>
>           * Status of this topic in the -00 draft: requires clarification
>    1. *MAC addresses on Ethernet data links in MPLS-TP*:
>           * The draft discusses this topic, and proposes using a
>             well-known multicast DA in Ethernet encapsulations for for
>             P2P LSPs
>
The problem we are facing here is that we do not have IP and ARP to 
bootstrap the link in the normal way, and yet we wished to avoid the 
need to configure datalink addresses statically. Manual configuration of 
data link addresses is a particular problem when a service provider 
makes a hardware repair and then requires a distant service provider to 
reflect this in their configuration to bring the link back into service.

>           * IMHO and FWIW if LAN interfaces are allowed in MPLS-TP,
>             usage of  well-known multicast DA is not compatible with
>             the downstream label allocation scheme.
>
We do not understand the conflict between  m/c DA and downstream label 
assignment. Did you mean p2mp MPLS encap over Ethernet as defined in 
RFC5332? Note that in the P2MP case RFC5332 describes how to construct 
the data link address (for Ethernet).

We were proposing  the well known m/c DA scheme in the context of p2p 
operation between a directly connected pair of LSR and not any form of 
p2mp operation either at the data link level or the LSP level, i.e. we 
exclude the shared LAN and the p2mp LSP case. We should add text to that 
effect.

The alternative approach would be to strike the well known m/c text and 
just use static data link addresses for this document and punt the issue 
of zero config for the (common) restricted case of direct connection 
p2p, and the issue of "ARP for TP" to another document.
>
>           * Status of this topic in the -00-draft: partially
>             recognized by the Editors, there seems to be a bug in the
>             proposed solution.
>
> Hopefully, these notes will be useful.
Thanks for these comments we will take the actions described above.

- Stewart & Dan

>  
> Regards,
>      Sasha
>
>           *  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>   

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html