Subject: [rbridge] Query on Campus wide MTU

From: somnath chatterjee <[email-masked]>
Date: Tue, 13 Dec 2011 10:15:20 +0530

Hi Authors,

>From draft-zhang-trill-mtu-negotiation-01 it is recommended that
RBridges send the campus wide MTU (Sz) in LSP0 or else the campus MTU
will be deemed to be 1470 which will be subjected to re-size when new
campus MTU value is received. Say we have different MTU sizes on ports
of RBridge. This may trigger a number of re-size through out the
campus based on timings of links coming to report state(and their MTU
values). Why do not we wait for all links on the RBridge to complete
the Neighbor state machine or stabilize before we send the assumed
Campus wide MTU to others in LSP. ie Could we not send campus wide MTU
in LSP only when all TRILL enabled ports in the RBridge are in
following state
1> Report State(MTU Testing is done)
2> Suspended State(MAC collision happened)
3> Two way state and MTU test has failed.
4> Detect State by receiving a TRILL Hello on the Designated VLAN with
one or more TRILL Neighbor TLVs covering an address range that
includes the receiver's (SNPA) address  -- and none of which lists the
receiver.

This will reduce the number of resizing of campus wide MTU to be
dependent on number of RBridges in the Campus rather than number of
links on that campus.

Thank you,
Regards,
Somnath
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 13 Dec 2011 07:19:17 +0000

Hi Somnath,

Thanks for your comments! I will soon upload a new version of this draft.

   > campus MTU value is received.

This issue is also covered in Section 4.5 of draft-eastlake-isis-rfc6326bis-01. Item 3) of the "Re-determining" Section may be removed or merged to the "bis" draft since the 02 version. 

   >This may trigger a number of re-size through out the
   > values).

I agree. But we cannot wait for all adjacencies of an RBridge to stabilize before we start to do LSP database synchronization. As pointed out in draft-eastlake-trill-rbridge-clear-correct-01, LSP database synchronization should start as early as two RBridges establish the 2-way connectivity. As I know, the LSPs transmitted in this synchronization process also contains the Sz value. 

If we wait for all the adjacencies of an RBridge to move to a stable state, then the connectivity of the campus may be undermined. Take the following figure as an example, if the adjacencies in the south-north direction do not stabilize, the east-west connectivity cannot be established either. 

    RB4
     |
RB1-RB2-RB3
     |
    RB5

In a well-configured campus all RBridges should be configured with the same originatingLSPBufferSize. It is not a big problem that the number of resizing of campus wide MTU is dependent on the number of links in the campus.

Thanks,
Mingui

   > -----Original Message-----
   > From: [email-masked] [mailto:[email-masked]] On
   > Behalf Of somnath chatterjee
   > Sent: Tuesday, December 13, 2011 12:45 PM
   > To: [email-masked]
   > Subject: [rbridge] Query on Campus wide MTU
   > 
   > Hi Authors,
   >

---

From: Radia Perlman <[email-masked]>
Date: Mon, 12 Dec 2011 23:23:06 -0800

"Sz" is a configured value on the RB which indicates the size of packet
that every link in the topology must be able to support.  Since LSP chunks
can't be resized once the source generates them, the campus-wide Sz is
needed so that an RB can know that its LSP fragments will be able to travel
across all the links.

So RB1 will not change its value of Sz based on the size of packets that
can be received on each of its ports.

Radia

---

From: Radia Perlman <[email-masked]>
Date: Tue, 13 Dec 2011 22:20:19 -0800

Actually I have the names of things wrong...problem with trying to reply
when I don't have time to properly read the spec, and am relying basically
on 30 year old memory of IS-IS in some cases.

So, I believe "originatingLSPBufferSize" is the configured value in each
RBridge R1 which is the size that R1 can handle (and must be at least
1470), and is reported in LSPs.  "Sz" is the minimum of all the reported
"originatingLSPBufferSize" reported in all the LSPs (but not allowed to be
less than 1470)

The only reason for having "originatingLSPBufferSize" configured and
reported, rather than simply fixing it at the constant 1470,  is so that in
a network where all the RBs support much larger than 1470 on all their
links, to also allow LSP fragments to be larger than 1470.

But I still believe (and am still relying on memory, so feel free to
correct me if I'm wrong), that "originatingLSPBufferSize" is a configured
value at R1, and is not affected by the capability of R1's links, so R1 can
immediately report its configured value in its LSP without waiting for its
links to come up.

Radia

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 14 Dec 2011 07:38:54 +0000

Thanks for the clarification!

Please allow me to say what I understand.

originatingLSPBufferSize (or Sz) is a per-node value. It is also the value configured and propagated around the campus. Port MTU size is a per port value which will not be propagated. It is the capability that how big a packet this port can process. I think Figure 2.1 of the draft can help us to understand their difference.

Since Sz is carried in LSPs and LSPs are transmitted when an adjacency moves to a certain state (e.g., 2-way or Report), the number of links in the campus may have some impact on the propagation of Sz. 

Thanks,
Mingui

   > Behalf Of Radia Perlman
   > Sent: Wednesday, December 14, 2011 2:20 PM
   > To: somnath chatterjee
   > Cc: [email-masked]
   > Subject: Re: [rbridge] Query on Campus wide MTU
   > 
   > Actually I have the names of things wrong...problem with trying to reply when
   > I don't have time to properly read the spec, and am relying basically on 30 year
   > old memory of IS-IS in some cases.
   > 
   > So, I believe "originatingLSPBufferSize" is the configured value in each RBridge
   > R1 which is the size that R1 can handle (and must be at least 1470), and is
   > reported in LSPs.  "Sz" is the minimum of all the reported
   > "originatingLSPBufferSize" reported in all the LSPs (but not allowed to be less
   > than 1470)
   > 
   > reported, rather than simply fixing it at the constant 1470,  is so that in a
   > network where all the RBs support much larger than 1470 on all their links, to
   > also allow LSP fragments to be larger than 1470.
   > 
   > But I still believe (and am still relying on memory, so feel free to correct me if
   > I'm wrong), that "originatingLSPBufferSize" is a configured value at R1, and is
   > not affected by the capability of R1's links, so R1 can immediately report its
   > configured value in its LSP without waiting for its links to come up.
   > 
   > Radia
   > 
   > 
   > 
   > 
   > 
   > 
   > 	On Mon, Dec 12, 2011 at 8:45 PM, somnath chatterjee
   > <[email-masked]> wrote:
   > 
   > 
   > 		Hi Authors,
   >

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 14 Dec 2011 16:26:41 -0500

Hi Mingui,

> originatingLSPBufferSize (or Sz) is a per-node value. It is also the value configured and propagated around the campus. Port MTU size is a per port value which will not be propagated. It is the cap…

originatingLSPBufferSize is indeed the per node value. It would
default to minimum ( the MTUs of the ports that might be used to
send/receive LSPs, the largest LSP the RBridge's IS-IS implementation
can handle ) but not less than 1470. However, to avoid surprises as
are described in your draft, a network operator would often want to
configure originatingLSPBufferSize to a smaller value (but not less
than 1470) so that it is consistent across the campus.

(In the IS-IS standard, there are two originatingLSPBufferSize values,
one in Level 1 LSPs and one in Level 2 LSPs, but in the current TRILL
standard you only have Level 1.)

> Since Sz is carried in LSPs and LSPs are transmitted when an adjacency moves to a certain state (e.g., 2-way or Report), the number of links in the campus may have some impact on the propagation of…

Actually, Sz is just calculated by each RBridge independently. The
value of Sz is not particularly depending on the number of links in
the campus. I suppose how richly or sparsely connected the campus is
has some effect on the propagation of LSPs and thus on the propagation
of originatingLSPBufferSize.

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

> Thanks,
> Mingui
>
>
>   > -----Original Message-----
>   > From: [email-masked] [mailto:[email-masked]] On
>   > Behalf Of Radia Perlman
>   > Sent: Wednesday, December 14, 2011 2:20 PM
>   > To: somnath chatterjee
>   > Cc: [email-masked]
>   > Subject: Re: [rbridge] Query on Campus wide MTU
>   >
>   > Actually I have the names of things wrong...problem with trying to reply when
>   > I don't have time to properly read the spec, and am relying basically on 30 year
>   > old memory of IS-IS in some cases.
>   >
>   > So, I believe "originatingLSPBufferSize" is the configured value in each RBridge
>   > R1 which is the size that R1 can handle (and must be at least 1470), and is
>   > reported in LSPs.  "Sz" is the minimum of all the reported
>   > "originatingLSPBufferSize" reported in all the LSPs (but not allowed to be less
>   > than 1470)
>   >
>   > The only reason for having "originatingLSPBufferSize" configured and
>   > reported, rather than simply fixing it at the constant 1470,  is so that in a
>   > network where all the RBs support much larger than 1470 on all their links, to
>   > also allow LSP fragments to be larger than 1470.
>   >
>   > But I still believe (and am still relying on memory, so feel free to correct me if
>   > I'm wrong), that "originatingLSPBufferSize" is a configured value at R1, and is
>   > not affected by the capability of R1's links, so R1 can immediately report its
>   > configured value in its LSP without waiting for its links to come up.
>   >
>   > Radia
>   >
>   >
>   >
>   >
>   >
>   >
>   > On Mon, Dec 12, 2011 at 11:23 PM, Radia Perlman <[email-masked]>
>   > wrote:
>   >
>   >
>   >    "Sz" is a configured value on the RB which indicates the size of packet
>   > that every link in the topology must be able to support.  Since LSP chunks
>   > can't be resized once the source generates them, the campus-wide Sz is
>   > needed so that an RB can know that its LSP fragments will be able to travel
>   > across all the links.
>   >
>   >    So RB1 will not change its value of Sz based on the size of packets that
>   > can be received on each of its ports.
>   >
>   >
>   >    Radia
>   >
>   >
>   >    On Mon, Dec 12, 2011 at 8:45 PM, somnath chatterjee
>   > <[email-masked]> wrote:
>   >
>   >
>   >            Hi Authors,
>   >
>   >            >From draft-zhang-trill-mtu-negotiation-01 it is recommended that
>   >            RBridges send the campus wide MTU (Sz) in LSP0 or else the
>   > campus MTU
>   >            will be deemed to be 1470 which will be subjected to re-size when
>   > new
>   >            campus MTU value is received. Say we have different MTU sizes on
>   > ports
>   >            of RBridge. This may trigger a number of re-size through out the
>   >            campus based on timings of links coming to report state(and their
>   > MTU
>   >            values). Why do not we wait for all links on the RBridge to complete
>   >            the Neighbor state machine or stabilize before we send the
>   > assumed
>   >            Campus wide MTU to others in LSP. ie Could we not send campus
>   > wide MTU
>   >            in LSP only when all TRILL enabled ports in the RBridge are in
>   >            following state
>   >            1> Report State(MTU Testing is done)
>   >            2> Suspended State(MAC collision happened)
>   >            3> Two way state and MTU test has failed.
>   >            4> Detect State by receiving a TRILL Hello on the Designated VLAN
>   > with
>   >            one or more TRILL Neighbor TLVs covering an address range that
>   >            includes the receiver's (SNPA) address  -- and none of which lists
>   > the
>   >            receiver.
>   >
>   >            This will reduce the number of resizing of campus wide MTU to be
>   >            dependent on number of RBridges in the Campus rather than
>   > number of
>   >            links on that campus.
>   >
>   >            Thank you,
>   >            Regards,
>   >            Somnath
>   >            _______________________________________________
>   >            rbridge mailing list
>   >            [email-masked]
>   >            http://mailman.postel.org/mailman/listinfo/rbridge
>   >
>   >
>   >
>