Subject: RE: Proposed liaison response to IEEE

From: "Nurit Sprecher" <[email-masked]>
Date: Thu, 21 Sep 2006 13:38:16 +0200

Hi,

I think it is a good idea to send the liaison to the IEEE and get once
and for all a clear statement that the s-vid translation is supported on
each provider bridge port. 

In addition, the IEEE has recognized that MAC learning is not required
for point-to-point VLANs in a bridge. The 802.1Q rev-5 already includes
this extension in section 8.7. 

" The Learning Process receives the source MAC Addresses and VIDs of
received frames from the

Forwarding Process, following the application of the ingress rules
(8.6.2). It shall create or update a

Dynamic Filtering Entry (8.8.3) that specifies the reception Port for
the frame's source address and VID, if

and only if the source address is an Individual Address, i.e., is not a
Group Address, the resulting number of

entries would not exceed the capacity of the Filtering Database, and the
filtering utility criteria for the

receiving Bridge Port are met."

The enhanced filtering utility criteria "are satisfied if at least one
VLAN that uses the FID includes the reception Port and at least one
other Port with a Port State of Learning or Forwarding in its member
set, and: a) The operPointToPointMAC parameter is false for the
reception Port; or b) Ingress to the VLAN is permitted through a third
Port. NOTE -The third port can, but is not required to be in the member
set.". 

I think it is clearly stated, but if it is required to ask the IEEE
about the context of forwarding based on a destination MAC, I suggest
being more precise and specify that we are talking on point-to-point
connections.

Regards,

Nurit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Don Fedyk
Sent: Wednesday, September 20, 2006 23:16
To: Adrian Farrel; [email-masked]
Cc: [email-masked]; Wijnen, Bert (Bert)
Subject: RE: Proposed liaison response to IEEE

Hi Adrian

The Liaison looks good however it does not capture a comment I made.   

My understanding of the S-VLAN translation in IEEE documents and the

liaison is that the translation is valid in the context of forwarding

based on a destination MAC. My interpretation is that V-LAN is optional

MAC is not. If I am correct VLAN translation as specified is not equal

to Label switching. The Liaison is clear about not just the format of

'packets on the wire' but the relationship to the entities such as MAC

relay as well.  

I think we should also ask in our liaison for clarification if the

S-VLAN translation can be valid by itself i.e. as a label agnostic to

the MAC so there is no confusion.

Thanks,

Don

> -----Original Message-----

> From: [email-masked] 

> All,

> The IETF received an unsolicited liaison on the subject of 

> 802.1 Ethernet

> You can see the liaison at

> https://datatracker.ietf.org/documents/LIAISON/file358.pdf

> The participants on the GELS mailing list have requested that 

> we respond to this to clarify an issue.

> Here is the draft of a liaison that we proposed to send. 

> Please shout at once if you have any concerns with this 

> liaison. I intend to ask Bert to send it on Monday of next week.

> Thanks,

> Adrian

> ===

> Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags"

> Date: Sep 2006

> To: IEEE802.1

>      Tony Jeffree, IEEE 802.1 WG Chair, [email-masked]

> From: Bert Wijnen, IETF liaison to IETF liaison to IEEE 802.1

>           Adrian Farrel, IETF CCAMP Working Group co-chair

>           Deborah Brungard, IETF CCAMP Working Group co-chair

> Cc: Bernard Aboba [email-masked]

>        Ross Callon [email-masked]

>        Bill Fenner [email-masked]

>        CCAMP mailing list [email-masked]

>        GELS mailing list  [email-masked]

> Thank you for your very informative and clarifying liaison on 

> "Use of IEEE 802.1Q VLAN tags".

> We have a question arising from this liaison and our reading 

> of the relevant standards documents as follows.

> The liaison says: "Translation of 802.1Q S-VLAN tags (with 12 

> bit VIDs) is supported at S-tagged service interfaces, as an 

> option, by the IEEE Std 802.1ad Provider Bridging amendment 

> to IEEE Std 802.1Q."

> While this text in itself is clear it leaves open the 

> question of whether "S-tagged Service interfaces" is the only 

> type of interface where Translation of 802.1Q S-VLAN tags is 

> supported.

> It is our understanding that IEEE Std 802.1ad does not 

> preclude the translation of 802.1Q S-VLAN tags at any 

> S-tagged interface. Thus, this translation would be allowed 

> at Provider Network Ports, not just at Customer Network Ports.

> Can you please confirm whether this is the correct 

> interpretation of the IEEE Std 802.1ad amendment to the IEEE 

> Std 802.1Q?

> Many thanks,

> Bert Wijnen, IETF liaison to IEEE 802.1

> Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs

_______________________________________________

gels mailing list

[email-masked]

https://rtg.ietf.org/mailman/listinfo/gels

---

From: <[email-masked]>
Date: Thu, 21 Sep 2006 12:00:05 +0100

Nurit.....precision is indeed important.  In a co mode layer network
connections can be p2p or p2mp in nature and each can be composed of
multiple concatenated subnetwork-connections (ie nodes in THIS layer
network) and link-connections......noting that a single p2p
link-connection hop between 2 bridges in a cl-ps Ethernet layer network
is NOT a connection in THAT (ie Ethernet) layer network (though it will
be supported by a trail which is provided by a connection in some lower
layer network).
 
regards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Nurit Sprecher
Sent: 21 September 2006 12:38
To: Don Fedyk; Adrian Farrel
Cc: [email-masked]; Wijnen, Bert (Bert); [email-masked]; Nurit
Sprecher
Subject: RE: Proposed liaison response to IEEE

Hi,

Regards,

Nurit.

-----Original Message-----

Hi Adrian

relay as well.  

Thanks,

Don

gels mailing list

[email-masked]

---

From: "Nurit Sprecher" <[email-masked]>
Date: Thu, 21 Sep 2006 15:20:02 +0200

I approve the liaison as stated. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Loa Andersson
Sent: Thursday, September 21, 2006 14:03
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Proposed liaison response to IEEE

All,

there have been a number of correct statements in this short thread.

Neil is right (given the layered network model) that Ethernet is a layer
network and as such connectionless and packet oriented.

Nurit is right that if you configure a VLAN on only to parts of an
Ethernet bridge the frame will go through without looking at the MAC
address

Don is right that the liaison does not capture an earlier comment he
made on the gels-list. Neither does it capture a comment made by Attila.

However, if I understand what is happening here is that we need to
clarify a paragraph in the liaison form the IEEE802.1 on translation of
S-VIDs.

I guess that this is something we all need to understand, and given the
answer, it will be possible to follow up with further more precise
questions.

If for example the answer on S-VID translation is that it is not
supported other than at domain borders, then the question on whether it
needs to be done by taking the MAC-address into consideration or not
will have very different meaning.

Let agree on getting the liaison out, and then decide on what we do next
depending on the answer.

/Loa

Nurit Sprecher wrote:
> Hi Neil,
> Thanks for your clarification. 
> Please note that the discussion below relates to the liaison that the 
> IETF wants to send to the IEEE in order to understand the standard 
> behavior of the Ethernet forwarding behavior. As I understand it, Don 
> was concerned that S-VID translation does not preclude the forwarding 
> decision which is based on the MAC address. My intention was to 
> indicate that for point-to-point VLAN connection (on a link), MAC 
> learning is not required by the 802.1Qrev-5 spec and the forwarding 
> decision does not rely on the MAC address. This is not a discussion on

> networking but on the standard behavior of the 802.1Q bridges.
> Regards,
> Nuritl.
> 
> ________________________________
> 
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, September 21, 2006 13:00
> To: Nurit Sprecher; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> link-connection hop between 2 bridges in a cl-ps Ethernet layer 
> network is NOT a connection in THAT (ie Ethernet) layer network 
> (though it will be supported by a trail which is provided by a 
> connection in some lower layer network).
>  
> regards, Neil
> 
> 	I think it is a good idea to send the liaison to the IEEE and
get 
> once and for all a clear statement that the s-vid translation is 
> supported on each provider bridge port.
> 
> 	 
> 
> 	In addition, the IEEE has recognized that MAC learning is not 
> required for point-to-point VLANs in a bridge. The 802.1Q rev-5 
> already includes this extension in section 8.7.
> 
> 	 
> 
> 	and only if the source address is an Individual Address, i.e.,
is not 
> a Group Address, the resulting number of
> 
> 	entries would not exceed the capacity of the Filtering Database,
and 
> the filtering utility criteria for the
> 
> 	The enhanced filtering utility criteria "are satisfied if at
least 
> one VLAN that uses the FID includes the reception Port and at least 
> one other Port with a Port State of Learning or Forwarding in its 
> member set, and: a) The operPointToPointMAC parameter is false for the

> Port. NOTE -The third port can, but is not required to be in the 
> member set.".
> 
> 	 
> 
> 	From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Don Fedyk
> 	MAC is not. If I am correct VLAN translation as specified is not

> equal
> 	'packets on the wire' but the relationship to the entities such
as 
> MAC

--
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                           [email-masked]
_______________________________________________
gels mailing list
[email-masked]
https://rtg.ietf.org/mailman/listinfo/gels

---

From: "Nurit Sprecher" <[email-masked]>
Date: Thu, 21 Sep 2006 16:34:09 +0200

Out of scope of the discussion of the liaison...

In general, I suggest that before statements on what is applicable and
what is not, the IEEE standards are carefully learnt .......
(1) the enhanced filtering criteria does apply with S-VID
translation.....there is a VLAN classification process at the
ingress........the learning process and the forwarding decisions are
taken on the internal VLAN to which the coming frame was
classified.......the translation operation is performed after the
outgoing port is determined........
(2) If that was true, the entire VLAN concept would loose it
meaning............can not we support broadcasting of unknown frames
correctly with s-vid translation???????????
(3) etc.

Nurit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Attila Takacs (IJ/ETH)
Sent: Thursday, September 21, 2006 14:59
To: Loa Andersson
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Proposed liaison response to IEEE

Hi all,

I also support the liaison as it is. 

We will anyhow need to clarify a set of other issues later but these
would now over complicated this liaison.

BTW, I think the enhanced filtering criteria is not applicable if one
applies S-VID translation since the ingress and egress VIDs are
different. An other note: even when the enhanced filtering criteria is
applied the MAC address is considered by forwarding however due to
suppressed MAC learning (no entry for the MAC in FDB) the frame will be
"broadcasted" over the (in this case) only one available egress VLAN
member port.

Regards,
Attila

> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Thursday, September 21, 2006 2:03 PM
> Neil is right (given the layered network model) that Ethernet is a 
> layer network and as such connectionless and packet oriented.
> 
> clarify a paragraph in the liaison form the IEEE802.1 on translation 
> of S-VIDs.
> 
> I guess that this is something we all need to understand, and given 
> the answer, it will be possible to follow up with further more precise

> supported other than at domain borders, then the question on whether 
> it needs to be done by taking the MAC-address into consideration or 
> not will have very different meaning.
> 
> Let agree on getting the liaison out, and then decide on what we do 
> next depending on the answer.
> 
> /Loa
> 
> Nurit Sprecher wrote:
> > Hi Neil,
> [mailto:[email-masked]] On
> > Behalf Of Nurit Sprecher
> > 	I think it is a good idea to send the liaison to the
> IEEE and get
> > 	and only if the source address is an Individual
> Address, i.e., is not
> > 	entries would not exceed the capacity of the Filtering
> Database, and
> > 	The enhanced filtering utility criteria "are satisfied
> if at least
> > 	'packets on the wire' but the relationship to the
> entities such as
> > MAC
> > 
> > 	relay as well.  
> > 
> > 	 
> >

---

From: <[email-masked]>
Date: Thu, 21 Sep 2006 15:59:54 +0100

Thanks Loa.....this sounds OK to me and I'll go with the liaison as-is.

However, one point we should bear in mind and that has not been stated
so far is that the VLAN field assumes a different semantic in a co-ps
mode layer network (be this PBT or VLAN-XC swapping) compared to its
original cl-ps mode Ethernet layer network semantic.  In the co-ps mode
case it is either:
-	part of the trail termination address in PBT that does not get
swapped during forwarding, ie the trail sink term address is the
combination of DMAC+VCID;
-	a proxy for the trail termination address in VLAN-XC (BTW - I am
not clear what VLAN-XC layer network addresses are here) that could be
swapped on each link-connection.

AFAI understand the original IEEE intent of a VLAN was to create a
restricted broadcast domain within which a certain subset of the total
MAC address population reside.

These are quite different semantics.  So asking for clarification of
what IEEE mean by (and the scope of) swapping the VLAN field would still
not really be comparable to such an action in a co-ps mode layer
network.

regards Neil

> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: 21 September 2006 13:03
> Neil is right (given the layered network model) that Ethernet
> is a layer network and as such connectionless and packet oriented.
> 
> Nurit is right that if you configure a VLAN on only to parts
> of an Ethernet bridge the frame will go through without 
> looking at the MAC address
> 
> Don is right that the liaison does not capture an earlier
> comment he made on the gels-list. Neither does it capture a 
> comment made by Attila.
> 
> However, if I understand what is happening here is that we
> need to clarify a paragraph in the liaison form the IEEE802.1 
> on translation of S-VIDs.
> 
> I guess that this is something we all need to understand, and
> given the answer, it will be possible to follow up with 
> further more precise questions.
> 
> If for example the answer on S-VID translation is that it is
> not supported other than at domain borders, then the question 
> on whether it needs to be done by taking the MAC-address into 
> consideration or not will have very different meaning.
> 
> Let agree on getting the liaison out, and then decide on what
> we do next depending on the answer.
> 
> /Loa
> 
> Nurit Sprecher wrote:
> > Hi Neil,
> > decision which is based on the MAC address. My intention
> was to indicate
> > that for point-to-point VLAN connection (on a link), MAC
> learning is not
> > required by the 802.1Qrev-5 spec and the forwarding
> decision does not
> > rely on the MAC address. This is not a discussion on
> networking but on
> > the standard behavior of the 802.1Q bridges.
> > Regards,
> > Nuritl.
> >