The MPLS WG Archive

[Alex Zinin <azinin@cisco.com>]

Peter,

You have several places in the document that explicitly speak
about LSDB modification. Some examples below.
I think this should be changed to something more neutral.

>    constructed. Eventually this message arrives back at the source
>    node, where the vector is taken and inserted into the topology
>    database. This node has just learned from its mistake and is now

>    When the LDP session that originated a CR-LDP label request receives
>    a notification that contains feedback TLV's it is recommended that
>    these bandwidth values overwrite the corresponding values in the
>    nodes topology database. Doing so permits this node to immediately

Thanks,

-- 
Alex Zinin


Monday, July 10, 2000, 7:15 AM, Peter Ashwood-Smith <petera@nortelnetworks.com> wrote:

>    Alex,

>    Thanks for the comments. The thing to keep in mind here is that how an
> implementation chooses to store the feedback information is not really part
> of the draft, and does not need to be standardized. The important point is
> that you receive feedback and you use that feedback information in
> subsequent computations until you get another LSA. There are a variety of
> different ways to accomplish this but probably the easiest is to store
> feedback information separately from flooded information. In any case, fed
> back information is never re-flooded, only the originator can flood its
> bandwidth information.

>     If however you would prefer that I add a sentence or two  to make this
> more clear I will be happy to do so if you want to send me something.

>     Cheers,

>     Peter

>         -----Original Message-----
>         From:   Alex Zinin [SMTP:azinin@cisco.com]
>         Sent:   Monday, July 10, 2000 1:59 AM
>         To:     mpls
>         Subject:        draft-ietf-mpls-te-feed-00.txt


>           Peter, et al.

>           In your draft you recommend to change the contents
>           of IGP's LSDB whenever the feedback from the signaling
>           component is received. I'm afraid it is not quite good.

>           1. If the checksum of the LSA/LSP is not recalculated
>              after the contents were changed, the IGP may report
>              a fatal error if the checksum is verified before
>              the next version of the LSA/LSP arrives.

>           2. Recalculating the checksum is also wrong, because:

>               a) only the originating router must do this

>               b) if this is done by other routers it may affect
>                  LSA/LSP version comparison algo.

>           Because of the above and because it is a 'bad thing' to
>           modify link-state PDUs originated by others, I think it
>           is safer and makes some more sense to say that implementations
>           must account for a method to link the information provided
>           by the signaling component to the corresponding elements
>           of the TE database, instead of overwriting it.

>           Cheers,
          
>         -- 
>         Alex Zinin