|
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 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 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----- 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: owner-ccamp@ops.ietf.org > 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, > > === > 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, tony@jeffree.co.uk > > 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 bernard_aboba@hotmail.com > Ross
Callon rcallon@juniper.net > Bill
Fenner fenner@research.att.com > CCAMP
mailing list ccamp@ops.ietf.org > GELS
mailing list gels@rtg.ietf.org > > 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 gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels |