Re: [manet-dlep-rg] Peer termination

I agree Stan: what you have described is the most rational handling of the situation, but I was wondering out loud if it was felt that specific text detailing that is required...

Rick Taylor

> -----Original Message-----
> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
> Sent: 12 November 2013 15:41
> To: Taylor, Rick
> Cc: DLEP Research Group (manet-dlep-rg@ietf.org)
> Subject: Re: [manet-dlep-rg] Peer termination
>
>
> On Nov 12, 2013, at 7:57 AM, "Taylor, Rick" <Rick.Taylor@cassidian.com>
> wrote:
>
> > +1
> >
> > Keep the Peer Terminate message.  Include a status value to
> differentiate between a normal and abnormal termination.
> >
> > Status 0 = Ok - Normal shutdown, e.g. user turned off device
> > 1 = Missing heartbeats
> > 2 = Incompatible configuration
> >
> > I'm guessing at status codes here, but it's an idea.
> >
> > Obviously a terminate can come from either modem or router, and MUST be
> the last message.
> >
> > I am not sure it is clear that the termination of a DLEP session implies
> that all destinations are no longer reachable.  No more DLEP metrics about
> those destinations, sure, but unreachable?
>
> At least in the current Cisco implementation, Peer Termination means that
> all information learned from the Peer is no longer valid. So the router
> removes information about all destinations learned via the modem. To do
> otherwise would put you a weird state if/when the radio comes back online.
> You'd have an "information base" for an instantiation of DLEP in the peer
> that wasn't built by said instantiation...
>
> Also, in the Cisco implementation, removing the known destinations for a
> modem fires an indicator to routing protocols to drive "Dead Timer" for
> those destinations. So, the routing protocols will remove any existing
> adjacency, and re-converge. So yes, the current implementation pretty much
> equates DLEP termination to "destination unreachable".
>
> Regards,
> Stan
>
>
> >
> > Rick Taylor
> >
> >> -----Original Message-----
> >> From: manet-dlep-rg-bounces@ietf.org [mailto:manet-dlep-rg-
> >> bounces@ietf.org] On Behalf Of Teco Boot
> >> Sent: 11 November 2013 18:14
> >> To: Stan Ratliff
> >> Cc: DLEP Research Group (manet-dlep-rg@ietf.org)
> >> Subject: Re: [manet-dlep-rg] Peer termination
> >>
> >>
> >> Op 11 nov. 2013, om 18:34 heeft Stan Ratliff (sratliff)
> >> <sratliff@cisco.com> het volgende geschreven:
> >>
> >>>
> >>> On Nov 11, 2013, at 11:19 AM, Teco Boot <teco@inf-net.nl>
> >>> wrote:
> >>>
> >>>>
> >>>> Op 11 nov. 2013, om 01:55 heeft Stan Ratliff (sratliff)
> >> <sratliff@cisco.com> het volgende geschreven:
> >>>>
> >>>>> Oh, and on termination:  I'm not removing the "Peer Terminate". Yes,
> a
> >> session can be brought down via TCP FIN. But, you can also announce it
> >> with a Peer Terminate. Gives a more orderly way to clean everything up,
> >> IMO.
> >>>>
> >>>> It doesn't add anything, other than more messages, more state, more
> >> code and more bugs.
> >>>> What am I missing?
> >>>
> >>> The ability for one side of the DLEP connection to tell the other
> *why*
> >> things are going down.
> >>
> >> I think a "Peer Down" message makes sense. This is very different than
> >> terminating a DLEP session, in that the latter would not indicate peers
> >> are no longer accessible. A "Peer Down" has an implicit meaning that
> all
> >> Destinations are down. Closure of DLEP TCP connection would not
> indicate
> >> such.
> >>
> >> Maybe use a generic Peer Error message, as notification. Could be send
> >> before TCP connection teardown.
> >>
> >> Teco
> >>
> >>
> >> _______________________________________________
> >> manet-dlep-rg mailing list
> >> manet-dlep-rg@ietf.org
> >> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
> > The information contained within this e-mail and any files attached to
> this e-mail is private and in addition may include commercially sensitive
> information. The contents of this e-mail are for the intended recipient
> only and therefore if you wish to disclose the information contained
> within this e-mail or attached files, please contact the sender prior to
> any such disclosure. If you are not the intended recipient, any
> disclosure, copying or distribution is prohibited. Please also contact the
> sender and inform them of the error and delete the e-mail, including any
> attached files from your system. Cassidian Limited, Registered Office :
> Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No:
> 04191036 http://www.cassidian.com

The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com