Subject: Num of Nbrs and MTU size in hello pkts : OSPFv2

From: Erblichs <[email-masked]>
Date: Wed, 12 Feb 2003 09:32:38 -0800

Group,

        I guess you could say that I have a dumb question.

        If a DR wanted to support say 400+ adjs with a standard
        Ethernet 1.5 MTU, is it acceptable to send out more
        than 1 hello describing all of its nbrs?

        Note: each nbr id would consume 4 bytes and thus
        the length of the 1 pkt would be greater than MTU size.

        I am assuming that 2 pkts per hello interval would
        be transmitted.

        It is that I just don't remember any RFC describing
        this condition.

        Pointers please...

        Thanks,

        Mitchell Erblich
        Sr. Software Engineer
`       ======================

---

From: alok <[email-masked]>
Date: Wed, 12 Feb 2003 23:35:46 +0530

ideally, you would have to build flow control on top of OSPF?

---

From: Acee Lindem <[email-masked]>
Date: Wed, 12 Feb 2003 10:05:44 -0800

>         I am assuming that 2 pkts per hello interval would

Erblichs,

This won't work. Based the neighbor FSM, the neighbors will all go to
One-Way state when they receive the hello packet not including them in
the hello packet. Better to let the IP stacks fragment and
reassemble.

--
Acee

---

From: Shankar Agarwal <[email-masked]>
Date: Wed, 12 Feb 2003 10:11:34 -0800

I am not sure how the different implementations will behave in this
case. But as far as RFC is concerned. It says in section 4.3 that each
protocol packet can be broken into small protocol packet. But i am not
sure in case of Hello. But then we can use Ip Fragmentation for Hello
Packet and no one stops us from sending an IP packet greater than then
MTU.

---

From: SOMEN BHATTACHARYA <[email-masked]>
Date: Wed, 12 Feb 2003 12:47:02 -0800

> the hello packet. Better to let the IP stacks

Does the OSPF Hello packet header include any
Multi-Packet indicator (similar to More Flag) ?

If so then Neighbor FSM can wait till the last
Hello packet (in a multi-packet hello) arrives
and then set Neighbor to 1-Way if the receving router
itself is not included in any of the fragment hellos.

This could be an alternate to the IP fragmentation
to transport large OSPF hello packets.

> >         It is that I just don't remember any RFC

=====
Somen Bhattacharya
E-Mail : [email-masked]

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

---

From: Acee Lindem <[email-masked]>
Date: Wed, 12 Feb 2003 13:39:25 -0800

> Multi-Packet indicator (similar to More Flag) ?

Nope - and it really doesn't make sense to talk about
modifications to the protocol when IP fragmentation/reassembly
solves the problem.

--
Acee

---

From: SOMEN BHATTACHARYA <[email-masked]>
Date: Wed, 12 Feb 2003 17:23:38 -0800

--- Acee Lindem <[email-masked]> wrote:
> > > >         I guess you could say that I have a
> dumb
> > > question.
> > > >
> > > >         If a DR wanted to support say 400+
> adjs
> > > with a standard
> > > >         Ethernet 1.5 MTU, is it acceptable to
> send
> > > out more
> > > >         Note: each nbr id would consume 4
> bytes
> > > and thus
> > > >         the length of the 1 pkt would be
> greater
> > > than MTU size.
> > > >
> > > One-Way state when they receive the hello packet
> not
> > > including them in

Does OSPF guarantee that "Don't Fragment" bit will
never be set in the IP header ?

If not, then large OSPF Hello packet may get dropped
by IP forwarder while attempting to send to the
neighbor, if IP fragmentation is not permitted for
the link.

> > > >         It is that I just don't remember any
> RFC
> > > describing
> > > >         this condition.
> > > >
> > > >         Pointers please...
> > > >
> > > >         Thanks,
> > > >
> > > >         Mitchell Erblich
> > > >         Sr. Software Engineer
> > > > `       ======================
> > >
> > > --
> > > Acee
> >
> > =====
> > Somen Bhattacharya

=====
Somen Bhattacharya

---

From: Acee Lindem <[email-masked]>
Date: Wed, 12 Feb 2003 17:48:37 -0800

> never be set in the IP header ?

Why would an OSPF implementation ever set the DF bit?

--
Acee

---

From: Erblichs <[email-masked]>
Date: Wed, 12 Feb 2003 17:31:43 -0800

Group,

        Thanks, I was/am concerned about the Don't
        Fragment bit being set in the IP header.

        Has anyone run into this large neighbor
        problem and having packets dropped OR
        just having packets dropped because of
        this Don't Fragment bit?

        This almost seems like a option bit to
        me. Don't go 1-way if you see a hello
        packet that doesn't have yourself specified
        once you were 2-way UNTIL dead-router
        interval has occurred...

        Oops, this seems like a mod of
        the nbr state machine..

        Maybe something simpler like a msg
        generation if a hello is createed beyond
        a MTU????

        Mitchell Erblich
        ============================

---

From: alok <[email-masked]>
Date: Thu, 13 Feb 2003 11:00:20 +0530

hi,

incase of a "hello" per se, i dont see how one evens run into MTU
issues..the hello packet is not that big (only router specific info)

i think may come about in DD and LSUpdates etc...which pass the LSA info....

the issues may come like this:

if i have a MPLS- PPVPN from A to B

the "label stacking" causes the frame size to grow
so we reach an MTU of above 1500 (whatever the value)
now if the routing nodes in the core (the LSRs) dont accomodate this ...the
edge has no way of knowing that the core has a drop in MTU....right?
and Labels in MPLS dont have DF bits :o) so you "cant fragment" there on the
"core".....

now what?

you have to make sure the MTU accomodates these "labelstacks" in the core
...but even now fragmentation using DF bits in IP header is ruled out
..right?

-rgds
Alok

---

From: Somen Bhattacharya <[email-masked]>
Date: Wed, 12 Feb 2003 23:47:17 -0800

> edge has no way of knowing that the core has a drop

Before MPLS LSP can be used to transport OSPF
messages,
LSP setup over hop-by-hop routed path is dependent on
OSPF to discover adjacencies and hence on successful
OSPF hello exchanges.

Even if there were fewer adjacencies initially and
hello packet exchange was successful and LSP setup
was done, transporting a large OSPF packet over LSP
will not require fragmentation of the labeled packet
at the directly attached core LSR, as the Ingress-LSR
would have done an one time fragmentation based on
MTU limit known via "Path MTU Discovery" or via
configured Maximum Initially Labeled IP Datagram size.

In the case of OSPF, routing messages travel only
one hop and hence do not have the concern of
fragmentation by core routers except at the sender.

In general if a core LSR drops a labeled packet
because it exceeds the link layer frame payload
size, and the labeled IP packet has 'Dont Fragment'
bit set in the IP header, an ICMP Destination
Unreachable message (Fragmentation Required and DF
set)
will be sent to the Edge and so Edge router will
know the reason for packet drop.

> ...but even now fragmentation using DF bits in IP

If fragmentation of a labeled packet is needed at
core LSR, then fragmentation is done at the unlabeled
IP datagram after removing the label stack and then
prepending back the same label stack onto the
fragmented IP datagrams.

> dumb question.
> adjs with a standard
> send out more
> bytes and thus
> greater than MTU size.
> RFC describing

=====
Somen Bhattacharya

---

From: alok <[email-masked]>
Date: Thu, 13 Feb 2003 13:29:42 +0530

inline....

----- Original Message -----
From: Somen Bhattacharya <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 13, 2003 1:17 PM
Subject: Re: Num of Nbrs and MTU size in hello pkts : OSPFv2

> OSPF to discover adjacencies and hence on successful

errr no
im talking about a topology where i provision a PPVPN to the customer and he
runs OSPF over it...across the MPLS infrastrctr in the middle
in MPLS LSPs where OSPF is used as the IGP, this wont ever crop up, coz the
adjacencies are not "over the LSP"  :o)....well FA and all that are there if
one reads the GMPLS routing draft but i dont know if they are looking at
OSPF as signalling there...........

> configured Maximum Initially Labeled IP Datagram size.

how??? as i said im looking at a PPVPN between A and B, and somewhere in the
middle the MTU drops and the LSR is not even aware of whats inside...(the ip
part encaped inthe label stack)

> prepending back the same label stack onto the

i am not too sure if i have seen this in *any draft*
...that we shall look into actual payload and decide and put fragments
etc...it might work for L3VPN though coz we know payload is IP

you might argue.. :o) if i knew it was IP, i might look at L3VPN, right...

but if it was a PPVPN (which doesnt assume that its carrying IP) how would
the LSR behave?

---

From: Erblichs <[email-masked]>
Date: Tue, 25 Feb 2003 03:11:46 -0800

Update,

        Clarification...

        Due to belief that the Don't Fragment IP option is set in
        an environment, has anyone one done a multiple router-id
        support within a single router within the OSPF environment?

        This type of mod was done in the ISIS where the ID was a
        limitation..

        This should / could support a subset of router-ids per
        hello, where each hello pkt xmit'ed from a single interface.
        Thus, the combination of 2 hellos will cover the sum of
        adj's if said router were to to become both a DR and the
        BDR.

        If three of more separate hellos would be needed, then the
        virtual router ids should specify a priority that results
        in non DR / BDR election..

        If we were to become a DRother, we should prevent
        a DR and a BDR from forming adj with multiple virtual
        router ids.

        Comments... (and I am ducking :)  )...

        Mitchell Erblich
        ====================