Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQMNG-00044h-U2 for ccamp-archive@ietf.org; Thu, 21 Sep 2006 07:05:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQMN9-0002Su-DE for ccamp-archive@ietf.org; Thu, 21 Sep 2006 07:05:46 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQMHr-0002Dy-Lt for ccamp-data@psg.com; Thu, 21 Sep 2006 11:00:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [217.32.164.151] (helo=smtp4.smtp.bt.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQMHp-0002DO-AR for ccamp@ops.ietf.org; Thu, 21 Sep 2006 11:00:09 +0000 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 12:00:07 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Sep 2006 12:00:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DD6D.1821739E" Subject: RE: Proposed liaison response to IEEE Date: Thu, 21 Sep 2006 12:00:05 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389188A9743@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed liaison response to IEEE Thread-Index: Acbc7HRnAX/g41+pSkGzWxFpSzGTXAAAF6CAACBecuAAANq2gA== From: To: , , Cc: , , X-OriginalArrivalTime: 21 Sep 2006 11:00:06.0407 (UTC) FILETIME=[18CF9970:01C6DD6D] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 3a364894605f80b4cf7342846f9183e6 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DD6D.1821739E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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). =20 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, =20 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.=20 =20 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.=20 =20 " 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.".=20 =20 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. =20 Regards, Nurit. =20 -----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 =20 Hi Adrian =20 The Liaison looks good however it does not capture a comment I made. =20 =20 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. =20 =20 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. =20 Thanks, Don =20 =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > All, >=20 > The IETF received an unsolicited liaison on the subject of=20 > 802.1 Ethernet >=20 > You can see the liaison at > https://datatracker.ietf.org/documents/LIAISON/file358.pdf >=20 > The participants on the GELS mailing list have requested that=20 > we respond to this to clarify an issue. >=20 > Here is the draft of a liaison that we proposed to send.=20 > Please shout at once if you have any concerns with this=20 > liaison. I intend to ask Bert to send it on Monday of next week. >=20 > Thanks, > Adrian > =3D=3D=3D > Subject: Response to your liaison "Use of IEEE 802.1Q VLAN tags" >=20 > Date: Sep 2006 > To: IEEE802.1 > Tony Jeffree, IEEE 802.1 WG Chair, tony@jeffree.co.uk >=20 > 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 >=20 > 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 >=20 > Thank you for your very informative and clarifying liaison on=20 > "Use of IEEE 802.1Q VLAN tags". >=20 > We have a question arising from this liaison and our reading=20 > of the relevant standards documents as follows. >=20 > The liaison says: "Translation of 802.1Q S-VLAN tags (with 12=20 > bit VIDs) is supported at S-tagged service interfaces, as an=20 > option, by the IEEE Std 802.1ad Provider Bridging amendment=20 > to IEEE Std 802.1Q." >=20 > While this text in itself is clear it leaves open the=20 > question of whether "S-tagged Service interfaces" is the only=20 > type of interface where Translation of 802.1Q S-VLAN tags is=20 > supported. >=20 > It is our understanding that IEEE Std 802.1ad does not=20 > preclude the translation of 802.1Q S-VLAN tags at any=20 > S-tagged interface. Thus, this translation would be allowed=20 > at Provider Network Ports, not just at Customer Network Ports. >=20 > Can you please confirm whether this is the correct=20 > interpretation of the IEEE Std 802.1ad amendment to the IEEE=20 > Std 802.1Q? >=20 > Many thanks, >=20 > Bert Wijnen, IETF liaison to IEEE 802.1 > Adrian Farrel and Deborah Brungard, CCAMP Working Group co-chairs >=20 >=20 >=20 >=20 =20 _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels =20 ------_=_NextPart_001_01C6DD6D.1821739E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Nurit.....precision is indeed important.  In a co mode = layer network=20 connections can be p2p or p2mp in nature and each can be composed of = multiple=20 concatenated subnetwork-connections (ie nodes in THIS layer network) and = link-connections......noting that a single p2p link-connection hop = between 2=20 bridges in a cl-ps Ethernet layer network is NOT a connection in = THAT (ie=20 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:=20 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of=20 Nurit Sprecher
Sent: 21 September 2006 = 12:38
To: Don=20 Fedyk; Adrian Farrel
Cc: gels@rtg.ietf.org; Wijnen, Bert = (Bert);=20 ccamp@ops.ietf.org; Nurit Sprecher
Subject: RE: Proposed = liaison=20 response to IEEE

Hi,

 

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

 

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

 

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

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

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

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

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

receiving Bridge = Port are = met."

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

 

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

 

Regards,

Nurit.

 

-----Original Message-----
From:=20 gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf = Of Don=20 Fedyk
Sent: Wednesday, September 20, 2006 23:16
To: Adrian = Farrel;=20 ccamp@ops.ietf.org
Cc: gels@rtg.ietf.org; Wijnen, Bert = (Bert)
Subject:=20 RE: Proposed liaison response to IEEE

 

Hi Adrian

 

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

 

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

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

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

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

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

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

relay as well.  =

 

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

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

the MAC so there is no=20 confusion.

 

Thanks,

Don

 

 

> -----Original=20 Message-----

> From: owner-ccamp@ops.ietf.org=20

> All,

>

> The IETF received an unsolicited = liaison on the=20 subject of

> 802.1 = Ethernet

>

> You can see the liaison=20 at

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

>

> The participants on the GELS mailing = list have=20 requested that

> we respond to this to clarify an=20 issue.

>

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

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

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

>

> Thanks,

> Adrian

> =3D=3D=3D

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

>

> Date: Sep = 2006

> To: = IEEE802.1

>      Tony = Jeffree, IEEE=20 802.1 WG Chair, tony@jeffree.co.uk

>

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

>          =20 Adrian Farrel, IETF CCAMP Working Group = co-chair

>          =20 Deborah Brungard, IETF CCAMP Working Group=20 co-chair

>

> Cc: Bernard Aboba=20 bernard_aboba@hotmail.com

>        Ross=20 Callon rcallon@juniper.net

>        Bill=20 Fenner fenner@research.att.com

>        CCAMP=20 mailing list ccamp@ops.ietf.org

>        GELS=20 mailing list  gels@rtg.ietf.org

>

> Thank you for your very informative and = clarifying liaison on

> "Use of IEEE 802.1Q VLAN=20 tags".

>

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

> of the relevant standards documents as=20 follows.

>

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

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

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

> to IEEE Std = 802.1Q."

>

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

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

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

> supported.

>

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

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

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

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

>

> Can you please confirm whether this is = the=20 correct

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

> Std = 802.1Q?

>

> Many = thanks,

>

> Bert Wijnen, IETF liaison to IEEE=20 802.1

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

>

>

>

>

 

_______________________________________________

gels mailing = list

gels@rtg.ietf.org

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

 

------_=_NextPart_001_01C6DD6D.1821739E--