Subject: Re: [rbridge] Default port type

From: rakesh kumar <[email-masked]>
Date: Wed, 14 Dec 2011 14:09:09 +0530

Hi Radia,

I think if both bits are on,port should act as access port according to
RFC6325 section 4.9.1

RFC6325 section 4.9.1:
"The dominance relationship of these four configuration bits is as
follows, where configuration bits to the left dominate those to the
right. That is to say, when any pair of bits is asserted,
inconsistencies in behavior they mandate are resolved in favor of
behavior mandated by the bit to the left of the other bit in the this
list.
Disable > P2P > Access > Trunk"

Regards,
Rakesh

---------- Forwarded message ----------
From: <[email-masked]>
Date: Tue, Dec 13, 2011 at 11:06 PM
Subject: rbridge Digest, Vol 91, Issue 12
To: [email-masked]

Send rbridge mailing list submissions to
       [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
       http://mailman.postel.org/mailman/listinfo/rbridge
or, via email, send a message with subject or body 'help' to
       [email-masked]

You can reach the person managing the list at
       [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of rbridge digest..."

Today's Topics:

  1. Queries on RFC 6325 - Default port type (Abhinav Bhatia)
  2. Request to read "TRILL IS-IS MTU Negotiation"//FW: New
     Version Notification for draft-zhang-trill-mtu-negotiation-02.txt
     (Mingui Zhang)
  3. Queries on RFC 6325 trunk bit (rakesh kumar)
  4. Re: Queries on RFC 6325 - Default port type (Donald Eastlake)
  5. Re: Queries on RFC 6325 trunk bit (Donald Eastlake)
  6. Re: Queries on RFC 6325 - Default port type (Radia Perlman)

----------------------------------------------------------------------

Message: 1
Date: Tue, 13 Dec 2011 13:30:09 +0530
From: Abhinav Bhatia <[email-masked]>
Subject: [rbridge] Queries on RFC 6325 - Default port type
To: [email-masked]
Message-ID:
       <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

 Hi ,

I looked at some of the posts and RFC, there is confusion on the default
settings to the trill port. According to RFC it seems the default settings
is both access and trunk bits are 0.
In this mode port will do both encapsulation/decapsulation and forward the
trill data packet. If yes the what should be the behaviour when both the
bits are set.

>From rbridge Digest, Vol 91, Issue 4

*" If the DRB port on the link is not an access port but some other*
*> RBridge's port is an access port, the link is misconfigured. It would*
*> probably work fine to appoint an RBridge with an access port on such a*
*> misconfigured link as an Appointed Forwarder. But, since that RBridge*
*> disagrees with the DRB about the type of service being provided on the*
*> link and the DRB is, generally, in charge, I think the idea was to*
*> isolate the inconsistent non-DRB RBridge as much as possible."*
**
Does above bold statement means only trunk port or does it include both
"trunk and access bit set 0"?

Regards,
Abhinav
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.postel.org/pipermail/rbridge/attachments/20111213/ef08d00d/attachment-0001.html

------------------------------

Message: 2
Date: Tue, 13 Dec 2011 08:37:21 +0000
From: Mingui Zhang <[email-masked]>
Subject: [rbridge] Request to read "TRILL IS-IS MTU Negotiation"//FW:
       New Version Notification for draft-zhang-trill-mtu-negotiation-02.txt
To: "[email-masked]" <[email-masked]>
Message-ID:
       <
[email-masked]>

Content-Type: text/plain; charset=utf-8

Hi,

A new version of the draft has been uploaded to the IETF repository. This
document offers some meaningful use cases, defines a new value link-wide Lz
to break the relevance between MTU testing and campus-wide Sz, and designs
a useful method for MTU testing. We are considering whether we should
include it into the WG documents. Please help to review it and make
comments.

  > -----Original Message-----
  > From: [email-masked] [mailto:[email-masked]]
  > Sent: Tuesday, December 13, 2011 4:24 PM
  > To: Mingui Zhang
  > Cc: [email-masked]; Mingui Zhang; Zhangxudong
  > Subject: New Version Notification for
draft-zhang-trill-mtu-negotiation-02.txt
  >
  > A new version of I-D, draft-zhang-trill-mtu-negotiation-02.txt has been
  > successfully submitted by Mingui Zhang and posted to the IETF
repository.
  >
  > Filename:   draft-zhang-trill-mtu-negotiation
  > Revision:   02
  > Title:              TRILL IS-IS MTU Negotiation
  > Creation date:      2011-12-13
  > WG ID:              Individual Submission
  > Number of pages: 11
  >
  > Abstract:
  >    The IETF TRILL protocol provides least cost pair-wise layer 2 data
  >    forwarding by using IS-IS link state routing. This document defines a
  >    new link MTU size negotiation mechanism to update the TRILL documents
  >    "Routing Bridges (RBridges): Base Protocol Specification" and
  >    "Routing Bridges (RBridges): Adjacency".
  >
  >
  >
  >
  > The IETF Secretariat

Thanks,
Mingui

------------------------------

Message: 3
Date: Tue, 13 Dec 2011 15:12:40 +0530
From: rakesh kumar <[email-masked]>
Subject: [rbridge] Queries on RFC 6325 trunk bit
To: [email-masked]
Message-ID:
       <CAM-s48D-r_juN+Wa7a2OJQHk=[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

Hi Authors,
>From RFC6325,Section 4.9.1
End station service disable (trunk port) bit. When this bit is
set, all native frames received on the port and all native frames
that would have been sent on the port are discarded. (See Appendix
B.) (Note that, for this document, "native frames" does not
include layer 2 control frames.) *By default, ports are not
restricted to being trunk ports.*

>From RFC6325,Section 5.3
Four per-port configuration bits: disable port (default 0 ==
enabled), *disable end station service (trunk, default 0 ==
enabled)*, access port (default 0 == not restricted to being an
access port), and use P2P Hellos (default 0 == use TRILL
Hellos). (See Section 4.9.1.)

i think,above highlighted things are conflicting with each other in the
latter section
5.3 for disable end station service description should have been "default
0== not
restricted to being an trunk" otherwise it will give wrong impression of
trunk bit 0
will enable trunk mode by default.

Regards,
Rakesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.postel.org/pipermail/rbridge/attachments/20111213/16f70023/attachment-0001.html

------------------------------

Message: 4
Date: Tue, 13 Dec 2011 09:28:16 -0500
From: Donald Eastlake <[email-masked]>
Subject: Re: [rbridge] Queries on RFC 6325 - Default port type
To: Abhinav Bhatia <[email-masked]>
Cc: [email-masked]
Message-ID:
       <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

Hi Abhinav,

On Tue, Dec 13, 2011 at 3:00 AM, Abhinav Bhatia
<[email-masked]> wrote:
> Hi ,
>
> I looked at some of the posts and RFC, there is confusion on the
> default settings to the trill port.

I don't think I'm not confused.

> According to RFC it seems the default settings is both access and
> trunk bits are 0. In this mode port will do both
> encapsulation/decapsulation and forward the trill data packet.

That's right. By default RBridge ports are universal ports. This is
motivated by the TRILL goal of supporting zero/minimal configuration.

> If yes the what should be the behaviour when both the bits are set.

I don't see why you have a question on this. The dominant, longest,
and most complete section of RFC 6325 on these port bits is clearly
Section 4.9.1. There, the bits are called the "TRILL traffic disable
(access port) bit" and the "End-station service disable (trunk port)
bit". While it seems a bit silly to turn on both of these bits instead
of just turning on the "Disable port bit", I don't see any conflict
between these two bits. The access port bit is defined in terms of its
effect on the transmission and receipt of TRILL IS-IS frames and the
trunk port bit is defined in terms of its effect on the transmission
and receipt of native frames. These are disjoint classes of frames.

> From rbridge Digest, Vol 91, Issue 4
>
> "If the DRB port on the link is not an access port but some other
>> RBridge's port is an access port, the link is misconfigured. It would
>> probably work fine to appoint an RBridge with an access port on such a
>> misconfigured link as an Appointed Forwarder. But, since that RBridge
>> disagrees with the DRB about the type of service being provided on the
>> link and the DRB is, generally, in charge, I think the idea was to
>> isolate the inconsistent non-DRB RBridge as much as possible."
>
> Does above bold statement means only trunk port or does it include both
> "trunk and access bit set 0"?

Sorry, perhaps my wording was not as pedantic as it should have been.
"not an access port" means "has the TRILL traffic disable (access) bit
set to zero" and "is an access port" means " has the TRILL traffic
disable (access) bit set to one". Neither assertion has anything to do
with the value of the trunk bit.

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

> Regards,
> Abhinav

------------------------------

Message: 5
Date: Tue, 13 Dec 2011 10:14:30 -0500
From: Donald Eastlake <[email-masked]>
Subject: Re: [rbridge] Queries on RFC 6325 trunk bit
To: rakesh kumar <[email-masked]>
Cc: [email-masked]
Message-ID:
       <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

Hi Rakesh,

On Tue, Dec 13, 2011 at 4:42 AM, rakesh kumar <[email-masked]> wrote:
> Hi Authors,

> From RFC6325,Section 4.9.1
> End station service disable (trunk port) bit. When this bit is
> set, all native frames received on the port and all native frames
> that would have been sent on the port are discarded. (See Appendix
> B.) (Note that, for this document, "native frames" does not
> include layer 2 control frames.) By default, ports are not
> restricted to being trunk ports.
>
> From RFC6325,Section 5.3
> Four per-port configuration bits: disable port (default 0 ==
> enabled), disable end station service (trunk, default 0 ==
> enabled), access port (default 0 == not restricted to being an
> access port), and use P2P Hellos (default 0 == use TRILL
> Hellos). (See Section 4.9.1.)
>
> i think,above highlighted things are conflicting with each other in the
> latter section
> 5.3 for disable end station service description should have been "default
> 0== not
> restricted to being an trunk" otherwise it will give wrong impression of
> trunk bit 0
> will enable trunk mode by default.

While it might have been nicer if the two sections had used parallel
wording, I do not see any conflict. The wording change you suggest
would have been a good editorial improvement. Too bad it wasn't
suggested before the RFC actually issued.

The "disable end station service (trunk, default 0 == > enabled)"
wording in Section 5.3 means that by default end station service is
enabled. That is the simplest reading and is consistent with the rest
of the RFC including Section 4.9.1 which is the longest, most
detailed, and dominant discussion of these bits. Apparently you are
worried that it will be read in 5.3 as meaning "enable disable end
station service", a more complex and odd sounding reading that is
inconsistent with the rest of the RFC.

How about if I add something to
draft-eastlake-trill-rbridge-clear-correct to update and expand
section 1.2 of RFC 6325 to say the the precedence ordering between the
sections of the RFC to resolve any apparent conflicts is

   4 > 3 > 7 > 5 > 2 > 6 > 1

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

> Regards,
> Rakesh

------------------------------

Message: 6
Date: Tue, 13 Dec 2011 09:36:04 -0800
From: Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Queries on RFC 6325 - Default port type
To: Donald Eastlake <[email-masked]>
Cc: [email-masked], Abhinav Bhatia <[email-masked]>
Message-ID:
       <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

A shorter answer is that if both bits are on, the port is disabled.

Radia

On Tue, Dec 13, 2011 at 6:28 AM, Donald Eastlake <[email-masked]> wrote:

> Hi Abhinav,
>
> On Tue, Dec 13, 2011 at 3:00 AM, Abhinav Bhatia
> <[email-masked]> wrote:
> > Hi ,
> >
> > I looked at some of the posts and RFC, there is confusion on the
> > default settings to the trill port.
>
> I don't think I'm not confused.
>
> > According to RFC it seems the default settings is both access and
> > trunk bits are 0. In this mode port will do both
> > encapsulation/decapsulation and forward the trill data packet.
>
> That's right. By default RBridge ports are universal ports. This is
> motivated by the TRILL goal of supporting zero/minimal configuration.
>
> > If yes the what should be the behaviour when both the bits are set.
>
> I don't see why you have a question on this. The dominant, longest,
> and most complete section of RFC 6325 on these port bits is clearly
> Section 4.9.1. There, the bits are called the "TRILL traffic disable
> (access port) bit" and the "End-station service disable (trunk port)
> bit". While it seems a bit silly to turn on both of these bits instead
> of just turning on the "Disable port bit", I don't see any conflict
> between these two bits. The access port bit is defined in terms of its
> effect on the transmission and receipt of TRILL IS-IS frames and the
> trunk port bit is defined in terms of its effect on the transmission
> and receipt of native frames. These are disjoint classes of frames.
>
> > From rbridge Digest, Vol 91, Issue 4
> >
> > "If the DRB port on the link is not an access port but some other
> >> RBridge's port is an access port, the link is misconfigured. It would
> >> probably work fine to appoint an RBridge with an access port on such a
> >> misconfigured link as an Appointed Forwarder. But, since that RBridge
> >> disagrees with the DRB about the type of service being provided on the
> >> link and the DRB is, generally, in charge, I think the idea was to
> >> isolate the inconsistent non-DRB RBridge as much as possible."
> >
> > Does above bold statement means only trunk port or does it include both
> > "trunk and access bit set 0"?
>
> Sorry, perhaps my wording was not as pedantic as it should have been.
> "not an access port" means "has the TRILL traffic disable (access) bit
> set to zero" and "is an access port" means " has the TRILL traffic
> disable (access) bit set to one". Neither assertion has anything to do
> with the value of the trunk bit.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [email-masked]
>
> > Regards,
> > Abhinav
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.postel.org/pipermail/rbridge/attachments/20111213/3094bebc/attachment.html

------------------------------

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

End of rbridge Digest, Vol 91, Issue 12
***************************************
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 14 Dec 2011 14:35:28 -0500

Hi Rakesh,

> Disable > P2P > Access > Trunk"

Well, it many not be clear enough but I know what I was thinking when
I wrote those words.

Note that the dominance relationship only has effect to resolve
"inconsistencies in behavior". I just don't see any inconsistency
between "end station service disable" and "TRILL traffic disable". I
believe that the current specification is as spelled out in the
attached chart and would be happy to make this chart part of the
clarifications and corrections draft. A total ordering of the TRILL
port mode bits was specified just to be sure there wouldn't be any
ambiguities should some conflict arise, even though I didn't think
there was any conflict between the access and trunk bits. It is
interesting that providing this total ordering seems to have had the
opposite effect.

Thanks,
Donald