Re: [rbridge] comments on draft-ietf-trill-rbridge-oam-00

[Yizhou Li <[e-mail]>]

Hi David,
Please see [yz]

-----Original Message-----
From: David M Bond [mailto:[e-mail]] 
Sent: Tuesday, August 09, 2011 3:28 AM
To: Yizhou Li
Cc: [e-mail]; 'Erik Nordmark'; [e-mail];
[e-mail]
Subject: RE: [rbridge] comments on draft-ietf-trill-rbridge-oam-00

Hi Yizhou,

My main concern here is that the data must be able to look like real data
at least up to the end of the inner ethernet header otherwise the OAM will
be useless if we can't get the data to follow a path data is failing on.

So I guess there are two questions here:
1) Do we allow the Inner.MacDA to be anything other than the reserved
address? I think we have to otherwise we face the problem mentioned above.
If we do allow this should the current channel draft be updated to allow
for this exception?
2) If we allow #1 then an egress Rbridge would have to listen for the OAM
Inner.ethertype and not de-encapsulate that data: rather it would need to
send the frame to the OAM processing. Is this what you are asking for more
explanation on below?

[yz]Yes. I do not have a strong opinion if we should allow Inner.MacDA to be
arbitrary MAC for non-native oam frame. Checking on a reserved destination
multicast mac may be an easier way to identify the oam frame. Using
ethertype only for identifying oam frame seems also workable for me.
Otherwise any better choice? Using native frame does have the problem you
mentioned below.  

Also, I like your idea about using the native rbridge channel frames. If I
understand it correctly essentially this would be involving end stations in
the oam protocol, the only problem is it would only work for ping whereas
traceroute requires the hop count to be varied and the end stations can
only send "untamed" native frames.

Thanks,
David







From:	Yizhou Li <[e-mail]>
To:	David M Bond/Bedford/IBM@IBMUS
Cc:	[e-mail], "'Erik Nordmark'" <[e-mail]>,
            [e-mail], [e-mail]
Date:	08/04/2011 06:47 AM
Subject:	RE: [rbridge] comments on draft-ietf-trill-rbridge-oam-00



Hi David,

For item 3, I am ok with your example on varying Inner.MacSA.
Non-trivial part for me indeed is Inner.MacDA.

draft-ietf-trill-rbridge-channel-02 section 2 says "They are identified as
RBridge Channel messages by their Inner.MacDA, which is the
All-Egress-RBridges multicast address, together with their Inner Ethertype,
which is the RBridge-Channel Ethertype." It appears Inner.MacDA must be a
fixed value.

Channel draft talks about "Native RBridge Channel Frames" which may use end
host's MAC as destination. So I assume we want to use this for testing
different data path by varying Inner.MacDA. My feeling is some detailed
description is needed to make it clearer and more useful for implementers.
E.g. Can we say "egress RB should handle such echo request/reply without
sending it to real destination mac"? If target(egress) RB is not connected
to destination end host, certain specific oam error should be generated?

Yizhou

-----Original Message-----
From: David M Bond [mailto:[e-mail]]
Sent: Thursday, August 04, 2011 2:30 AM
To: Liyizhou
Cc: [e-mail]; Erik Nordmark; [e-mail];
[e-mail]
Subject: Re: [rbridge] comments on draft-ietf-trill-rbridge-oam-00

Hi Yizhou,

Thanks for the detailed review and sorry for the slow response time.
Comments inline below prefaced with DB>:

Thanks,
David



From:		 Liyizhou <[e-mail]>
To:		 "[e-mail]" <[e-mail]>
Cc:		 "[e-mail]" <[e-mail]>, Erik Nordmark
            <[e-mail]>, "[e-mail]" <[e-mail]>,
            "[e-mail]" <[e-mail]>
Date:		 07/27/2011 12:24 PM
Subject:		 [rbridge] comments on
draft-ietf-trill-rbridge-oam-00
Sent by:		 [e-mail]



Hi folks,

Some reviewing comments on draft-ietf-trill-rbridge-oam-00,

1. pg6, table 1 gives the header format of oam frame *in response to*
another data frame. We also need a header format table for self-initiating
oam message like echo request. Table entry for "Inner.MacDA" says
"Inner.MacDA MAY be other values as specified in subsequent sections". But
there is no other value specified indeed.  I believe it was prepared for
ping request as inner.MacDa should be a unicast mac address of destination
RB?

DB> I've added that second table. In regards to the "specified in
subsequent sections" I was referring to "The Inner.VLAN, Inner.MacSA,
Inner.MacDA, Inner.Priority, and Ingress Nickname SHOULD default to the
values specified in Table 1.  Rbridges SHOULD be configurable to change
these values to assign the TRILL data frame to a flow." This however was
for self-generated messages. Thanks, this has been corrected.

2. pg8, 4.1.1, para 3, ..continue transmitting these echo requests,
incrementing the hop-count by one each time until... Looks a bit
ambiguitous to me. Shouldn't echo request be sent with hop-count
incremented by 1 only after hop-count error notification for previous echo
request being received?

DB> My intention here was to leave those specific details up to the
implementer. Each request has a sequence number which can be used for
reordering. If someone wants to sent frames in lock step that's fine but
they can also flood oam frames out quickly if their specific implementation
would work better with that method. The results will be the same
regardless.

3. pg9, para2, "The Inner.VLAN, Inner.MacSA, Inner.MacDA, Inner.Priority,
and Ingress Nickname SHOULD default to the values specified in Table 1.
RBridges SHOULD be configurable to change these values to assign the TRILL
data frame to a flow. " For unicast tracert with specified two RBridges, if
we assume each RB has single MAC address for oam, Inner.MacSA, Inner.MacDA
and Ingress Nickname are all fixed values. Inner.vlan may take different
value (table 1 indeed says it should be 1) but does not make much sense.
Priority may have different value but very restricted. Therefore it lacks a
lot of details on how to vary those values to get different flow? I suggest
to remove this and leave it for future tool such as ecmp oam. Or say
details could be find in future draft? If we want to keep it,  better to
give some explaination, e.g. explicitly say virtual internal end station
inside RB possily allows to be configured for different MACs?

DB> These are intended to be configuration options on say a command line
implementation (ttraceroute -ivlan 2 0x1234). Remember this OAM traffic
must mimic real data which would otherwise be coming from an end station.
Each Rbridge has a single mac address but it may be attached to multiple
end stations. So let's say I'm an operator and I seeing traffic destined to
00:11:22:33:44:55 failing while traffic to 00:11:22:33:44:66 is getting
through. Both of these devices are on a single L2 LAN and are therefore
connected to the same egress rbridge. Their flows however might be
transiting through the TRILL Campus through different ECMP paths and one of
those paths might be failing. If I don't have this ability to change say
the inner dst mac from the egress Rbridges dst mac to a connected end
station's dst mac then I lack the ability to locate the failure in the
campus. Does this sentence "e.g. The Inner.MacSA might be changed to the
MAC address of an end station connected to the ingress Rbridge to alter the
ECMP path frames coming from that end station follow through the TRILL
campus." appended to the end of that paragraph help explain the meaning
better? Additionally describing how flows are classified I feel is beyond
the scope of this document since the base draft does not specify that as
well and it is up to each vendor to determine their transit hash method
works.

4. pg9, para3, "incoming port field" ->"Incoming Port ID TLV", "include its
16-bit port ID from the port on which.." ->"include its 16-bit port ID from
the port on which...in Outgoing Port ID TLV in reply..." , "If the request
is a multi-destination frame, this field..." better moves to "4.1.1.1.
Multi-Destination Targets".

DB> Agreed

5. pg9, para5, lack of description on timeout and re-transmission of echo
request

DB> This is implementation specific and does not affect interoperability. I
would prefer to leave that up to the implementers specific needs. What does
everyone else think in regards to this? Should we specify a
re-transmission/timeout algorithm?

6. pg10, 4.1.1.2, "hop-count-exceeded message" -> "Hop Count Zero error
notification"

DB> Agreed

7. pg11, table 2, column "TRILL OAM Protocol", "Hop Count Error" -> "Hop
Count Zero error notification", "hop count" for error is "N/A", what is the
value for "N/A"? is it maximun 0x3F?

DB> Agreed, changes N/A to default (aka what the base protocol spec
specifies.

8. pg12, para4, lack of description on srcMac, destMac and hop count. It
refers to table 1, but original table 1 is only for responding oam message.

DB> Added table for self originated messages and updated reference. Thanks.

9. pg15, 4.2.1, If the request is a multi-destination frame, this field
MUST be set to all zeros.... However pg9 para3 says if it is for
multi-destination traceroute, next hop nickname should be "previous hop
nickname"? Should have some clarification. Here it talks about normal data
frame but not oam echo request frame.

DB> This is a mistake. They should both be the previous hop nickname.
Thanks, fixed.

10. pg18, 6.2, SPID is never used in error notification. Error notification
uses channel protocol number 5 while echo use 4. Can we make SPID field
here to be used for error type and make the subcode to be 16-bit long
instead?

DB> I have no objection to this. What do other people feel?

11. pg18, last line, typo, dup. Requests

DB> Fixed

12. pg19, para above 6.2.1, bullet TLVs. "For next hop errors"->"For Hop
Count Zero error"

DB> Fixed

13. pg19, 6.2.1, "The sub-code values fall into three categories...", there
are 4 error type as described in previous section bullet.  It is unclear
between permanent error and transient error.

DB> Let me get back to you on that one.

14. pg19, error code 2. I assume it is valid that the MAC Address is not a
multicast address and the M bit is one? Remember there are some discussion
regarding some corner cases of this. Not too sure. Moreover, can we call
this error M bit mismatch or something like it to make it more descriptive?

DB> Yes this is the intent. I have updated the name as suggested.

15. pg20, error 11. "exceeded its hop count.. " -> hop count reaches zero?

DB> Fixed

16. pg24, 7.1, what if next hop has multiple nicknames? list all, list one
with lowest value or list one with highest value? Duplicate description on
multi-destination traceroute and multi-destination hop-count errors.

DB> Added this sentence "If an Rbridge has multiple nicknames it SHOULD use
the numerically largest nickname in the Next Hop Nickname TLV."

Another general comment is we want to make sure traceroute tool sends out
echo request with same header contents each time until it reaches the final
destination though RB allows the different configurations for testing
flow-based path. It gurantees it follows the same path for incremental
trace in tracert.

DB> Added this sentence "An Rbridge must keep the TRILL header contents the
same for ever frame sent in a hop count traceroute."

Yizhou

 _______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge





_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge