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

["Malis, Andrew G. (Andy)" <[e-mail]>]

Jia,

I don't really want to get back into MPLS-TP vs. T-MPLS, but that was really a minor bit at the time compared to other technical points, and that is still the case, which is why it's being discussed now rather than being included as a part of the JWT report.

Cheers,
Andy

-----Original Message-----
From: hejia 48726 [mailto:[e-mail]] 
Sent: Thursday, December 11, 2008 10:47 AM
To: Malis, Andrew G. (Andy)
Cc: Adrian Farrel; [e-mail]
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Hi Andy,
   I guess what you suggest by using "a label stack with two EOS bits set" to realize demarcation was once discussed in MPLS over T-MPLS scenario(ITU-T contribution),as a alternative of PW way (which is valid, but not efficient). But the whole idea was not accepted at that time beacause this was claimed to invalid the existing MPLS architecure. :(



B.R.
Jia

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
 immediately and delete it!
 *****************************************************************************************

----- 原邮件 -----
发件人: "Malis, Andrew G. (Andy)" <[e-mail]>
日期: 星期四, 十二月 11日, 2008 下午9:51
主题: Re: [Mpls-interop] MPLS over MPLS-TP
收件人: Adrian Farrel <[e-mail]>
抄送: [e-mail]

> 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:[e-mail]] 
> Sent: Thursday, December 11, 2008 8:40 AM
> To: Malis, Andrew G. (Andy)
> Cc: [e-mail]
> 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)" <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>uk>; "Drake, John E" 
> <[e-mail]>om>; "Ben Niven-Jenkins" 
> <[e-mail]>om>; <[e-mail]>
> 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: [e-mail]
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Thursday, December 11, 2008 5:35 AM
> To: Drake, John E; Ben Niven-Jenkins; [e-mail]
> 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 
> MPLStransport 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 
> futurewe may wish to offer MPLS-TP as a customer-facing interface, 
> withcustomers 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 
> question2, 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-interop
> 
_______________________________________________
Mpls-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-interop