Subject: [spring] Comments on Section 3// WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

From: Lizhenbin <[email-masked]>
Date: Thu, 27 Mar 2014 16:26:04 +0000

Alvaro,

Section 3 of draft-previdi-spring-problem-statement presents as follows:

"  The source-based routing model, applied to the MPLS dataplane, offers
   the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE
   to an egress PE, without any other protocol than IGPs (ISIS or OSPF).
   LDP and RSVP-TE signaling protocols are not required."

In my opinion, now the IP network is alway to bear multiple services including unicast and mulitcast. Then LDP does not only mean RFC 5036, but RFC 5036 and mLDP. RSVP-TE does not only mean RFC 3209, but RFC 3209 and P2MP TE. If SR path does not cover multicast, "LDP and RSVP-TE signaling protocols are not required" is just to mislead.

Regards,

Zhenbin(Robin)

> Hi!
>
> This message officially starts the call for adoption for
> draft-previdi-spring-problem-statement.
>
> Please indicate your position about adopting this use cases draft
> by end-of-day on March 27, 2014.
>
> Some additional background:  We had issued a call for adoption for
> draft-filsfils-rtgwg-segment-routing-use-cases-02 back in November.
> From both the discussion at the meeting in Vancouver and on the
> list, there was consensus to adopt.  The authors published
> draft-previdi-spring-problem-statement-00 as a revision to the
> original draft without the solution being present in the use case
> description.
>
> http://tools.ietf.org/html/draft-previdi-spring-problem-statement
>
> Thanks!

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Mar 2014 17:58:12 +0100

Hi Robin,

Please notice that mLDP and LDP have nothing in common as far as protocol
itself. So those are two separate protocols.

The name may be confusing ;)

Cheers,
R.
On Mar 27, 2014 5:26 PM, "Lizhenbin" <[email-masked]> wrote:

> In my opinion, now the IP network is alway to bear multiple services
> including unicast and mulitcast. Then LDP does not only mean RFC 5036, but
> RFC 5036 and mLDP. RSVP-TE does not only mean RFC 3209, but RFC 3209 and
> P2MP TE. If SR path does not cover multicast, "LDP and RSVP-TE signaling
> protocols are not required" is just to mislead.
>
>
>
>
>
> Regards,
>
> Zhenbin(Robin)
>
>
>
>
>
>
>
>
> > Hi!
> >
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
>

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 27 Mar 2014 18:47:33 -0700

Robert,

> itself. So those are two separate protocols.

To put some reality check on your claim, and especially on the part
that "mLDP and LDP have nothing in common as far as protocol itself",
let me point out the following from Section 1 of rfc6388 ("Label
Distribution Protocol Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths"):

                         This document describes extensions to LDP for
   setting up point-to-multipoint (P2MP) and multipoint-to-multipoint
   (MP2MP) LSPs.  

Yakov.

P.S. Just to avoid any further confusion, rfc6388 is the specification
for mLDP.

> --bcaec51827b894d9e804f5997d28
> Content-Type: text/html; charset="ISO-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> <p dir=3D"ltr">Hi Robin,</p>
> <p dir=3D"ltr">Please notice that mLDP and LDP have nothing in common as f
a=
> r as protocol itself. So those are two separate protocols.</p>
> <p dir=3D"ltr">The name may be confusing ;)</p>
> <p dir=3D"ltr">Cheers,<br>
> R.</p>
> <div class=3D"gmail_quote">On Mar 27, 2014 5:26 PM, &quot;Lizhenbin&quot; 
&=
> lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wr
o=
> te:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"mar
g=
> in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 
> 
> 
> 
> 
> <div>
> <div style=3D"direction:ltr;font-size:10pt;font-family:Tahoma">
> <p>Alvaro,</p>
> <p>=A0</p>
> <p>Section 3 of draft-previdi-spring-problem-statement presents as follows
:=
> </p>
> <p>=A0</p>
> <p>&quot;=A0 The source-based routing model, applied to the MPLS dataplane
,=
>  offers<br>
> =A0=A0 the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE
<=
> br>
> =A0=A0 to an egress PE, without any other protocol than IGPs (ISIS or OSPF
)=
> .<br>
> =A0=A0 LDP and RSVP-TE signaling protocols are not required.&quot;</p>
> <p>=A0</p>
> <p>In my opinion, now the IP network is alway to bear multiple services in
c=
> luding unicast and mulitcast. Then LDP does not only mean RFC 5036, but RF
C=
>  5036 and mLDP. RSVP-TE does not only mean RFC 3209, but RFC 3209 and P2MP
 =
> TE. If SR path does not cover multicast,
>  &quot;LDP and RSVP-TE signaling protocols are not required&quot; is just 
t=
> o mislead. =A0</p>
> <p>=A0</p>
> <p>=A0</p>
> <p>Regards,</p>
> <p>Zhenbin(Robin)</p>
> <p>=A0</p>
> <p>=A0</p>
> <p>=A0</p>
> <p><br>
> &gt; Hi!<br>
> &gt; <br>
> &gt; This message officially starts the call for adoption for<br>
> &gt; draft-previdi-spring-problem-statement.<br>
> &gt; <br>
> &gt; Please indicate your position about adopting this use cases draft<br>
> &gt; by end-of-day on March 27, 2014.<br>
> &gt; <br>
> &gt; Some additional background:=A0 We had issued a call for adoption for<
b=
> r>
> &gt; draft-filsfils-rtgwg-segment-routing-use-cases-02 back in November.<b
r=
> >
> &gt; From both the discussion at the meeting in Vancouver and on the<br>
> &gt; list, there was consensus to adopt.=A0 The authors published<br>
> &gt; draft-previdi-spring-problem-statement-00 as a revision to the<br>
> &gt; original draft without the solution being present in the use case<br>
> &gt; description.<br>
> &gt; <br>
> &gt; <a href=3D"http://tools.ietf.org/html/draft-previdi-spring-problem-st
a=
> tement" rel=3D"nofollow" target=3D"_blank">
> http://tools.ietf.org/html/draft-previdi-spring-problem-statement</a><br>
> &gt; <br>
> &gt; Thanks!<br>
> <br>
> </p>
> </div>
> </div>
> 
> <br>_______________________________________________<br>
> spring mailing list<br>
> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <a href=3D"https://www.ietf.org/mailman/listinfo/spring" target=3D"_blank"
>=
> https://www.ietf.org/mailman/listinfo/spring</a><br>
> <br></blockquote></div>
> 
> --bcaec51827b894d9e804f5997d28--
> 
> --===============5384383223427779958==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============5384383223427779958==--

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Mar 2014 10:21:47 +0100

Hi Yakov,

If we are to talk real - let's do it.

mLDP is effectively subset of PIM control plane enhanced to carry MPLS
labels over LDP transport. Unicast LDP control plane procedures have
as I said in my former mail in vast majority nothing in common with
mLDP and vice versa. And I am talking about real implementations and
not RFCs.

If you call using completely different protocol and stuffing it under
LDP umbrella as (LDP extension) that's clearly your choice.

But for the SPRING WG point what matters is that when one can use
segment routing to remove need of unicast LDP it does not mean that
segment routing also needs to artificially rename and assimilate PIM
to claim both unicast and multicast coverage.

In IP networks multicast has already number of practical solutions on
the table to control construction of its distribution trees that I do
not think "extensions" of segment routing are required in this space
at least in this point of time.

Perhaps it would be productive to check with others in SPRING WG both
operators and vendors on their opinion in this matter.

Yours,
Robert.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 28 Mar 2014 11:03:54 -0700

Robin,

> including unicast and mulitcast. Then LDP does not only mean RFC
> 5036, but RFC 5036 a nd mLDP. RSVP-TE does not only mean RFC 3209,
> but RFC 3209 and P2MP TE. If SR path does not cover multicast, "LDP
> and RSVP-TE signaling protocols are not required" is just to mislead.

Agreed.

Yakov.