Subject: RE: Discovery [was Re: [Pana] IETF LC and discussion: Next steps]

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Tue, 11 Jul 2006 16:14:17 +0200

Hi,

I've just presented the update of the DHCP PANA option in the dhc session and the draft seems to be ready for a WGLC (with the removal of the use of FDQN).
However, with the re-design of the PANA specification and ongoing discussion on discovery mechanism, there is a need to clarfify that the DHCP-based discovery mechanism is still required by the pana wg, to indicate to the dhc wg that the ongoing work is not "useless".
I think that, if it is decided to have a separate document on discovery mechanisms, one of the first points will be to clarify which method to use according to the newtork configuration.

We can talk about this during the next pana session, at least during my slot.

Lionel

-----Message d'origine-----
De : Alper Yegin [mailto:[email-masked]] 
Envoyé : jeudi 29 juin 2006 02:27
À : 'Yoshihiro Ohba'
Cc : 'Mark Townsley'; 'Jari Arkko'; [email-masked]
Objet : RE: Discovery [was Re: [Pana] IETF LC and discussion: Next steps]

That makes sense to me.

Alper

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Saturday, June 24, 2006 7:31 AM
> To: Alper Yegin
> Cc: 'Yoshihiro Ohba'; 'Mark Townsley'; 'Jari Arkko'; [email-masked]
> Subject: Re: Discovery [was Re: [Pana] IETF LC and discussion: Next 
> steps]
> 
> On Fri, Jun 09, 2006 at 03:31:41PM -0700, Alper Yegin wrote:
> >
> > If the separate document is going to say what we already have in the
> base
> > specification, I don't see why we should spin it off. Especially 
> > given
> that
> > the base document would have a dependency on the discovery document,
> which
> > is likely to take a lot of time and unnecessarily delay the PANA 
> > standardization.
> 
> As long as we can add other discovery mechanisms in separate documents 
> when needed in a future, it is ok for me.  From this perspective, let 
> me analyse Section 4.3 of the PANA specification:
> 
> "
>    When the PaC knows the IP address of the PAA, it can send a unicast
>    PANA-PAA-Discover message and initiate the PANA exchange.  In other
>    cases, the PaC MUST rely on dynamic discovery methods, such as
>    multicast-based and a traffic-driven discovery.
> "
> 
> For example, if we have a plan to define an anycast-based discovery 
> mechansim, then we can define the mechanism as a case where the PaC 
> knows the IP address of the PAA.  So once the mechanism is defined and 
> implmented, then we do not have to rely on the multicast-based 
> discovery.  The same discussion applies to DHCP-based discovery 
> mechanism.
> 
> Yoshihiro Ohba
> 
> 
> >
> >
> > Alper
> >
> >
> >
> > > -----Original Message-----
> > > From: Yoshihiro Ohba [mailto:[email-masked]]
> > > Sent: Wednesday, June 07, 2006 12:33 PM
> > > To: Alper Yegin
> > > Cc: [email-masked]; 'Mark Townsley'; 'Jari Arkko'
> > > Subject: Discovery [was Re: [Pana] IETF LC and discussion: Next 
> > > steps]
> > >
> > > On Tue, Jun 06, 2006 at 08:36:17AM -0700, Alper Yegin wrote:
> > > >
> > > > [1] Can we remove the discovery part of the base specification? 
> > > > Can
> we
> > > > mandate the DHCP-based discovery as specified in a separate
> document?
> > > >
> > >
> > > Also, there is Mark's comment in another thread:
> > > > There is precedent in other groups for advancing discovery 
> > > > separately from a base protocol (L2VPN/PWE3 and softwires, for 
> > > > example). Given that there are already multiple ways to do PANA 
> > > > discovery, I would consider pulling this out of the base 
> > > > specification as well, allowing it to advance as its own document.
> > >
> > > Initially I thought discovery should be integral part of base 
> > > specification.  But going through comments in IETF mailing list 
> > > (some person raised an issue on administrative scoped multicast in 
> > > multi-hop environment and some person indicated anycast) and 
> > > private discussion, now I have an impression that it might be good 
> > > to define discovery in separate document(s).  We can even define 
> > > default preference among multiple discovery methods in a separate document.
> > >
> > > Yoshihiro Ohba
> >
> >
> >
> > _______________________________________________
> > Pana mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pana
> >

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana