Re: [Mpls-interop] MPLS over MPLS-TP

Quite agree with Andy's points on 
- service provided by an MPLS-TP network should be general
- clear demarcation is needed, especially from the operation point of
view as the reasons c, d, Adrian stated.
> Plus in the future we may wish to offer MPLS-TP as a customer-facing
interface, with customers using it to interconnect their own IP/MPLS
routers. 

I think these points are consistent with the requirements draft.

Thanks,
Luyuan 

-----Original Message-----
From: mpls-interop-bounces@ietf.org
[mailto:mpls-interop-bounces@ietf.org] On Behalf Of Malis, Andrew G.
(Andy)
Sent: 11 December 2008 08:51
To: Adrian Farrel
Cc: mpls-interop@ietf.org
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Adrian,

Thanks for the clarification, but doesn't change my points about
generality of the MPLS-TP service.

Thanks,
Andy

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Thursday, December 11, 2008 8:40 AM
To: Malis, Andrew G. (Andy)
Cc: mpls-interop@ietf.org
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Thanks Andy,

Just one point.
My understanding of the PW usage is that an EOS has to be present.
That means that the choice (when there is demarcation) is between PW and
no PW. EOS would always be there.

A
----- Original Message -----
From: "Malis, Andrew G. (Andy)" <andrew.g.malis@verizon.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>uk>; "Drake, John E" 
<John.E.Drake2@boeing.com>om>; "Ben Niven-Jenkins" 
<benjamin.niven-jenkins@bt.com>om>; <mpls-interop@ietf.org>
Sent: Thursday, December 11, 2008 1:30 PM
Subject: RE: [Mpls-interop] MPLS over MPLS-TP

Adrian,

Thanks for taking the discussion in Geneva to the list. I have some
comments inline.

Cheers,
Andy

-----Original Message-----
From: mpls-interop-bounces@ietf.org
[mailto:mpls-interop-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Thursday, December 11, 2008 5:35 AM
To: Drake, John E; Ben Niven-Jenkins; mpls-interop@ietf.org
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Hi,

We have had considerable debate about this in Geneva.
(I think it is probably time to take this discussion to mpls-tp, so I
will
recreate the thread there).

Some data points for this discussion are:

1. What is the service provided by an MPLS-TP network?
Is it (as described in some documents) the provision of pseudowires over
an
MPLS transport network?
Or is it the provision of services (including pseudowires) over an MPLS
transport network?

AM> My preference is the latter - it should be more general than just
the provisioning of pseudowires (even if we have IP and MPLS
pseudowires). A PW is an instance of a label in the stack, and what can
be transported over MPLS-TP shouldn't be limited to just that instance.

2. It there a need to provide demarcation between server traffic and
client
traffic?
There seem to be several reasons why one might do this:
a. architectural beauty
b. consistency with the answer to point 1
   (depending on the answer!)
c. ease of OAM and general management
  (so you can see the demarcation when you sniff the network)
d. To avoid accidental misforwarding of traffic
  For example, consider an MPLS-TP network operated using
  the management plane. In this network it is possible that an
  LSR along the path of an LSP is misconfigured to pop the
  MPLS-TP LSP top label. If what is found underneath is
  either a label from the client label space, or is treated as a label
  (in the case where the payload is IP) we will not spot an error,
  but may misforward traffic.

AM> Yes, we need a clear demarcation, for reasons c and d. Here in VZ,
our current discussions are around using IP/MPLS as an overlay over
MPLS-TP, with different groups in charge of the management of each
layer, thus maintaining our current layer separation. Plus in the future
we may wish to offer MPLS-TP as a customer-facing interface, with
customers using it to interconnect their own IP/MPLS routers.

3. If there is demarcation as suggested in point 2, what is the best way
to
provide demarcation?
a. Encode as a PW with the end of stack set and a PW header according to
the
appropriate PW encoding type.
b. Simply use the end of stack bit to say that we have reached the
bottom of
the MPLS-TP label stack.
(The alternative clearly being that the label stack runs through from
the
client label stack to the server label stack.)

AM> I prefer b, for simplicity and generality of what can be carried
over MPLS-TP. Thus we could have a label stack with two EOS bits set.

AM> Also, regarding the possible misconfiguration discussed in question
2, this could happen with PW labels as easily as with non-PW labels, so
requiring PWs to be used with MPLS-TP is no panacea. Rather, this sort
of misconfiguration needs to be detected using OAM and other MPLS-TP
layer management mechanisms.

Cheers,
Andy

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