Re: B: Re: I-D ACTION:draft-bhatia-manral-diff-isis-ospf-00.txt

[Manral Vishwas-G19459 <[e-mail]>]

Hi folks,

I have taken these comments on another list.

Thanks,
Vishwas

-----Original Message-----
From: Erblichs [mailto:[e-mail]]
Sent: Saturday, September 06, 2003 02:27
To: [e-mail]
Subject: Re: B: Re: I-D ACTION:draft-bhatia-manral-diff-isis-ospf-00.txt


Part B: really short

        A) Nits

        1 ) Terminology

                There is no DR specified. However, there is a BDR specified.

                BDR should be specified after Backup Designated Router.

        2) 5.2 ATM Encapsulation

                TCP ACK  ??won??t  : will not

        3) 8. Checks on Hellos ...

                remove "-" at the end of the first paragraph.


                [RFC1195] : should have a blank space after RFC and
                be specified in references

                RFC1195 : should have a blank space or a "-"

        4) Probably should have DRothers..


        B) Technical comments


        ADDDD:
        OSPFv2 and OSPFv3 only form adjacencies between DRothers with the
hellos
        from the DR and/or the BDR in BMA and NBMA network configurations.

        The E-bit and N-bit are found in the options field of the hello
        packet.


        Mitchell Erblich
        Sr Software Engineer
        ------------------------------






Erblichs wrote:
>
> This is going to be a multiple part comment,
>
>         A) nits
>
>         1) Abstract
>
>         [IS-IS]  -> Has no item specified in References
>
>         2) 1. Terminologies
>
>         End System - Host   --> End System (ES) - Host
>         Intermediate System - Router  ---> Intermediate System (IS) - Router
>
>         Need something to specify that IS-IS uses the L1 and L2 to specify
>         Level 1 and Level 2 respectively.
>
>         3) References
>
>         What are those strange characters? See [Martley], [Mesh], [OOB],
>                                                 [TUNNEL],
>
>         4) 8. Checks on ...
>
>         atleast --> at least
>
> -------
>
>         B) Technical comments
>
>         1) 6.1 DR election deterministic..
>
>         is sticky meaning --> is somewhat sticky because after the wait time
>         has expired and a router has been elected, it tends to stay in that
>         elected position. The reason that it is not fully stiicky is that
>         if a elected router is added to a interface because of area merging,
>         a DR will be selected from the two routers. This behaviour is specified
>         in the OSPF RFCs.
>
>         2) 7. Areas / Hierarchy
>
>         There is a mixture of Level and L usages... You should probably pick
>         one and stay with it.
>
>         IS-IS
>
>         - Routers are identified as L1, or L2, or L1/L2 routers.
>
>         OSPF
>
>         - Divides the routing domain into multiple area types.
>
>         - The backbone area, area 0.0.0.0 or 0, is used to send packets
>           from one non-backbone area to another non-backbone area.
>
>         3) MTU Limitations
>
>         OSPF
>
>                 Add
>
>         - When the MTU values differ between routers, IP protocol
>           allows the configuration to support non-fragmenting of packets that
> are
>           greater than MTU size and can result in the complete loss of packets.
>
>         - When a packet is sent that is greater than MTU size and congestion
>           occurs or is approaching (random early discard) within the internet,
>           some implementations will drop these larger packets first.
>
>         - When a packet is sent that is greater than MTU size, the loss of any
>           part of this fragment will cause the complete packet to be resent.
>
>         - Some vendors support disabling the MTU mismatch detection that
>           would allow the adjacency to attempt to form.
>
>         - Please note that MTU mismatch is one of a number of causes that
>           can cause an adjacency to be stuck in exstart. One example could
>           be duplicate router-ids.
>
>         Mitchell Erblich
>         Sr Software Engineer
>         ---------------------------
>
> [e-mail] wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >
> >         Title           : IS-IS and OSPF Difference Discussions
> >         Author(s)       : V. Manral, M. Bhatia
> >         Filename        : draft-bhatia-manral-diff-isis-ospf-00.txt
> >         Pages           : 42
> >         Date            : 2003-9-4
> >
> > The increasing popularity of IS-IS [IS-IS] and OSPF [OSPF] over
> > the years has drawn significant attention to the relative merits
> > and de-merits of one with respect to the other. This draft presents
> > an elaborate comparison between the two routing protocols to explain
> > how the features and functionalities of one differs from the other.
> > Wherever applicable the differences between OSPFv2 and OSPFv3[OSPFv3]
> > have also been pointed out.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-bhatia-manral-diff-isis-ospf-00.txt
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body of the message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> >         "get draft-bhatia-manral-diff-isis-ospf-00.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> >         [e-mail].
> > In the body type:
> >         "FILE /internet-drafts/draft-bhatia-manral-diff-isis-ospf-00.txt".
> >
> > NOTE:   The mail server at ietf.org can return the document in
> >         MIME-encoded form by using the "mpack" utility.  To use this
> >         feature, insert the command "ENCODING mime" before the "FILE"
> >         command.  To decode the response(s), you will need "munpack" or
> >         a MIME-compliant mail reader.  Different MIME-compliant mail readers
> >         exhibit different behavior, especially when dealing with
> >         "multipart" MIME messages (i.e. documents which have been split
> >         up into multiple messages), so check your local documentation on
> >         how to manipulate these messages.
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> >   ------------------------------------------------------------------------
> > Content-Type: text/plain
> > Content-ID:     <[e-mail]>