AW: Regarding draft-wijnands-mpls-mldp-csc-01

[<N.Leymann at telekom.de>]

Hi,

 

I'm also in favor of keeping the work in a single draft. The draft is quiete

small (and simple) and I think it's a  good idea to keep the procedures

in line in a single document.

 

  regards

 

    Nic

---

Von: l3vpn-bounces at ietf.org [mailto:l3vpn-bounces at ietf.org] Im Auftrag von Fil Dickinson
Gesendet: Montag, 21. September 2009 04:52
An: IJsbrand Wijnands
Cc: mpls at ietf.org; l3vpn at ietf.org
Betreff: Re: Regarding draft-wijnands-mpls-mldp-csc-01

Hi Ice,

I agree with Yakov that the VPN method belongs in the L3VPN WG, however I am happy to support your suggestion (of maintaining a single document across the groups and developing within the MPLS WG) if the following is true:

1) There are no alternatives that provide a better outcome to provide the same functionality for the L3VPN case.

2) Prior to last call across the WG's, all significant work developed in the MPLS WG on the L3VPN solution is presented and robustly discussed with the L3VPN WG so that things do not get delayed late in the process.

 

On the draft itself, personally I like the simplicity of the proposal and think that keeping the solution to both non-L3 and L3 aligned is a good thing.

 

Cheers

On Fri, Sep 18, 2009 at 6:06 PM, IJsbrand Wijnands <ice at cisco.com> wrote:

Dear WG,

I like to get some input from the WG regarding draft-wijnands-mpls-mldp-csc-01.

I presented this draft in MPLS WG at IETF in Stockholm and got the comments from Yakov that this document contains work that belongs in L3VPN. It was suggested this document should be split in 2 different drafts, a non-L3VPN specific draft and a L3VPN specific draft.

Considering how small the draft is and how close the non-L3VPN and L3VPN procedures are, I would prefer to keep this one draft. We can do a last call in both WG's and present it in L3VPN, but we do the work in MPLS.

I would appreciate if you voice your opinion, after reading the draft :-)

Thx,

Ice.

Appendix:

This is small explanation on why procedures in section 3.1, 3.2 are considered to be L3VPN. The draft describes a procedure to use a Recursive Opaque encoding to help an mLDP LSP traverse a MPLS core that does not have reachability to the root of an LSP. Using the recursive Opaque encoding you temporarily replace the original FEC with a new FEC that has a root that is reachable. This procedure is useful in the VPN context and in the non-VPN context. The only difference is that you add an RD to the encoding for LSP's are that originated in the VPN context.