Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03

From: Erik Nordmark <[email-masked]>
Date: Wed, 01 Feb 2012 11:25:58 -0800

We're starting three separate last calls this week, but they are all 
very short documents.

We had an earlier WG last call on this document 6 months ago, and there 
were some concerns about using the IS-IS genapp mechanism, so that use 
has been removed.

The WG last call ends on Feb 15th.
Please send comments (including ones that say you've read the document 
and it is fine) to the rbridge list.

   Erik

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Yizhou Li <[email-masked]>
Date: Thu, 02 Feb 2012 09:33:02 +0800

The latest version should be 04.

Yizhou

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Erik Nordmark
Sent: Thursday, February 02, 2012 3:26 AM
To: [email-masked]
Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 01 Feb 2012 20:00:35 -0800

> The latest version should be 04.

Yes. Thanks for the correction.

    Erik

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 9 Feb 2012 11:50:37 -0800

Here are some comments on the document.

Technical comments
===============

- I'm a bit concerned about the hop-by-hop processing which
  requires the ability to look at a bit in the extended header.
  I don't know if any alternatives were discussed...perhaps
  using a different inner.MACDA multicast address which indicates
  hop-by-hop processing is desired would work much better and
  would be compatible with existing silicon.  Would there be
  any issues with using a separate multicast address for
  indicating hop-by-hop processing?

- State that the "Available Flags" part is reserved; i.e. set
  to zero on transmit, ignore on receipt.

- Section 3
      2. If an RBridge Channel Alert extended header flag is set, then
         the RBridge MUST process the RBridge Channel message as
         described below even if it is not egressing the frame. If it is
         egressing the frame, then no additional processing beyond
         egress processing is needed even if an RBridge Channel Alert
         flag is set.
  Since the inner.MACDA is
  always All-Egress-RBridges, how would such a frame ever be
  allowed to be sent out an egress RBridge?  It seems like end
  station can send a channel message, but an RBridge can't send
  one to an end station.

- Section 3.2
   For the protocol specific data area, an
   RBridge Channel Message Error frame has at least the first 256 bytes
   (or less if less are available) of the erroneous decapsulated channel
   message starting with the TRILL Header. (Note: The TRILL Header does
   not include the TRILL Ethertype that is part of the Link Header on
   Ethernet Links and may be absent for other link technologies.)

  What if the channel frame is a native frame?  This aspect is not
  dealt with even in the section concerning native frames.

- Section 4
      2. If the frame is unicast, the destination MAC address is the
         unicast MAC address of the RBridge or end-station port that is
         its intended destination. If the frame is multicast by an end
         station to all the RBridges on a link that support an RBridge
         Channel protocol that uses this transport, the destination MAC
         address is the All-Edge-RBridges multicast address. If the
         frame is multicast by an RBridge to all the devices that TRILL
         considers to be end stations on a link that support an RBridge
         Channel protocol that uses this transport, the destination MAC
         address is the TRILL-End-Stations multicast address (see
         Section 6). The RBridge-Channel Ethertype must be present. In
         the future there may be other protocols using the All-Edge-
         RBridges and/or TRILL-End-Stations multicast addresses on
         native frames distinguished by different Ethertypes.
  This imposes some interesting requirements for filtering on ingress
  to the RBridge.  For example, what if the address on a channel frame
  does not match any of the ones specified above?  Do we assume
  that channel messages received in native format must either be
  processed by the receiving RBridge or discarded?  In other words
  it should not be possible to send a channel protocol frame from
  outside the TRILL network that enters or transits the TRILL network.

Editorial comments
==============
- Section 1, 4th line
  "the implement" -> "that implement.

- Pg 5, line 9 from bottom
  depend -> and depending

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 13 Feb 2012 22:22:28 -0500

Hi Anoop,

Thanks for the comments. See below:

On Thu, Feb 9, 2012 at 2:50 PM, Anoop Ghanwani <[email-masked]> wrote:
> - I'm a bit concerned about the hop-by-hop processing which requires
> the ability to look at a bit in the extended header. I don't know if
> any alternatives were discussed...perhaps using a different
> inner.MACDA multicast address which indicates hop-by-hop processing
> is desired would work much better and would be compatible with
> existing silicon. Would there be any issues with using a separate
> multicast address for indicating hop-by-hop processing?

I think the vast majority of channel protocols will either be (1) one
hop or (2) multi-hop with no per hop processing. In the case of a
multi-hop channel protocol frame that needs hop-by-hop processing (for
example something like record route or some protocol that wants source
routing), there are lots of ways you could modify such a frame to
alert the transit RBridges along the way. But these frames will
commonly be unicast, in which case there is no reason in the TRILL
base protocol for a transit RBridge to look at anything after the
TRILL Header, such as the Inner.MacDA. So you need to change something
in the TRILL Header. You could use a bit in the V field and/or the R
field, but people seemed to be against using those bits.

Anyway, setting the TRILL Header Extension Length (called Options
Length in RFC 6325) non-zero causes all the TRILL silicon I know about
to divert the frame to the slow path, which is the desired effect for
now. There is no need for the fast path logic to "look at" the
extended header at this time.

This is exactly how it was in the earlier version of this draft which
passed WGLC:
http://tools.ietf.org/html/draft-ietf-trill-rbridge-channel-01
The only difference is that, in response to comments on this list, the
previous non-critical Alert Flag was supplemented by a critical Alert
Flag.

> - State that the "Available Flags" part is reserved; i.e. set to
>zero on transmit, ignore on receipt.

An excellent suggestion. How about, in Section 2.1.1, changing the
figure so the bits are labeled "Reserved" instead of "Available Flags"
and, after the descriptions of bits 0 thorugh 2, adding something
like:

   "Reserved: Bits reserved for future specification that MUST be sent
as zero and ignored on receipt."

> Since the inner.MACDA is always All-Egress-RBridges, how would such
> a frame ever be allowed to be sent out an egress RBridge? It seems
> like end station can send a channel message, but an RBridge can't
> send one to an end station.

"Egressing" means being decapsulated, that is, leaving the TRILL
tunnel. You are correct that RBridge Channel protocol frames are only
intended to go between RBridges. But there are native RBridge Channel
messages that go between RBridges and end stations on the same link as
described in Section 4. An RBridge can create a native RBridge Channel
frame and unicast it to an attached end station, etc.

You could also have a channel protocol, for example, that went from an
RBridge RB1, through RB2, to an end station or from that end station
through RB2 to RB1, but the frames would have to be manipulated by
that channel protocol at RB2 to convert between non-native and native
forms. At a minimum, the native channel frame has no TRILL Header
while the non-native inter-RBridge channel frame does. In addition,
you would have to complement the NA bit in the Channel Header and
adjust MAC addresses. That's what the next to the last paragraph in
Section 4 is about. But I would think that almost all channel
protocols would either be between RBridges or between an edge RBridge
and an end station.

> dealt with even in the section concerning native frames.

Good point. The idea is to have all the differences between native and
non-native channel frames described in Section 4. The last paragraph
of Section 4 already mentions one native RBridge channel error message
difference. That last pragraph in Section 4 should have something like
the following added:

   "Also, since there is no TRILL Header in native RBridge Channel
   protocol frames, the beginning part of the frame in which the error
   was detected that is included in native RBridge Channel error
   frames starts with the RBridge Channel Header."

>  >>>
> to the RBridge.

It only imposes requirements on edge RBridges (or end stations) that
want to support one or more native RBridge channel protocols...

> For example, what if the address on a channel frame
> does not match any of the ones specified above?

I assume you are talking about a native RBridge channel frame since
the requirements on the Outer.MacDA of non-native RBridge channel
frames is the same as on TRILL Data frames.

So, as per the text above, a native RBridge channel frame arriving at
an edge RBridge must have an Outer.MacDA of either the port's unicast
MAC address of the All-Edge-RBridges multicast address. If it has a
different unicast address, it is presumably intended for another
RBridge on the link and is discarded. If it has a different multicast
address, it is discarded.

> Do we assume that
> channel messages received in native format must either be processed
> by the receiving RBridge or discarded? In other words it should not
> be possible to send a channel protocol frame from outside the TRILL
> network that enters or transits the TRILL network.

Yes, that is my assumption. Probably a specific statement to that
effect should be added.

> Editorial comments

Thanks for spotting that.

> - Pg 5, line 9 from bottom

Thanks again.

For a version show suggested resolutions of your comments and a
comparison to the current -04, see
http://www.pothole.com/~dee3/drafts/

Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 14 Feb 2012 08:45:43 -0800

Hi Donald,

Thanks for the response.  I have pulled out sections of the
text that I want to respond to.

> extended header at this time.

But it probably won't be able to prioritize the frame
correctly.

If a message is going to be processed hop-by-hop, and it is
unicast, would it not be better to just use the "AnyRBridge" nickname
and embed the eventual egress RBridge in the payload?  That way
it becomes easily compatible with existing hardware.  So, for the
multicast case, we use a different reserved MAC, and for the
unicast case we use AnyRBridge.  I don't see that there would be
any loss of functionality if we did that.

> frame and unicast it to an attached end station, etc.

Per your description, this would not be a valid case of
"egressing", so the above text wouldn't apply to this case.

> protocols would either be between RBridges or between an edge RBridge

Would the case of manipulation be considered "egressing"?
Since egressing in the strict sense is simplying decapsulating the
frame and sending it out as a native frame, it seems to me that
the scenario described in the quoted text should never happen.

Anoop

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 15 Feb 2012 00:02:55 -0500

Hi Anoop,

> But it probably won't be able to prioritize the frame

I don't see why there would be a prioritization problem. The
Inner.VLAN tag is still there with the priority for re-queueing the
frame if it is forwarded.

> any loss of functionality if we did that.

The technique currently in the draft also seems to work fine and,
given that it previously got WG consensus, I don't particularly want
to change it.

> "egressing", so the above text wouldn't apply to this case.

There are two things being discussed. An RBridge-to-RBridge channel
message does get de-capsulated/egressed at its egress RBridge(s) (can
be more than one if multi-destination). But you are right that
creation and transmission and the reception and processing of a native
channel message does not involve "egressing" or "engrossing".

> Would the case of manipulation be considered "egressing"?

No, I don't think so. If the message went from RB1 to edge RBridge
RB2, it would be decapitated (egressed) at RB2. The manipulate would
be after the egressing and before the transmission as a native frame.

> the scenario described in the quoted text should never happen.

I guess you are right. I was using "egressing" in other than the
strictest sense -- as decapsulating and delivering, where delivering
might be transmitting through an external port but could just be
delivering to the slow path...

> Anoop

Thanks,
Donald

---

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 15 Feb 2012 17:45:39 -0800

Hi Donald,

OK, regarding the use of the extended header, I guess I can
live with it, assuming others are OK with it.

Regarding the "egressing" issue, I assume you'll be modifying
the text to make it clearer.  It might also be good to have a statement
that says channel messages only go between RBridges,
or between an Rbridge and an end station; i.e. you can't
have a channel message that goes from a "core" Rbridge
to an end station without going through processing (which
is more than simple egress decapsulation) at the egress
RBridge.

Thanks,
Anoop

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 15 Feb 2012 23:57:46 -0500

Hi Anoop,

On Wed, Feb 15, 2012 at 8:45 PM, Anoop Ghanwani <[email-masked]> wrote:
> ...

OK. I'll try to make that clearer.

Thanks,
Donald

---

From: ayabaner <[email-masked]>
Date: Wed, 15 Feb 2012 22:51:58 -0800

Had a quick question on the following:

   The RBridge-Channel Ethertype indicates that the frame
   is an RBridge Channel message. The only other Ethertype currently
   specified for use with the All-Egress-RBridges Inner.MacDA is L2-IS-
   IS to indicate an ESADI frame [RFC6325]. In the future additional
   Ethertypes may be specified for use with the All-Egress-RBridges
   multicast address.

Would there be an easy method to see this list in the future?

Also, in Section 4, from the below paragraph:

   If provided for by the channel protocol involved, the receipt of such
   a native RBridge Channel frame MAY lead to the generation and
   transmission of one or more native or TRILL Data RBridge Channel
   frames.  The decapsulation and processing of a TRILL Data RBridge
   Channel frame MAY, if provided for by the channel protocol involved,
   result in the sending of one or more native RBridge channel frames to
   one or more end stations.

Does this imply the original frame may be modified by the transit nodes, say
with respect to the destination address used. If so, can we make that a bit
more explicit.

Thanks,
Ayan

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 16 Feb 2012 14:24:00 -0500

Hi Ayan,

> Would there be an easy method to see this list in the future?

I would think so for  Ethertypes to the IETF. But I don't know of any
beyond the above two that are currently being suggested.

I don't think there would be anything stopping a proprietary extension
of some sort with a different Ethertype here and the IETF might not
even know about such an extension.

> with respect to the destination address used. If so, can we make that a bit

That paragraph is not meant to say anything about transit nodes. But
it could be modified at the egress (decapsulation) / ingress
(encapsulation) node. I've tried to make things clearer in a
-05candidate1 version which is available along with a wdiff at
http://www.pothole.com/~dee3/drafts/

Thanks,
Donald

---

From: ayabaner <[email-masked]>
Date: Thu, 16 Feb 2012 12:02:09 -0800

Donald,

Responses in-line.

Thanks,
Ayan

> http://www.pothole.com/~dee3/drafts/

I have read through the candidate draft and it is much easier to follow. I
did mean the egress/ingress node that was changing the message from a TRILL
frame to a native frame and vice versa (wrong terminology choice :)).

Thanks,
Ayan

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Fri, 17 Feb 2012 21:29:56 -0800

I have read this draft and have following comments.

1. This draft indicates the channels encaps proposed can be utilized as
a general method of sending OAM messages. 
[Comment] I disagree with that comment. As the channel it is defined
currently. Utilize a fixed Multicast MAC address and specific Ethtype.
Additionally it require to use Source MAC address that belong to the
originating switch.

In OAM the messages need to follow the path that the data frames takes.
With the above methods these channel frames follow a different path than
the data. Hence this cannot be effectively used for OAM.

2. This draft propos to use Channel header extended header flags for
certain conditions. 
[comment] This may alter the forwarding path of the channel frame from
the original frames. Again that may reduce the coverage of OAM. What is
not clear is can a RBridges that cannot support extended header can
advertise itself as channel capable ?

I propose this draft if needed to be moved to RFC state to remove all
reference to OAM. 

During the last WG in Taipei it was discussed that OAM proposals that
are based on the channel encapsulations may not really provide the ECMP
coverage 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Erik Nordmark
Sent: Wednesday, February 01, 2012 11:26 AM
To: [email-masked]
Subject: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03

   Erik

---

From: Jon Hudson <[email-masked]>
Date: Sat, 18 Feb 2012 00:38:04 -0800

May I also suggest that if another version is created that TRILL-channel
may be a more appropriate name than rbridge-channel.

-- 
"Do not lie. And do not do what you hate."
"Don't worry, be happy"
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 18 Feb 2012 08:57:14 -0500

Hi Tissa,

> the data. Hence this cannot be effectively used for OAM.

I guess you would have really hated the earlier versions where it was
called the "OAM Channel" instead of the "RBridge Channel"... :-)

You can use the channel mechanism for a variety of purposes including
sending certain limited kinds of OAM messages. For example, it seems
to me that it works fine for one-hop BFD messages or BFD Echo to a
neighbor.

> I propose this draft if needed to be moved to RFC state to remove all

I think it is a good thing to reference at least one use as motivation
when adding a new facility. "OAM" is currently mentioned only in the
Abstract and the first section of the Introduction. How about if I
replace that with a reference to BFD?

> are based on the channel encapsulations may not really provide the ECMP

Yes, that's right. Other mechanisms, similar to draft-tissa-trill-oam
are probably better for general OAM.

Thanks,
Donald

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Sat, 18 Feb 2012 09:09:33 -0800

Hi Donald

I am ok, replacing OAM with BFD

Thanks
Tissa

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Saturday, February 18, 2012 5:57 AM
To: Tissa Senevirathne (tsenevir)
Cc: Erik Nordmark; [email-masked]
Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-channel-03

Hi Tissa,

Thanks,
Donald

---

From: Vishwas Manral <[email-masked]>
Date: Sat, 18 Feb 2012 22:33:07 -0800

Hi Tissa,

> the data. Hence this cannot be effectively used for OAM.
I agree partially with what you say. The channel is to allow sending.
receiving packets directly over the TRILL layer. It gives a way to
demultiplex different kinds of packets and can be used for OAM packets. If
I understand correctly not all data frames in the DC are TCP/ UDP based?

Also in the ideal case the forwarding in the TRILL layer should depend on
the TRILL header. In this case the TRILL of the channel header is the same
as that of the data packet. I however understand for good multiplexing we
do look deeper into the packet, but what that also leads to is the fact
that all DC switches should now be able to support looking deeper into IPv6
and all its present/ future extension headers to provide the ideal
de/multiplexing, which may not be the case .

> are based on the channel encapsulations may not really provide the ECMP
VM> Like I mentioned, I agree there are limitations because of the fact we
do deeper packet inspection for doing ECMP/ LAG mux/ demux. I however do
not see why it cannot be used in cases I have mentioned above.

Thanks,
Vishwas

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Mon, 20 Feb 2012 08:50:01 -0800

Hi Vishwas

Very interesting comment "not all traffic in networks are IP". Yes not
all traffic in networks are IP, in the same token majority of traffic in
networks are IP.

While TRILL does forwarding based on TRILL header and supports Equal
cost multi-pathing. Traffic is allocated to multiple equal cost paths
per flow basis. While definition of a flow is outside the scope of
RFC6325, in classical Ethernet Ling Aggregation bundles, traffic is
hashed to different links based on L3 information. This is a very common
practice. 

When you are defining generic OAM channel it is important to provide
flexibility to address full set of issues rather than sub-set.

My objection on presenting rbridge-channel draft as a generic OAM
messaging channel is based on the fact that it covers only a subset. It
may cover some specific needs of applications such as BFD.

I am ok if wording of reference to generic OAM is replaced with wording
of like "messaging channel for applications such as BFD"

 

From: Vishwas Manral [mailto:[email-masked]] 
Sent: Saturday, February 18, 2012 10:33 PM
To: Tissa Senevirathne (tsenevir)
Cc: Erik Nordmark; [email-masked]
Subject: Re: [rbridge] WG last call of
draft-ietf-trill-rbridge-channel-03

Hi Tissa,

	1. This draft indicates the channels encaps proposed can be
utilized as
	a general method of sending OAM messages.
	[Comment] I disagree with that comment. As the channel it is
defined
	currently. Utilize a fixed Multicast MAC address and specific
Ethtype.
	Additionally it require to use Source MAC address that belong to
the
	originating switch.
	
	In OAM the messages need to follow the path that the data frames
takes.
	With the above methods these channel frames follow a different
path than
	the data. Hence this cannot be effectively used for OAM.

I agree partially with what you say. The channel is to allow sending.
receiving packets directly over the TRILL layer. It gives a way to
demultiplex different kinds of packets and can be used for OAM packets.
If I understand correctly not all data frames in the DC are TCP/ UDP
based?

Also in the ideal case the forwarding in the TRILL layer should depend
on the TRILL header. In this case the TRILL of the channel header is the
same as that of the data packet. I however understand for good
multiplexing we do look deeper into the packet, but what that also leads
to is the fact that all DC switches should now be able to support
looking deeper into IPv6 and all its present/ future extension headers
to provide the ideal de/multiplexing, which may not be the case .

	2. This draft propos to use Channel header extended header flags
for
	certain conditions.
	[comment] This may alter the forwarding path of the channel
frame from
	the original frames. Again that may reduce the coverage of OAM.
What is
	not clear is can a RBridges that cannot support extended header
can
	advertise itself as channel capable ?
	I propose this draft if needed to be moved to RFC state to
remove all
	reference to OAM.
	
	During the last WG in Taipei it was discussed that OAM proposals
that
	are based on the channel encapsulations may not really provide
the ECMP
	coverage

VM> Like I mentioned, I agree there are limitations because of the fact
we do deeper packet inspection for doing ECMP/ LAG mux/ demux. I however
do not see why it cannot be used in cases I have mentioned above.

Thanks,
Vishwas

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On
	Behalf Of Erik Nordmark
	Sent: Wednesday, February 01, 2012 11:26 AM
	To: [email-masked]
	Subject: [rbridge] WG last call of
draft-ietf-trill-rbridge-channel-03

	We're starting three separate last calls this week, but they are
all
	very short documents.
	
	We had an earlier WG last call on this document 6 months ago,
and there
	were some concerns about using the IS-IS genapp mechanism, so
that use
	has been removed.
	
	The WG last call ends on Feb 15th.
	Please send comments (including ones that say you've read the
document
	and it is fine) to the rbridge list.
	
	  Erik