Subject: Re: [mpls-tp] -03 of requirements draft & actions still to be resolved

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 02 Feb 2009 22:34:24 +0000

Maarten,

I am not sure what the Transport Service Layer is below.  The requirements
are for MPLS-TP technology, not for MPLS-TP services built using MPLS-TP
technology. Therefore I do not see your proposed requirements as in scope
for the document.

For example one could use MPLS-TP to build MP2MP or RMP VPLS that is outside
the scope of this requirements document, however I believe the existing
requirements adequately cover such that MPLS-TP can be used to efficiently
support such services.

Ben

On 30/01/2009 14:34, "Maarten Vissers" <[email-masked]> wrote:

> Ben,
> 
> I would like to have the following requirements added to the document:
> 
> Section 2.1:
> 
>    A   Mechanisms and capabilities MUST be able to interoperate at the
> Transport
> Service Layer, with a minimal gateway function capable to translate
> packet/frame
>        headers, with existing Ethernet VLAN data planes where appropriate.
> 
>    B   MPLS-TP MUST support traffic engineered multipoint to multipoint
> (MP2MP) and
>        rooted multipoint (RMP) transport paths in its Transport Service
> Layer to
> support E-TREE and E-LAN services.
> 
>    C   MPLS-TP MUST support transport paths at the Transport Service Layer
> through
> multiple heterogenous domains (Ethernet, MPLS-TP).
> 
> These requirements make sure that the 'MPLS-TP solution' will be able to:
> 
> - support all service types, including the mp2mp and rmp E-LAN and E-TREE
> type services, and
> 
> - interoperate in today's multi-technology packet transport network
> environment in which Ethernet is significantly present and Service VLANs are
> used in the Transport Service Layer within Ethernet domains to support p2p,
> p2mp, rmp and mp2mp services.
> 
> Complying with those requirements prevents that unnecessary layers will be
> present in MPLS-TP domains to support UNI-to-UNI service monitoring.
> 
> Regards,
> Maarten
> 

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 02 Feb 2009 22:37:57 +0000

Maarten,

IMO it means that the transport path's destination must know who the source
for that transport path is supposed to be so that for e.g. If it receives
traffic from another source it can identify a defect.

Ben

On 30/01/2009 14:43, "Maarten Vissers" <[email-masked]> wrote:

> Ben,
> 
> Can you clarify for me the intention behind data plane requirement 27: "A
> transport path's source MUST be identifiable at its destination within its
> layer network.". Specifically, to what level this identification is
> required?
> 
> The label in the data plane represents under fault free conditions the
> source-destination information; the specific source and destination
> identifiers (the so called "Access Point Identifiers") are hold in the
> management plane, not in the data plane however. During fault conditions,
> e.g. configuration faults in the network, the label at the destination node
> not longer identifies the intended source.
> 
> Regards,
> Maarten
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 02 Feb 2009 22:40:43 +0000

Maarten,

It is a bidirectional path where the end points (but not necessarily any
other points along each direction of the path) are aware of the association.
Remote Defect/Error Information exchange between the two end points is
optional but not prohibited.

Ben

On 30/01/2009 14:52, "Maarten Vissers" <[email-masked]> wrote:

> Ben,
> 
> Can you describe how we should treat "associated unidirectional paths" from
> an OAM perspective?
> 
> Should such path be treated as two independent unidirectional paths, in
> which case there is no Remote Defect/Error Information to exchange between
> the two endpoints? Additionally, any tandem connection monitoring will only
> be unidirectional as the other direction of such associated unidir paths
> will not pass through the same nodes.
> 
> Or, should such path still support Remote Defect/Error Information between
> the two endpoints of this path?
> 
> Note that SNC type protection switching of the 1:1 type will not be able to
> work on such associated unidir paths as such protection requires APS signals
> to flow over both direction of the path.
> 
> Regards,
> Maarten
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 03 Feb 2009 02:23:21 +0000

Rolf,

Thanks for the comments.

On 29/01/2009 10:45, "Rolf Winter" <[email-masked]> wrote:
> Very detailed set of requirements. I sometimes have the feeling that a bunch
> of these can be condensed for clarity but I need at least one more pass over
> the document to make a (good) suggestion.

Such is the by product of documentation by committee (or two committees in
this case).

> Some more detailed comments on the requirements draft:
> 
> Requirement 4:
> 
> I find this requirement odd, after all this is what a standard is for. I know
> that this is not the situation in the optical space where equipment from
> different vendors does not get along and similar issues exist in 3GPP, but
> spelling this out in this way seems odd. Do you think for MPLS-TP this could
> become an issue as we are aiming for MPLS forwarding compatibility?

"Motherhood and apple pie" has been discussed many times within the MEAD
team.  Conclusion has always been if it does no harm and someone wants it
included then leave it in.

> Requirement 15:
> 
> Why is this SHOULD and not MUST. The requirement itself is written so fuzzily
> that a MUST seems appropriate.

I have no strong preference either way, unless anyone objects I will change
it to a MUST.

> Requirement 18/46:
> 
> Seems rather obvious to me. MPLS-TP needs to be scalable in every aspect. Why
> reiterating this requirement? There are a number of generally applicable
> requirements which I think can be omitted or just mentioned in the main text.

See "Motherhood and apple pie".

> Requirement 33/64/75/90:
> 
> Things that "MAY" are not requirements in my opinion and SHOULD not be
> included. These aspects SHOULD be mentioned in solution drafts.

See "Motherhood and apple pie". It is really about saying "we haven't
overlooked this functionality it's just not a core requirement".

> Requirement 54 c, 55 c:
> 
> Are non-requirements in scope of this document? This list could become long
> but I generally see that in those places they are there for completeness sake,
> right?

Yes, they're just there for completeness. I probably need to drop them into
lowercase as the idnits script complains that NOT REQUIRED is not defined in
RFC2119.

Ben