Subject: Last call for draft-ietf-l2vpn-pbb-vpls-pe-model

From: Giles Heron <[email-masked]>
Date: Tue, 11 Oct 2011 09:44:42 +0100

This is the start of a two-week working group last call on the draft
³Extensons to VPLS PE Model for Provider Backbone Bridging².

The draft can be found at:

http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-vpls-pe-model-04
 
Please, review the draft and send any comments to the L2VPN working group
email list. 

This WG last call will close on Tuesday October 25th 2011.
 
Regards,
Giles

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 11 Oct 2011 11:06:35 +0200

support

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Giles Heron
Sent: dinsdag 11 oktober 2011 10:45
To: [email-masked]
Subject: Last call for draft-ietf-l2vpn-pbb-vpls-pe-model

 

Regards,
Giles

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 11 Oct 2011 08:32:49 -0700

support

> Sent: Tuesday, October 11, 2011 1:45 AM
> To: [email-masked]

---

From: Shishio Tsuchiya <[email-masked]>
Date: Wed, 12 Oct 2011 00:44:30 +0900

support!

---

From: David Allan I <[email-masked]>
Date: Tue, 11 Oct 2011 13:17:53 -0400

Hi:

For what is largely a tutorial document, IMO it is missing a critical component.

IMO bridging B-components over VPLS is no different than bridging S-components, done & dusted. The key difference introduced in PBB and what this document is almost totally silent on is in how I-components map per S-tag BU traffic to I-SID specific reserved multicast MAC addresses, and how MAC filtering is used within the B-tag. This is how much finer broadcast containment of customer VLANs is performed vs. simply using B-tags. 

This plays into the packet walkthrough description and gives some clue as to why specific references (e.g. MMRP) are in section 6.

For the document to have utility, this should be called out. Please consider this a formal LC comment.

My 2 cents
Dave

(2011/10/11 17:44), Giles Heron wrote:
> Please, review the draft and send any comments to the L2VPN working 
> group email list.
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 11 Oct 2011 10:46:11 -0700

Hi Dave,

One of point that this draft is making is that bridging S-component in VPLS IS different than bridging B-component in PBB-VPLS with respect to PE model. In VPLS/H-VPLS, an S-VLAN is mapped to a group of PWs - e.g., a group of PWs represent a VLAN emulation and it is associated with a broadcast domain (associated with a VLAN). However, in PBB-VPLS, a PW represents a logical interface and thus it is treated as an interface to the B-component and thus enables us to run bridging protocol such as MMRP over such interface for multicast optimization.

I think your point is that the section 6 needs to articulate this better and I agree and we will expand it a bit more in the next rev.

Cheers,
Ali	

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of David Allan I
> Sent: Tuesday, October 11, 2011 10:18 AM
> To: Giles Heron
> Cc: [email-masked]
> Subject: RE: Last call for draft-ietf-l2vpn-pbb-vpls-pe-model
> 
> Hi:
> 
> IMO bridging B-components over VPLS is no different than bridging S-
> components, done & dusted. The key difference introduced in PBB and
> what this document is almost totally silent on is in how I-components
> map per S-tag BU traffic to I-SID specific reserved multicast MAC
> addresses, and how MAC filtering is used within the B-tag. This is how
> much finer broadcast containment of customer VLANs is performed vs.
> simply using B-tags.
> 
> This plays into the packet walkthrough description and gives some clue
> as to why specific references (e.g. MMRP) are in section 6.
>

---

From: David Allan I <[email-masked]>
Date: Tue, 11 Oct 2011 14:00:08 -0400

Hi Ali:

I was more interested in some mention of how bridging overlayed on the B-MAC layer worked in the packet walkthrough in section 4 as that seemed rather thin on IMO a key point. As otherwise the behaviour is directly analogous to bridging an S-tag even if a B-tag was an aggregate of S-tags... (e.g. a VPN of VPNs...)

A bit of elaboration in section 6 I would consider to be a bonus. ;-)

Dave

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
Sent: Tuesday, October 11, 2011 10:46 AM
To: David Allan I; Giles Heron
Cc: [email-masked]
Subject: RE: Last call for draft-ietf-l2vpn-pbb-vpls-pe-model

Hi Dave,

Cheers,
Ali

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 11 Oct 2011 11:10:57 -0700

Hi Dave,

We cannot do a PBB tutorial here because it is outside of the scope; however, we can elaborate how customer mcast traffic is encapsulated and how they can be replicated efficiently because of the PBB-VPLS PE model and applying MMRP over PWs (that act as logical interfaces). 

Cheers,
Ali

> From: David Allan I [mailto:[email-masked]]
> Sent: Tuesday, October 11, 2011 11:00 AM
> To: Ali Sajassi (sajassi); Giles Heron
> Cc: [email-masked]
> I was more interested in some mention of how bridging overlayed on the
> B-MAC layer worked in the packet walkthrough in section 4 as that
> seemed rather thin on IMO a key point. As otherwise the behaviour is
> directly analogous to bridging an S-tag even if a B-tag was an
> aggregate of S-tags... (e.g. a VPN of VPNs...)
> 
> One of point that this draft is making is that bridging S-component in
> VPLS IS different than bridging B-component in PBB-VPLS with respect to
> PE model. In VPLS/H-VPLS, an S-VLAN is mapped to a group of PWs - e.g.,
> a group of PWs represent a VLAN emulation and it is associated with a
> broadcast domain (associated with a VLAN). However, in PBB-VPLS, a PW
> represents a logical interface and thus it is treated as an interface
> to the B-component and thus enables us to run bridging protocol such as
> MMRP over such interface for multicast optimization.
> 
> I think your point is that the section 6 needs to articulate this
> better and I agree and we will expand it a bit more in the next rev.
> 
> Cheers,
> Ali
> 
>

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Tue, 11 Oct 2011 13:16:33 -0500

Hi Dave,

Based on previous comments we chose to focus the current text only on the deltas from IEEE docs (specifically IEEE 802.1ah): i.e. the I-component bridging procedures are very well described in IEEE 802.1ah.
Also PBB-VPLS interop draft - see the other LC -  has some level of details on the S-tag Interop piece.

If something is missing though we can consider updating the text in one of the two drafts. Feel free to send us some suggested text for the two sections...

Thanks,
Florin

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David Allan I
> I was more interested in some mention of how bridging overlayed on the B-MAC
> layer worked in the packet walkthrough in section 4 as that seemed rather thin
> on IMO a key point. As otherwise the behaviour is directly analogous to bridging
> an S-tag even if a B-tag was an aggregate of S-tags... (e.g. a VPN of VPNs...)
> 
> One of point that this draft is making is that bridging S-component in VPLS IS
> different than bridging B-component in PBB-VPLS with respect to PE model. In
> VPLS/H-VPLS, an S-VLAN is mapped to a group of PWs - e.g., a group of PWs
> represent a VLAN emulation and it is associated with a broadcast domain
> (associated with a VLAN). However, in PBB-VPLS, a PW represents a logical
> interface and thus it is treated as an interface to the B-component and thus
> enables us to run bridging protocol such as MMRP over such interface for
> multicast optimization.
> 
> I think your point is that the section 6 needs to articulate this better and I agree
> and we will expand it a bit more in the next rev.
> 
> Cheers,
> Ali
> 
>

---

From: David Allan I <[email-masked]>
Date: Tue, 11 Oct 2011 14:56:37 -0400

Well, at the risk of being pedantic, right now you are sort of half pregnant....

Section 4 describes a chunk of how a B-component behaves, with the proviso that some arbitrary bundle of virtual interfaces need to be treated like a single interface from the POV of split horizon but without invalidating learning of B-MAC to PW bindings unique to each PW. And goes further to discuss the decapsulation performed by I-components. IMO everything beyond how a PW bundle is treated by a B-component has already crossed a line if the goal is to discuss deltas from IEEE docs.

So it is either overkill from the "this is not a tutorial" point of view as the only requisite statement is about how the B-component needs to treat a set of PWs (e.g. no different than an S-component would). Or inadequate if it is to set the stage for any additional functions the B-component/VPLS boundary could implement (e.g. MMRP driven filtering)...

I actually do not care either way, but if the intent is to set the stage then a simple additional of a couple of sentences. 

"Frames arriving on non-VPLS B-component interfaces are treated as per 802.1ah. BU frames from all non-virtual interfaces are flooded on all B-component interfaces participating in the B-VID the frame is tagged with (with the exception of the I/F of arrival). 

Frames arriving from a CE are treated as per 802.1ah and encapsulated accordingly, with the key salient feature being that if corresponding I-component cannot resolve a C-MAC to B-MAC binding or the frame is a broadcast or multicast frame, the frame is encapsualted in a well known I-SID specific reserved multicast MAC address upon which MAC filtering MAY be applied by B-components. The frame is then forwarded to the B-component where it is treated as described above."

Would IMO be sufficient...others may express it more succintly than I ;-)

Cheers
Dave

-----Original Message-----
From: Balus, Florin Stelian (Florin) [mailto:[email-masked]] 
Sent: Tuesday, October 11, 2011 11:17 AM
To: David Allan I; Ali Sajassi (sajassi); Giles Heron
Cc: [email-masked]
Subject: RE: Last call for draft-ietf-l2vpn-pbb-vpls-pe-model

Hi Dave,

Thanks,
Florin

> VPLS IS different than bridging B-component in PBB-VPLS with respect 
> to PE model. In VPLS/H-VPLS, an S-VLAN is mapped to a group of PWs - 
> e.g., a group of PWs represent a VLAN emulation and it is associated 
> with a broadcast domain (associated with a VLAN). However, in 
> PBB-VPLS, a PW represents a logical interface and thus it is treated 
> as an interface to the B-component and thus enables us to run bridging 
> protocol such as MMRP over such interface for multicast optimization.
> 
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of David Allan I
> > what this document is almost totally silent on is in how 
> > I-components map per S-tag BU traffic to I-SID specific reserved 
> > multicast MAC addresses, and how MAC filtering is used within the 
> > B-tag. This is how much finer broadcast containment of customer VLANs is performed vs.
> > simply using B-tags.
> >
> > This plays into the packet walkthrough description and gives some 
> > clue as to why specific references (e.g. MMRP) are in section 6.
> >
> > > This is the start of a two-week working group last call on the 
> > > draft ³Extensons to VPLS PE Model for Provider Backbone Bridging².
> > >
> > > Please, review the draft and send any comments to the L2VPN 
> > > working group email list.
> > >

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Tue, 11 Oct 2011 19:20:43 -0500

Thanks Dave.  See in-line

> Sent: Tuesday, October 11, 2011 11:57 AM
> To: Balus, Florin Stelian (Florin); Ali Sajassi (sajassi); Giles Heron
> Cc: [email-masked]
> Section 4 describes a chunk of how a B-component behaves, with the proviso
> that some arbitrary bundle of virtual interfaces need to be treated like a single
> interface from the POV of split horizon but without invalidating learning of B-
> MAC to PW bindings unique to each PW. And goes further to discuss the
> decapsulation performed by I-components. IMO everything beyond how a PW
> bundle is treated by a B-component has already crossed a line if the goal is to
> discuss deltas from IEEE docs.
> 
> So it is either overkill from the "this is not a tutorial" point of view as the only
> requisite statement is about how the B-component needs to treat a set of PWs
> (e.g. no different than an S-component would). Or inadequate if it is to set the
> stage for any additional functions the B-component/VPLS boundary could
> implement (e.g. MMRP driven filtering)...
> 
> I actually do not care either way, but if the intent is to set the stage then a
> simple additional of a couple of sentences.
> 
> "Frames arriving on non-VPLS B-component interfaces are treated as per 802.1ah.
> BU frames from all non-virtual interfaces are flooded on all B-component
> interfaces participating in the B-VID the frame is tagged with (with the
> exception of the I/F of arrival).
> 
> Frames arriving from a CE are treated as per 802.1ah and encapsulated
> accordingly, with the key salient feature being that if corresponding I-
> component cannot resolve a C-MAC to B-MAC binding or the frame is a broadcast
> or multicast frame, the frame is encapsualted in a well known I-SID specific
> reserved multicast MAC address upon which MAC filtering MAY be applied by B-
> components. The frame is then forwarded to the B-component where it is
> treated as described above."

This looks like IEEE 802.1ah procedure right? Nothing about the PBB-VPLS model in here. I am open to consider adding the text but I do not see the benefit. Am I missing something?
> Based on previous comments we chose to focus the current text only on the
> deltas from IEEE docs (specifically IEEE 802.1ah): i.e. the I-component bridging
> procedures are very well described in IEEE 802.1ah.
> If something is missing though we can consider updating the text in one of the
> two drafts. Feel free to send us some suggested text for the two sections...
> 
> Thanks,
> Florin
>

---

From: David Allan I <[email-masked]>
Date: Tue, 11 Oct 2011 20:31:00 -0400

HI Florin:

I'm confused as to what hairs you are seeking to split. The document is already prescriptive on the B-component behavior when some of the interfaces are PWs above and beyond what is actually necessary. "A B-component is required to treat a set of PWs this way" is the only statement actually needed in place of all of section 4.

As section 4 exists and IMO offers minimal utility in its current form, I'm simply suggesting adding two sentences or so to finish the picture it is already painting instead of pruning down to one requirement. 

To be consistent it is either-or.

Cheers
Dave

-----Original Message-----
From: Balus, Florin Stelian (Florin) [mailto:[email-masked]] 
Sent: Tuesday, October 11, 2011 5:21 PM
To: David Allan I; Ali Sajassi (sajassi); Giles Heron
Cc: [email-masked]
Subject: RE: Last call for draft-ietf-l2vpn-pbb-vpls-pe-model

Thanks Dave.  See in-line

> Section 4 describes a chunk of how a B-component behaves, with the 
> proviso that some arbitrary bundle of virtual interfaces need to be 
> treated like a single interface from the POV of split horizon but 
> without invalidating learning of B- MAC to PW bindings unique to each 
> PW. And goes further to discuss the decapsulation performed by 
> I-components. IMO everything beyond how a PW bundle is treated by a 
> B-component has already crossed a line if the goal is to discuss deltas from IEEE docs.
> 
> So it is either overkill from the "this is not a tutorial" point of 
> view as the only requisite statement is about how the B-component 
> needs to treat a set of PWs (e.g. no different than an S-component 
> would). Or inadequate if it is to set the stage for any additional 
> functions the B-component/VPLS boundary could implement (e.g. MMRP driven filtering)...
> 
> I actually do not care either way, but if the intent is to set the 
> stage then a simple additional of a couple of sentences.
> 
> BU frames from all non-virtual interfaces are flooded on all 
> B-component interfaces participating in the B-VID the frame is tagged 
> with (with the exception of the I/F of arrival).
> 
> accordingly, with the key salient feature being that if corresponding 
> I- component cannot resolve a C-MAC to B-MAC binding or the frame is a 
> broadcast or multicast frame, the frame is encapsualted in a well 
> known I-SID specific reserved multicast MAC address upon which MAC 
> filtering MAY be applied by B- components. The frame is then forwarded 
> to the B-component where it is treated as described above."

> Based on previous comments we chose to focus the current text only on 
> the deltas from IEEE docs (specifically IEEE 802.1ah): i.e. the 
> I-component bridging procedures are very well described in IEEE 802.1ah.
> If something is missing though we can consider updating the text in 
> one of the two drafts. Feel free to send us some suggested text for the two sections...
> 
> Thanks,
> Florin
> 
> > I was more interested in some mention of how bridging overlayed on 
> > the B-MAC layer worked in the packet walkthrough in section 4 as 
> > that seemed rather thin on IMO a key point. As otherwise the 
> > behaviour is directly analogous to bridging an S-tag even if a B-tag 
> > was an aggregate of S-tags... (e.g. a VPN of VPNs...)
> >
> > One of point that this draft is making is that bridging S-component 
> > in VPLS IS different than bridging B-component in PBB-VPLS with 
> > respect to PE model. In VPLS/H-VPLS, an S-VLAN is mapped to a group 
> > of PWs - e.g., a group of PWs represent a VLAN emulation and it is 
> > associated with a broadcast domain (associated with a VLAN). 
> > However, in PBB-VPLS, a PW represents a logical interface and thus 
> > it is treated as an interface to the B-component and thus enables us 
> > to run bridging protocol such as MMRP over such interface for multicast optimization.
> >
> > > IMO bridging B-components over VPLS is no different than bridging 
> > > S- components, done & dusted. The key difference introduced in PBB 
> > > and what this document is almost totally silent on is in how 
> > > B-tag. This is how much finer broadcast containment of customer 
> > > VLANs is
> performed vs.
> > > simply using B-tags.
> > >
> > > For the document to have utility, this should be called out. 
> > > Please consider this a formal LC comment.
> > >
> > > My 2 cents
> > > Dave
> > >
> > >

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Wed, 12 Oct 2011 16:01:35 -0500

Hi Dave,
We will wait for the end of LC and will discuss all proposed changes between co-authors and try to address them.

Note though we had a long discussion in L2VPN some time ago about re-using as much as possible the descriptions in the IEEE specs. Sometimes people are better off reading the  entire text in one place (IEEE802.1ah in our case) than just getting a portion of it.

As a result we took great care to include in section 4 only description related to PW encapsulation/forwarder: i.e. we pretty much tried to include wording to describe your statement "A B-component is required to treat a set of PWs this way". But we had to elaborate what "way" means and I thought we did it succinctly enough. I guess you are saying we elaborated too much hence your request.
Florin

> Sent: Tuesday, October 11, 2011 5:31 PM
> I'm confused as to what hairs you are seeking to split. The document is already
> prescriptive on the B-component behavior when some of the interfaces are PWs
> above and beyond what is actually necessary. "A B-component is required to
> treat a set of PWs this way" is the only statement actually needed in place of all
> of section 4.
> 
> As section 4 exists and IMO offers minimal utility in its current form, I'm simply
> suggesting adding two sentences or so to finish the picture it is already painting
> instead of pruning down to one requirement.
> 
> This looks like IEEE 802.1ah procedure right? Nothing about the PBB-VPLS model
> in here. I am open to consider adding the text but I do not see the benefit. Am I
> missing something?
> >

---

From: David Allan I <[email-masked]>
Date: Wed, 12 Oct 2011 17:24:18 -0400

Ok, great 

Thanks
D

-----Original Message-----
From: Balus, Florin Stelian (Florin) [mailto:[email-masked]] 
Sent: Wednesday, October 12, 2011 2:02 PM
To: David Allan I; Ali Sajassi (sajassi); Giles Heron
Cc: [email-masked]
Subject: RE: Last call for draft-ietf-l2vpn-pbb-vpls-pe-model

Hi Dave,

> I'm confused as to what hairs you are seeking to split. The document 
> is already prescriptive on the B-component behavior when some of the 
> interfaces are PWs above and beyond what is actually necessary. "A 
> B-component is required to treat a set of PWs this way" is the only 
> statement actually needed in place of all of section 4.
> 
> As section 4 exists and IMO offers minimal utility in its current 
> form, I'm simply suggesting adding two sentences or so to finish the 
> picture it is already painting instead of pruning down to one requirement.
> 
> > without invalidating learning of B- MAC to PW bindings unique to 
> > each PW. And goes further to discuss the decapsulation performed by 
> > B-component has already crossed a line if the goal is to discuss 
> > deltas from
> IEEE docs.
> >
> > functions the B-component/VPLS boundary could implement (e.g. MMRP 
> > driven
> filtering)...
> >
> > "Frames arriving on non-VPLS B-component interfaces are treated as 
> > per
> 802.1ah.
> > B-component interfaces participating in the B-VID the frame is 
> > tagged with (with the exception of the I/F of arrival).
> >
> > Frames arriving from a CE are treated as per 802.1ah and 
> > encapsulated accordingly, with the key salient feature being that if 
> > corresponding
> > I- component cannot resolve a C-MAC to B-MAC binding or the frame is 
> > a broadcast or multicast frame, the frame is encapsualted in a well 
> > filtering MAY be applied by B- components. The frame is then 
> > forwarded to the B-component where it is treated as described above."
> 
> This looks like IEEE 802.1ah procedure right? Nothing about the 
> PBB-VPLS model in here. I am open to consider adding the text but I do 
> not see the benefit. Am I missing something?
> >
> > Would IMO be sufficient...others may express it more succintly than 
> > I
> > ;-)
> >
> > Cheers
> > Dave
> >
> >
> >
> >
> >
> > Based on previous comments we chose to focus the current text only 
> > on the deltas from IEEE docs (specifically IEEE 802.1ah): i.e. the 
> > one of the two drafts. Feel free to send us some suggested text for 
> > the two
> sections...
> >
> > Thanks,
> > Florin
> >
> > > behaviour is directly analogous to bridging an S-tag even if a 
> > > B-tag was an aggregate of S-tags... (e.g. a VPN of VPNs...)
> > >
> > > One of point that this draft is making is that bridging 
> > > S-component in VPLS IS different than bridging B-component in 
> > > PBB-VPLS with respect to PE model. In VPLS/H-VPLS, an S-VLAN is 
> > > mapped to a group of PWs - e.g., a group of PWs represent a VLAN 
> > > emulation and it is associated with a broadcast domain (associated with a VLAN).
> > > it is treated as an interface to the B-component and thus enables 
> > > us to run bridging protocol such as MMRP over such interface for 
> > > multicast
> optimization.
> > >
> > > > S- components, done & dusted. The key difference introduced in 
> > > > PBB and what this document is almost totally silent on is in how 
> > > > multicast MAC addresses, and how MAC filtering is used within 
> > > > the B-tag. This is how much finer broadcast containment of 
> > > > customer VLANs is
> > performed vs.
> > > > simply using B-tags.
> > > >
> > > > This plays into the packet walkthrough description and gives 
> > > > some clue as to why specific references (e.g. MMRP) are in section 6.
> > > >

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Sun, 30 Oct 2011 03:32:53 +0530

Support

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Giles Heron
Sent: Tuesday, October 11, 2011 1:45 AM
To: [email-masked]
Subject: Last call for draft-ietf-l2vpn-pbb-vpls-pe-model

 

Regards,
Giles