[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Regarding draft-wijnands-mpls-mldp-csc-01
Fil,
> 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.
There was no discussion in L3VPN WG on this topic.
> 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.
There is nothing to prevent the alignment if Section 3 (the VPN related
stuff) will be placed in a separate document.
Yakov.
>
> 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 cal
l
> > 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.
> >
> >
> >
> >
>
> --000e0cd1a62040be9304740d926d
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> <div>Hi Ice,</div>
> <div>I agree with Yakov that the VPN method belongs in the L3VPN WG, howeve=
> r I am happy to support your suggestion (of maintaining a single document a=
> cross the groups and developing within the MPLS WG) if the following is tru=
> e:</div>
>
> <div>1) There are no alternatives that provide a better outcome to provide =
> the same functionality for the L3VPN case.</div>
> <div>2) Prior to last call across the WG's, all significant work develo=
> ped in the MPLS WG on the L3VPN solution is presented and robustly discusse=
> d with the L3VPN WG so that things do not get delayed late in the process.<=
> /div>
>
> <div>=A0</div>
> <div>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.</div>
> <div>=A0</div>
> <div>Cheers<br><br></div>
> <div class=3D"gmail_quote">On Fri, Sep 18, 2009 at 6:06 PM, IJsbrand Wijnan=
> ds <span dir=3D"ltr"><<a href=3D"mailto:ice at cisco.com">ice at cisco.com</a>=
> ></span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
> px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Dear WG,<br><br>I like to get so=
> me input from the WG regarding draft-wijnands-mpls-mldp-csc-01.<br><br>I pr=
> esented this draft in MPLS WG at IETF in Stockholm and got the comments fro=
> m Yakov that this document contains work that belongs in L3VPN. It was sugg=
> ested this document should be split in 2 different drafts, a non-L3VPN spec=
> ific draft and a L3VPN specific draft.<br>
> <br>Considering how small the draft is and how close the non-L3VPN and L3VP=
> N procedures are, I would prefer to keep this one draft. We can do a last c=
> all in both WG's and present it in L3VPN, but we do the work in MPLS.<b=
> r>
> <br>I would appreciate if you voice your opinion, after reading the draft :=
> -)<br><br>Thx,<br><br>Ice.<br><br>Appendix:<br><br>This is small explanatio=
> n on why procedures in section 3.1, 3.2 are considered to be L3VPN. The dra=
> ft 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 origi=
> nal 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.<br>
> <br><br><br></blockquote></div><br>
>
> --000e0cd1a62040be9304740d926d--