Re: [Mpls-interop] Who will be in Geneva?

Yes, Italo, you are right.

> I think we need to clarify the concept (irrespectively from the name)
> first, the we can understand the solution and finally we can give an
> appropriate name.
>
> The concept is the following: if I have a connection from A to Z, I
> would like to monitor (from fault and performance management) that
> connection (and only that one) between two intermediate points (let us
> call them I and J).

Good.

I think 1:1 is a special case of 1:n.
There is nothing in the proposal that precludes 1:1 association of 
connection with monitoring entitity (i.e. end-to-end LSP with PST).
But we want to make sure that we have a generic solution defined so that one 
technique (the PST) can be applied to:
- aggregation
- 1:n monitoring
- 1:1 monitoring

> There are many potential solutions to this problem. One solution is to
> rely on the MEG Level, like in Ethernet, but it has some impacts on the
> forwarding plane. In fact it is required that J is able to distinguish
> the OAM packets monitoring the TC (that it has to terminate) and the OAM
> packets monitoring the e2e connections that have to be forwarded like
> user data packets.
>
> In MPLS-TP, there is a clear requirement that the MPLS forwarding
> paradigm, as defined in RFC 3031, MUST not be changed. As a consequence
> the only mechanism I can imagine to solve the TC requirement is the one
> based on label stacking.

That is why we suggest PST (which is just a label stack) and is available to 
satisfy other requirements as well.

> Given the definition of TC, there is a 1:1 mapping between the TC and
> the end-to-end connection the TC refers to.

Yes. That is the definition of a TC that exists in the ITU and I think it 
would be unwise to try to change it.

That is why we suggest to not use the term at all. If we really want to 
continue to refer to a TC, we might add text to say that "operating a PST in 
a 1:1 relationship with the end-to-end LSP achieves the same function as 
that of a TC as specified by the ITU-T"

> The fact that the same mechanism used for tunneling (i.e. label
> stacking) is also used for TCM is just by chance and should not create
> confusion between them. Tunneling and TC are different architectural
> concepts and managed differently.

Agreed completely.
But it is nice to leverage the "just by chance" to make:
- simple implementations
- re-use of toolkit
- harmonized architecture

Have we converged (not merged, because merging is not allowed)?

Adrian

_______________________________________________
Mpls-interop mailing list
Mpls-interop@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-interop