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

[Fil Dickinson <[e-mail]>]

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 <[e-mail]> 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.
>
>
>
>