RE: [Tsvwg] SCTP multihoming issues draft

[Coene Lode <Lode.Coene@siemens.atea.be>]

Hello Randy,

> -----Original Message-----
> From: Randall Stewart [mailto:randall@stewart.chicago.il.us]
> Sent: maandag 11 februari 2002 14:54
> To: Arun Prasad
> Cc: Coene Lode; Transport Area wg (E-mail); 'multi6@ops.ietf.org'
> Subject: Re: [Tsvwg] SCTP multihoming issues draft
> 
> 
> Arun:
> 
> I don't think we need to have a host become
> routing aware as section 2.2 seems to imply to
> some degree. Some clever work with the routing
> system in the host can alleviate the problem that
> Lode is mentioning here I think..

Maybe the section is not clear enough. 
And a bit biased too. At least, I need to rephrase "downloading the routing
tables" sentences.  Stay tuned for the next iteration.

> 
> For example in our BSD work we have now the ability
> of the routing system to have multiple default routes
> and a method to lookup a route via an alternate interface.
> We probably need to expand this to actually look at the gateway
> and not the interface.. but for now we use interface :/
> 
> This allows the sctp stack to call 
> 
> rtalloc_alternate(dst,old_route);
> 
> which then trys to give a route out a different interface if
> necessary hunting up the routing tree.
> 
> With this change we then get:
> 
> A) The host only needs to know about the edge routes available
>    via its multiple default routes.
> 
> B) Full use of the multi-homing provided without injection
>    of static routes as the v4 side does now...
> 
> C) Host only knows about the default routes and possibly
>    some special routes applied by the local administrator...
> 
> R


yours sincerly,
Lode

> 
> Arun Prasad wrote:
> > 
> > hi Coene,
> >     Regarding the below section in the draft,
> >     2.2 SCTP multihoming and the size of routing tables
> >     what are we trying to achieve....   section 2.1 basically
> > explained the restrictions
> > of SCTP's multihoming feature due to existing IP 
> architecture....  The
> > problems
> > are well sorted out, and one solution I get from that is,   changing
> > the Source
> > Ip address for the packets send ( periodically, if the 
> acknowledgemnet
> > for it is
> > not reaching the endpoint,) from a multihomed endpoint....
> >     But regarding section 2.2,  SCTP could do nothing about it (
> > because its
> > basically IP's restriction or the restriction of the currect routing
> > architecture....)
> > SCTP defines some rules or features, using them properly is the
> > responsiblity of the
> > Application which uses it (it may the administrator of the system
> > also...) ..  This
> > each of them using it can implement their own ways to get 
> the maximum
> > from use
> > of multihoming feature of SCTP......
> >       Will it not make SCTP more heavy, if we try to load 
> it with more
> > and more
> > sub features like this... and it will make it more dependent on the
> > existing architecture
> > which will make the maintanance tough.....
> >     But definitely we should be spelling out the problems or
> > restrictions of the
> > multihoming feature of SCTP, with which the users of SCTP users will
> > do
> > appropriate action to use it best....
> > 
> > Is the observation valid??
> > 
> > Thanks
> > -arun
> > 
> > Coene Lode wrote:
> > 
> > > Previous week, the draft on SCTP multihoming issues was published.
> > >
> > > Apart from some editorial changes concerning author list and
> > > missing/wrong
> > > page numbers,
> > > the only major change is a sentence added at the end of paragraph
> > > 2.3 SCTP
> > > multihoming and Network Adress Translators(NAT):
> > > "It should be noted that the NAT box becomes a single
> > >     point-of-failure in this case, as ALL the paths of the SCTP
> > >     association have to go through that single NAT box."
> > > Theoretical it is possible to let all the different paths run
> > > through
> > > different NAT boxes, but then the NAT boxes would never 
> know exactly
> > > when to
> > > teardown/terminate the association as the terminate or abort takes
> > > only one
> > > of the paths(and there are other difficulties, such as the
> > > heartbeats
> > > ...etc...) So in practical terms this sentence should be 
> correct. If
> > > you
> > > feel otherwise, please let me know and I'll remove or add 
> something
> > > to it to
> > > make everything clear.
> > >
> > > The draft can be found at the IETF draft directory:
> > > Multihoming issues in the Stream Control Transmission Protocol
> > > <draft-coene-sctp-multihome-02.txt>
> > >
> > > If by then end of next week, no further issues have been 
> identified,
> > > then I
> > > would ask for this draft to be moved to informational.
> > >
> > > yours sincerly
> > > Lode Coene
> > >
> > > _______________________________________________
> > > tsvwg mailing list
> > > tsvwg@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/tsvwg
> > 
> > --
> > ****************************************************************
> > V.Arun Prasad
> > HCL Technologies Ltd.
> > 51, Jawaharlal Nehru Road,
> > Ekkattuthangal,
> > Guindy Industrial Estate,
> > Chennai - 600097.
> > 
> > Contact # : 9144 - 2334174
> >             9144 - 2334181
> >             extn : 233
> > ****************************************************************
> > 
> 
> -- 
> Randall R. Stewart
> randall@stewart.chicago.il.us 815-342-5222 (cell phone)
>