Subject: [mpls] poll on draft-raggarwa-mpls-seamless-mcast

From: Loa Andersson <[email-masked]>
Date: Thu, 12 May 2011 15:59:26 +0200

Working Group,

this is to start a two week poll on making

draft-raggarwa-mpls-seamless-mcast-03.txt

an mpls working group document.

If you support the document becoming a working group document
please respond to this poll with "yes/support"

If you do not support the document becoming a working group
document please respond to this poll with "no/do not support"
and at the same time give the technical reasons why you are
not supporting the document.

If you have technical comments or in any other way want to
discuss the document, please send these comments to the mpls
working group mailing list, but with another subject than what
is on this mail.

The poll ends on May 27th.

/Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: <[email-masked]>
Date: Mon, 23 May 2011 20:46:06 +0200

Support!

 Regards

   Nic

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Loa Andersson
Gesendet: Donnerstag, 12. Mai 2011 15:59
An: [email-masked]; [email-masked]; Ross Callon; George Swallow
Betreff: [mpls] poll on draft-raggarwa-mpls-seamless-mcast

Working Group,

/Loa

--

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Marco Rodrigues <[email-masked]>
Date: Mon, 23 May 2011 15:10:32 -0400

Support.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 24 May 2011 14:47:38 -0700

Loa,

yes/support

Yakov

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 25 May 2011 03:19:02 +0200

Yes/support

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yakov Rekhter
Sent: dinsdag 24 mei 2011 23:48
To: Loa Andersson
Cc: Ross Callon; [email-masked]; [email-masked]
Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast

Loa,

yes/support

Yakov

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Wed, 25 May 2011 09:13:59 +0200

Yes support
./
Lieve

---

From: Eric Rosen <[email-masked]>
Date: Wed, 25 May 2011 08:49:22 -0400

No/Do not Support.

1. The procedures for setting up P-tunnels across a seamless MPLS
   environment violate most of the requirements expressed in the "seamless
   MPLS" draft.  In particular, it is proposed to get the ABRs intimately
   involved in the MVPN-specific service signaling.  This violates the
   "seamless MPLS" requirement that the "transport nodes" (such as the ABRs)
   not have service-specific procedures, and that they should not have to
   maintain service-specific states.  If one wants to use BGP to set up
   P-tunnels in a seamless environment, the NLRI should be a P-tunnel
   identifier, not a customer multicast flow identifier.

   I will develop this point in another thread and suggest an alternate
   approach.

2. I think the handling of Internet multicast is the wrong approach.  It
   would be a lot simpler to treat "global table" multicast just like MVPN
   multicast, just using a special RD and RT to distinguish the global table
   from the VRFs.  Instead, this draft tries to do global table multicast
   without using the C-multicast routes, but just with the A-D routes.
   There is no reason for this different way of handling multicast, it just
   creates unnecessary complexity.

Since I think this draft takes the wrong approach on two very important
topics, I cannot support its becoming a WG document in its present form.

---

From: "SAAD, SAMIR S (ATTSI)" <[email-masked]>
Date: Tue, 24 May 2011 17:00:58 -0400

Support.

Samir Saad
AT&T

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 25 May 2011 15:48:33 +0200

No, do not support.

The issues Eric raised are fundamental and need to be addressed before adoption.

Thx,

Ice.

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 25 May 2011 17:31:51 -0700

Support.

---

From: Maciek Konstantynowicz <[email-masked]>
Date: Thu, 26 May 2011 10:04:40 +0100

yes/support

Cheers,
Maciek.

---

From: Rahul Aggarwal <[email-masked]>
Date: Fri, 27 May 2011 10:10:33 -0700

Hi Eric,

Please see inline:

>   I will develop this point in another thread and suggest an alternate

draft-raggarwa-mpls-seamless-mcast does provide the building blocks which 
do not require service signaling on ABRs. The draft makes a careful choice 
on the state that should be placed on the ABRs and the state that should 
not be on the ABRs. For example MVPN C-multicast routes are not required 
to be on ABRs. There are good reasons, described in response to your 
other thread by Yakov, for using the ABRs as RRs for I/S-PMSI A-D routes. 
Also, please see the response by Yakov on how your alternative
approach could be supported within the framework of
draft-raggarwa-mpls-seamless-mcast.

>   creates unnecessary complexity.

Without getting into debate on whether treating "global table"
multicast "just like MVPN" is "a lot simpler", and whether the
approach described in the draft "creates unnecessary complexity",
let me point out that draft-raggarwa-mpls-seamless-mcast does not
preclude treating "global table" multicast just like MVPN. In
fact, since draft-raggarwa-mpls-seamless-mcast does apply to MVPN,
draft-raggarwa-mpls-seamless-mcast does support the model you
described above, where "global table" multicast is treated just
ike MVPN.

However not all Service Providers are willing to buy into this model, 
just like not all SPs are willing to put Internet unicast in a VRF. Hence
the draft describes an alternate model

> topics,

The draft does not "take the wrong approach" on these two topics.
Please see above and the response by Yakov. Your comments are in no
way fundamental and should not prevent the draft from being adopted as a
WG draft and allow the WG to work on improving it.

rahul

---

From: Rahul Aggarwal <[email-masked]>
Date: Fri, 27 May 2011 10:12:56 -0700

Hi Loa,

Yes/support.

rahul

---

From: FRANCISCO JAVIER JIMENEZ CHICO <[email-masked]>
Date: Fri, 27 May 2011 21:26:36 +0200

Yes, support.

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Rahul Aggarwal
Enviado el: viernes, 27 de mayo de 2011 19:13
Para: Loa Andersson
CC: Ross Callon; [email-masked]; [email-masked]
Asunto: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast

Hi Loa,

Yes/support.

rahul

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Thomas Morin <[email-masked]>
Date: Mon, 30 May 2011 11:57:32 +0200

Hello Eric, working group,

Eric Rosen:
>     maintain service-specific states.

I don't think that there are contradictions between 
draft-leymann-mpls-seamless-mpls and draft-raggarwa-mpls-seamless-mcast.

First, the unicast seamless MPLS architecture strongly relies on region 
boundaries (ie. ABRs) to improve scaling, and this is precisely the 
spirit of the seamless MPLS multicast proposal.  Second, if you read the 
last § of section 2.1 or the unicast focused "seamless MPLS" draft, the 
motivation for decoupling service and transport is essentially presented 
in a configuration overhead perspective; the seamless MPLS multicast 
proposal does not require per-service configuration and is thus 
completely in line with this.  Last, let's keep in mind that the 
seamless MPLS draft is itself quite modest on how much it applies to 
multicast ("Currently, this document focus on end to end unicast LSP") 
and that what the seamless MPLS draft says on states in "transport 
nodes" is that they "*ideally* have no customer or service state" 
(emphasis mine) : far from being formulated as an fundamental 
requirement or as an architecture principle, it sounds as possibly open 
to a tradeoff.

So well... no surprise to see someone co-authoring both drafts !  ;-)

That said, generally speaking, I don't think that we should even shape 
the debate by applying as-is unicast-focused principles. I will restate 
the obvious, but the solutions that have been designed to enable 
multicast connectivity in flat IP or VPN environnement can actually be 
considered as "violating" what is often considered as key principle for 
unicast: these solutions introduced the possibility for multicast 
per-VPN and/or per-session control plane and/or dataplane state in the 
network. This is a necessary tradeoff.

So, it looks more reasonable to me to discuss precisely which (claimed) 
problems are brought by the proposal and whether or not this is 
problematic in a context such as the one described in the "seamless 
MPLS" draft (and we should carefully distinguish between configuration 
state, control plane state, and dataplane state). The seamless MPLS 
multicast architecture provides tools that are a solid tradeoff to scale 
multicast MPLS in such context. That it is at the expense of some state 
in ABRs does not prevent this solution from being a good solution. In 
fact, the leaf tracking issue happens to be reduced to a smaller issue 
by introducing some state in ABRs.

-Thomas,
co-author *and* supporting WG adoption !

---

From: Balaji KR <[email-masked]>
Date: Tue, 31 May 2011 20:53:24 +0530

Support.