[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> Sent: Thursday, September 21, 2006 13:00
> To: Nurit Sprecher; dwfedyk@nortel.com; adrian@olddog.co.uk
> Cc: gels@rtg.ietf.org; bwijnen@lucent.com; ccamp@ops.ietf.org
> Subject: RE: Proposed liaison response to IEEE
>
>
> 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]
> On Behalf Of Nurit Sprecher
> Sent: 21 September 2006 12:38
> To: Don Fedyk; Adrian Farrel
> Cc: gels@rtg.ietf.org; Wijnen, Bert (Bert); ccamp@ops.ietf.org;
> Nurit Sprecher
> Subject: RE: Proposed liaison response to IEEE
>
>
>
> 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: gels-bounces@rtg.ietf.org
> [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Don Fedyk
> Sent: Wednesday, September 20, 2006 23:16
> To: Adrian Farrel; ccamp@ops.ietf.org
> Cc: gels@rtg.ietf.org; 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: 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,
>
> > 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, 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
>
>
>
>
--
Loa Andersson
Principal Networking Architect
Acreo AB phone: +46 8 632 77 14
Isafjordsgatan 22 mobile: +46 739 81 21 64
Kista, Sweden email: loa.andersson@acreo.se
loa@pi.se