Subject: Simplified multicast in IS-IS VPLS

From: Xu Xiaohu <[email-masked]>
Date: Tue, 19 Apr 2011 18:12:15 +0800

Hi all,

I just noticed from Eric's recent comments on draft-ietf-l2vpn-vpls-mcast-08
as follows (see the thread:
http://www.ietf.org/mail-archive/web/l2vpn/current/msg02717.html) that
VPLS-MCAST doesn't support IP-based provider multicast distribution tree.

Therefore, I would like to reiterate that multicast in IS-IS VPLS could use
IP-based provider multicast distribution tree. Details are as follows:

***************************************************************************
5.1.2. Multicast/Broadcast 
There are two major multicast modes for IS-IS VPLS: ingress replication mode
and P-Multicast tree mode.
The encapsulation corresponding to each mode is described in the following
sub-sections.

5.1.2.1. Ingress Replication Mode
In the ingress replication mode, an ingress PE router forward the CE
multicast/broadcast frames received via its attachment circuits towards each
remote PE router of the same VPLS instance in the separate IP based tunnels
destined for each remote PE router. Hence, the encapsulation in this mode
has no difference from that for unicast.

5.1.2.2. P-Multicast Tree Mode
In the non-aggregative P-Multicast tree mode where a single P-Multicast
distribution tree in the backbone is exclusively used by one VPLS instance,
the MAC-in-IP encapsulation is used directly since the destination IP
address (i.e., multicast address) contained in the IP-based tunnel header is
enough for the egress PE routers to determine which VPLS instance the
encapsulated CE packets received from a remote PE router belongs to.
For aggregative P-Multicast tree mode in which a single P-Multicast tree is
shared by more than one VPLS instance, MAC-in-MPLS-IP encapsulation SHOULD
be used. The MPLS label contained in the inner MPLS header would be used by
the egress PE routers to identify the particular VPLS instance that the
received CE data packets belong to. To avoid introducing the complex
upstream label assignment mechanism [RFC5331], it is strongly suggested that
the globally unique VPLS label SHOULD be used in this particular case. Thus,
the value of the VPN ID filed could be directly copied to the VPLS Label
field.
****************************************************************************

In addition, you may notice that IS-IS VPLS also allows using the globally
unique VPLS label so as to avoid using the complex upstream label assignment
mechanism when implementing aggregative P-Multicast tree mode.

Any comments are welcome.

Best wishes,
Xiaohu

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Tue, 19 Apr 2011 10:40:42 -0500

Hi Xiaohu,

During the working group session in Prague there was feedback from the room we should not introduce yet another solution in this space. 

If this is indeed a requirement we should focus on extending the existing IS-IS based technologies developed by IEEE or IETF: i.e. IEEE 802.1aq/SPB or IETF TRILL.

If you want to stay in the context of solutions addressed already by L2VPN WG I suggest you go for the SPB option as it is based on IEEE Ethernet encapsulations (QinQ/802.1ad and PBB/802.1ah) that we already considered/addressed in terms of both VPWS and VPLS solution contexts - we put a lot of work already in a number of VPLS and PBB-VPLS RFCs/WG drafts on the subject, including interop ones.

I hope this helps.

Florin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Xu Xiaohu
> Sent: Tuesday, April 19, 2011 3:12 AM
> To: [email-masked]
> Subject: Simplified multicast in IS-IS VPLS
> 
> Hi all,
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 19 Apr 2011 12:24:52 -0400

Hi Florin -

Not sure I completely agree with you.

The concept of using ISIS based VPLS solution did intrigue me a little
bit.
The aspect I am little concerned about this proposal is needing P
routers to participate in 
VPLS DB population (as far as I understand). 

IS-IS based solutions on customer facing networks is not same as what is
proposed in this solution. Let us investigate further (and not use
legacy based argument)
before punting it.

IMO,
himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Balus, Florin Stelian (Florin)
Sent: Tuesday, April 19, 2011 11:41 AM
To: Xu Xiaohu; [email-masked]
Subject: RE: Simplified multicast in IS-IS VPLS

Hi Xiaohu,

During the working group session in Prague there was feedback from the
room we should not introduce yet another solution in this space. 

If this is indeed a requirement we should focus on extending the
existing IS-IS based technologies developed by IEEE or IETF: i.e. IEEE
802.1aq/SPB or IETF TRILL.

If you want to stay in the context of solutions addressed already by
L2VPN WG I suggest you go for the SPB option as it is based on IEEE
Ethernet encapsulations (QinQ/802.1ad and PBB/802.1ah) that we already
considered/addressed in terms of both VPWS and VPLS solution contexts -
we put a lot of work already in a number of VPLS and PBB-VPLS RFCs/WG
drafts on the subject, including interop ones.

I hope this helps.

Florin

> Therefore, I would like to reiterate that multicast in IS-IS VPLS
could
> use
***********************************************************************
> ****
> There are two major multicast modes for IS-IS VPLS: ingress
replication
> mode
> multicast/broadcast frames received via its attachment circuits
towards
> each
> upstream label assignment mechanism [RFC5331], it is strongly
suggested
> that
***********************************************************************
> *****

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 19 Apr 2011 18:44:40 +0200

Hi Florin,

 > During the working group session in Prague there was feedback from
 > the room we should not introduce yet another solution in this space.

Having feedback on the WG mic is good, but having a good and optimal 
solution to the problem is even better.

To deliver efficient multicast you need to be topology aware of a given 
network. And nothing is closer to accomplish this goal then link state IGP.

Clearly along the lines of separation from routing which in BGP usually 
is accomplished by defining new SAFI in the ISIS one could easily 
utilize multi-instance ISIS approach as defined in 
http://tools.ietf.org/html/draft-ietf-isis-mi-04.

Concerns reg P routers state should be analyzed against multicast 
distribution optimality. Some multicast types of traffic carrying large 
amount of traffic truly deserve to have efficient distribution patterns 
and their replication sweet spot is to happen within the network. That 
on the other hand is very hard to do using some overlay like BGP.

For the choice of transport it seems that both native IP as well as mLDP 
would work very well with ISIS VPLS instance.

Many thx,
R.

> Hi Xiaohu,
>
> During the working group session in Prague there was feedback from
> the room we should not introduce yet another solution in this space.
>
> existing IS-IS based technologies developed by IEEE or IETF: i.e.
> IEEE 802.1aq/SPB or IETF TRILL.
>
> Ethernet encapsulations (QinQ/802.1ad and PBB/802.1ah) that we
> already considered/addressed in terms of both VPWS and VPLS solution
> contexts - we put a lot of work already in a number of VPLS and
> PBB-VPLS RFCs/WG drafts on the subject, including interop ones.
>
> I hope this helps.
>
> Florin
>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Xu Xiaohu Sent:
>> Tuesday, April 19, 2011 3:12 AM To: [email-masked] Subject:
>> Simplified multicast in IS-IS VPLS
>>
>> Hi all,
>>
>> I just noticed from Eric's recent comments on
>> draft-ietf-l2vpn-vpls- mcast-08 as follows (see the thread:
>> http://www.ietf.org/mail-archive/web/l2vpn/current/msg02717.html)
>> that VPLS-MCAST doesn't support IP-based provider multicast
>> distribution tree.
>>
>> could use IP-based provider multicast distribution tree. Details
>> are as follows:
>>
****
>> 5.1.2. Multicast/Broadcast There are two major multicast modes for
>> IS-IS VPLS: ingress replication mode and P-Multicast tree mode. The
>> encapsulation corresponding to each mode is described in the
>> following sub-sections.
>>
>> 5.1.2.1. Ingress Replication Mode In the ingress replication mode,
>> an ingress PE router forward the CE multicast/broadcast frames
>> received via its attachment circuits towards each remote PE router
>> of the same VPLS instance in the separate IP based tunnels destined
>> for each remote PE router. Hence, the encapsulation in this mode
>> 5.1.2.2. P-Multicast Tree Mode In the non-aggregative P-Multicast
>> tree mode where a single P-Multicast distribution tree in the
>> backbone is exclusively used by one VPLS instance, the MAC-in-IP
>> encapsulation is used directly since the destination IP address
>> (i.e., multicast address) contained in the IP-based tunnel header
>> is enough for the egress PE routers to determine which VPLS
>> instance the encapsulated CE packets received from a remote PE
>> router belongs to. For aggregative P-Multicast tree mode in which a
>> single P-Multicast tree is shared by more than one VPLS instance,
>> MAC-in-MPLS-IP encapsulation SHOULD be used. The MPLS label
>> contained in the inner MPLS header would be used by the egress PE
>> routers to identify the particular VPLS instance that the received
>> CE data packets belong to. To avoid introducing the complex
>> suggested that the globally unique VPLS label SHOULD be used in
>> this particular case. Thus, the value of the VPN ID filed could be
>> directly copied to the VPLS Label field.
*****
>>
>> In addition, you may notice that IS-IS VPLS also allows using the
>> globally unique VPLS label so as to avoid using the complex
>> upstream label assignment mechanism when implementing aggregative
>> P-Multicast tree mode.
>>
>> Best wishes, Xiaohu

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Tue, 19 Apr 2011 11:58:56 -0500

Hi Robert,

I was not saying we should not consider using IS-IS in this context. I suggested we consider what is missing in the existing IS-IS based solutions developed already for this space in two SDOs (e.g. both have provisions for handling mcast as far as I know). 

Thanks,
Florin

> From: Robert Raszuk [mailto:[email-masked]]
> Sent: Tuesday, April 19, 2011 9:45 AM
> To: Balus, Florin Stelian (Florin)
> Cc: Xu Xiaohu; [email-masked]
> Subject: Re: Simplified multicast in IS-IS VPLS
> 
> Hi Florin,
>

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Tue, 19 Apr 2011 12:12:15 -0500

Hi Himanshu,

To move forward it will be helpful for the next IETF to define the space for this proposal by explaining in a few slides/in the draft text the differences from existing IS-IS based approaches. 

Thanks,
Florin

> From: Shah, Himanshu [mailto:[email-masked]]
> Sent: Tuesday, April 19, 2011 9:25 AM
> To: Balus, Florin Stelian (Florin); Xu Xiaohu; [email-masked]
> > the globally unique VPLS label SHOULD be used in this particular
> case.
> > Thus,
> > globally

---

From: Paul Unbehagen <[email-masked]>
Date: Tue, 19 Apr 2011 10:19:21 -0700

To that point the IEEE did tremendous amount of study on efficient multicast management when designing the algorithms behind the IS-IS topology. 

--
Paul Unbehagen

from my iPhone

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 19 Apr 2011 20:05:41 +0200

Then I think we are all in agreement.

Thx for clarification,
R.

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 20 Apr 2011 10:11:32 +0800

Hi Florin,

Thanks for your suggestion. Please see my reply inline.

> -----邮件原件-----
> 发件人: Balus, Florin Stelian (Florin)
[mailto:[email-masked]]
> 发送时间: 2011年4月19日 23:41
> 收件人: Xu Xiaohu; [email-masked]
> 主题: RE: Simplified multicast in IS-IS VPLS
> 
> Hi Xiaohu,
> 
room
> we should not introduce yet another solution in this space.
> 
> If this is indeed a requirement we should focus on extending the existing
IS-IS
> based technologies developed by IEEE or IETF: i.e. IEEE 802.1aq/SPB or
IETF
> TRILL.

Could you please give your reason why we should focus on extending the
existing IS-IS based technologies developed by IEEE or IETF: i.e. IEEE
802.1aq/SPB or IETF
TRILL, rather than extending the existing proven and familiar VPLS
technology a little bit? 

I agree that TRILL and SPB have many charming characters. However, IMHO,
there is still a long way to go for both TRILL and SPB before they are
comparable to IP and VPLS on the aspect of technology stability and
maturation. e.g., breaking 4096 VLANs limit, OAM tools for TRILL, Adding TTL
and simplifying the ECMP algorithm for SPB. 

Before a piece of delicious cake being baked, could somebody be allowed to
heat his existing bread to allay his hunger? I think people could make their
wise choices depending on their starvation status.

> If you want to stay in the context of solutions addressed already by L2VPN
WG I
> suggest you go for the SPB option as it is based on IEEE Ethernet
> encapsulations (QinQ/802.1ad and PBB/802.1ah) that we already
> considered/addressed in terms of both VPWS and VPLS solution contexts - we
> put a lot of work already in a number of VPLS and PBB-VPLS RFCs/WG drafts
on
> the subject, including interop ones.

Good point. The intention of IS-IS VPLS is just to reuse the existing VPLS
and IP technologies, since we have put a lot of work already in a number of
VPLS and PBB-VPLS RFCs/WG drafts, without mentioning numerous IP RFCs/WG
drafts. As you know, from the perspective of data plane, IS-IS VPLS could
reuse the existing VPLS encapsulation (e.g., VPLS over IP/GRE) and
forwarding mechanisms WITHOUT ANY CHANGE.

Thanks again for your comments.

Best wishes,
Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 20 Apr 2011 10:51:22 +0800

> -----邮件原件-----
> 发件人: Robert Raszuk [mailto:[email-masked]]
> 发送时间: 2011年4月20日 0:45
> 收件人: Balus, Florin Stelian (Florin)
> 抄送: Xu Xiaohu; [email-masked]
> 主题: Re: Simplified multicast in IS-IS VPLS
> 
> Hi Florin,
> 

Hi Robert,

Yes, your observation is correct.

Best wishes,
Xiaohu

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Mon, 25 Apr 2011 12:26:05 -0500

Hi Xiaohu,
Sorry for the delayed response. I took some vacation days.

See the answers to your questions below, focusing on the IEEE interop, the focus up to now in L2VPN WG...

> From: Xu Xiaohu [mailto:[email-masked]]
> Sent: Tuesday, April 19, 2011 7:12 PM
> To: Balus, Florin Stelian (Florin); [email-masked]
> Subject: re: Simplified multicast in IS-IS VPLS
> 
> Hi Florin,
> 
> the
> existing

[[FB]] This discussion is not about extending IEEE solutions versus extending VPLS. No need to change VPLS data plane to accommodate IEEE 802.1aq/SPB: SPB uses encapsulations like QinQ/802.1ad and PBB/802.1ah already supported by VPLS (see L2VPN comprehensive work on interop in draft-ietf-l2vpn-vpls-bridge-interop, draft-ietf-l2vpn-pbb-vpls-interop, draft-ietf-l2vpn-pbb-vpls-pe-model). 

This is about comparing the work to accommodate the IS-IS proposal in your draft (involving changes to the VPLS control plane) vs re-using existing IS-IS proposals developed in IEEE/IETF to that extent. 

> maturation. e.g., breaking 4096 VLANs limit, OAM tools for TRILL,
> Adding TTL and simplifying the ECMP algorithm for SPB.

[[FB]] My understanding is that IEEE 802.1aq/SPB work is almost completed and it should close this year or early next year. Also there was a lot of good work L2VPN WG did in the last 5-6 years to make sure we are in sync with IEEE so that all scaling aspects (4K VLANs, MAC scaling etc) and OAM toolsets (802.1ag, Y.1731) are inherited between the two specification sets. New initiatives like IEEE 802.1Qbp need to be considered as they are developed but definitely it will be easier to accommodate the new features if we are using the same base spec.

> L2VPN

[[FB]] See above there should not be any change in VPLS data plane. Let's focus on why go through a VPLS control plane change with new IS-IS procedures versus re-using the IS-IS work already in place in IEEE/IETF. 

> > > I just noticed from Eric's recent comments on draft-ietf-l2vpn-
> vpls-
> > > mcast-08
> > > destined for each remote PE router. Hence, the encapsulation in
> this
> > > mode

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 26 Apr 2011 12:11:32 +0800

> [[FB]] See above there should not be any change in VPLS data plane. Let's
focus
> on why go through a VPLS control plane change with new IS-IS procedures
> versus re-using the IS-IS work already in place in IEEE/IETF.

As I said at IETF80, VPLS could be a good option for cloud data center
network technology due to its powerful capabilities( e.g., Shortest path
forwarding.
Equal Cost Multi-Path (ECMP), a large amount of VPN instances (>4096),
forwarding table scalability, etc.) and especially the fact that VPLS and IP
are much proven and familiar technologies to most operators. However, BGP
VPLS [RFC4761] and LDP VPLS [RFC4762] protocols seem a bit heavy-weight.
That's why I propose a light-weight VPLS using IS-IS.

BR,
Xiaohu