Subject: [mpls] Regarding draft-wijnands-mpls-mldp-csc-01

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 18 Sep 2009 10:06:08 +0200

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.

---

From: Uwe Joorde <[email-masked]>
Date: Fri, 18 Sep 2009 12:21:02 +0200

Ice,

I fully agree with you, keeping the draft together. In my opinion a
splitting would separate the draft in parts, which belong together and
would slow down the process to get a working group document. This
doesen't mean, that I don't accept Yakov's concerns regarding the
draft at the Stockholm IEFT meeting, but I would vote to keep the
draft as a whole for simplyfication.

Cheers, Uwe Joorde

2009/9/18 IJsbrand Wijnands <[email-masked]>:
> 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:
>
> 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.
>
>
>
>

---

From: <[email-masked]>
Date: Mon, 21 Sep 2009 10:06:19 +0200

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: [email-masked] [mailto:[email-masked]] Im Auftrag
von Fil Dickinson
Gesendet: Montag, 21. September 2009 04:52
An: IJsbrand Wijnands
Cc: [email-masked]; [email-masked]
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 <[email-masked]>
wrote:

	Dear WG,

	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.

	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.

---

From: Fil Dickinson <[email-masked]>
Date: Mon, 21 Sep 2009 12:52:23 +1000

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

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 21 Sep 2009 06:27:33 -0700

Ice,

> I would appreciate if you voice your opinion, after reading the  

The size of the document does not change the fact that section 3
of the document is completely outside the scope of MPLS WG. That
is precisely why I proposed to remove section 3 from the document,
and progress the revised document in MPLS WG.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 21 Sep 2009 06:31:50 -0700

Fil,

> same functionality for the L3VPN case.

There was no discussion in L3VPN WG on this topic.

> think that keeping the solution to both non-L3 and L3 aligned is a good

There is nothing to prevent the alignment if Section 3 (the VPN related
stuff) will be placed in a separate document.

Yakov.

> --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&#39;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">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>=
> &gt;</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&#39;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&#39;s are that originated in =
> the VPN context.<br>
> <br><br><br></blockquote></div><br>
> 
> --000e0cd1a62040be9304740d926d--

---

From: Eric Rosen <[email-masked]>
Date: Mon, 21 Sep 2009 11:24:08 -0400

Keeping all the procedures in one document, and having it presented to and
last called in both WGs, is the best procedure.  This does not violate any
IETF process rules, but it does reduce the overhead involved in preparing,
reviewing, submitting, and publishing the document.  Most importantly, it
makes it easier for future implementers to find the specifications.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 21 Sep 2009 18:51:35 +0200

Yakov,

> and progress the revised document in MPLS WG.

The discussion is not about whether or not there is a L3VPN component  
to it.

The general procedures are very close for both L3 and non-L3  
procedures, so its seems to make sense to keep this one draft.

Thx,

Ice.