Subject: RE: [Mipshop] FMIPv6 - NAR sets up tunnel endpoint?

From: "GAABAB Brahim RD-CORE-CAE" <[email-masked]>
Date: Fri, 16 Sep 2005 13:21:24 +0200

Rejeev, some hyp. was missing in the last email. See inline please.

> De : GAABAB Brahim RD-CORE-CAE 
> 
> > De : Rajeev Koodli
> 
> > If the MN leaves without receiving FBack (in which 
> indication to use 
> > PCoA is present), it sends FNA[FBU]. In this case, rules 
> described on 
> > Page 13 apply. (See "When the NCoA corresponding to the FNA.."
> 
> Rajeev, the case I was describing is: proactive, FBAck 
> received at the pAR link, no nCoA is delivered. Sorry if it 
> was not clear.. But I will analyze the case you've described: 
> proactive, FBAck NOT received at the pAR, no nCoA was 
> delivered by nAR.
> The latter hyp. results in the pAR-nAR tunnel after the 
> completion of HI/Hack, MN is not aware..
> 
> The following applies also (see bottom of p.13):
>    "When the MN establishes link connectivity with the NAR, it SHOULD
>    send a Fast Neighbor Advertisement (FNA) message (see 
> 6.3.3).  If the
>    MN has not received an FBack by the time the FNA is being sent, it
>    SHOULD encapsulate the FBU in the FNA and send them together."
> 
> Suppose that proposed nCoA is acccepted (in the spec, address 
> verification by the nAR is a MUST, address assignment is not; 
> see section 5.2).

I've forgot to mention this hypthesis: the nCoA used for FNA is
different of the one sent at pAR link. Nothing prohibits this in the
spec.
Even if both nCoA are similar, accepting the nCoA after rejecting it
first is possible? may be rarely..

 So the following applies (see top of p.14)
>    "When the NCoA corresponding to the FNA message is 
> acceptable, the NAR
>    MUST
> 
>    1. delete its proxy neighbor cache entry, if any is present.
> 
>    2. create a neighbor cache entry and set its state to REACHABLE
>       without overwriting an existing entry for a different layer 2
>       address.
> 
>    3. forward any buffered packets.
> 
>    4. enable the host route entry for PCoA, if any is present."
> 
> 
> So here we will have the pCoA-nCoA established also (after 
> forwarding the FBU at nAR).
> 
> Am I confused some where?
> 
> Best Regards,
> 
> Brahim.
> 
> > 
> > And see:
> > 
> > "If the MN receives a Router Advertisement with a NAACK option, it
> >     MUST use the IP address, if any, provided in the NAACK option.
> >     Otherwise, the MN should configure another NCoA.  
> > Subsequently, the
> >     MN SHOULD send an FBU using the new CoA.  **As a 
> special case, the
> >     address supplied in NAACK could be PCoA itself, in 
> which case the 
> > MN
> >     MUST NOT send any more FBUs.**"
> > 
> > So, the result is that the second tunnel you mention below is not 
> > established.
> 
> And when the nAR delivers a nCoA valid in its link Is it 
> systematic that if the nAR did not delivered and address in 
> the first FBU/FBAck and MN uses the pCoA, that the nAR will 
> also deliver the pCoA in the 
> 
> > 
> > Regards,
> > 
> > -Rajeev
> > 
> > 
> > 
> > GAABAB Brahim RD-CORE-CAE wrote:
> > > Hi Rajeev, James,
> > > 
> > > In the case where no nCoA can delivered in an FBA received
> > at the pAR link, the protocol operation results in two 
> tunnels : first 
> > pAR-nAR after the end of the first HI/HAck, then pAR-nCoA after the 
> > 'successful' FBU/FBA at nAR link.
> > > 
> > > I agree with James : here we have unecessarily established
> > the second tunnel (pAR-nCoA). IMO, there are two 
> possibilities to deal 
> > with this :
> > >  1. pAR and nAR delete the pAR-nAR tunnel (and corresponding host
> > > routes) after the second 'succesful' HI/HAck  2. MN do not
> > engage in
> > > the second FBU/FBA
> > > 
> > > 
> > > Regards,
> > > Brahim.
> > > 
> > > 
> > > 
> > >>De : Rajeev Koodli
> > >>Envoyi : jeudi 15 septembre 2005 01:58 @ : James Kempf Cc 
> : GAABAB 
> > >>Brahim RD-CORE-CAE; [email-masked]; Alexandru Petrescu
> > Objet : Re: 
> > >>[Mipshop] FMIPv6 - NAR sets up tunnel endpoint?
> > >>
> > >>
> > >>Hi Jim,
> > >>
> > >>the PAR - NCoA is the default, normal, _predominant_ mode of 
> > >>operation, and is required.
> > >>
> > >>PAR - NAR tunnel is the fallback case when NCoA is not 
> supported by 
> > >>NAR for whatever reason. This feature is a MAY.
> > >>Sorry if this was not clear from my previous message.
> > >>
> > >>
> > >>-Rajeev
> > >>
> > >>
> > >>James Kempf wrote:
> > >>
> > >>>Rajeev,
> > >>>
> > >>>Is there any reason why we couldn't simplify the protocol
> > >>
> > >>by getting
> > >>
> > >>>rid of either the PAR-NAR tunnel or the PAR-NCoA tunnel?
> > >>>
> > >>>           jak
> > >>>
> > >>>----- Original Message ----- From: "Rajeev Koodli" 
> > >>><[email-masked]>
> > >>>To: "GAABAB Brahim RD-CORE-CAE" <[email-masked]>
> > >>>Cc: <[email-masked]>; "Alexandru Petrescu" 
> > >>><[email-masked]>
> > >>>Sent: Wednesday, September 14, 2005 11:20 AM
> > >>>Subject: Re: [Mipshop] FMIPv6 - NAR sets up tunnel endpoint?
> > >>>
> > >>>
> > >>>
> > >>>>Folks,
> > >>>>
> > >>>>
> > >>>>GAABAB Brahim RD-CORE-CAE wrote:
> > >>>>
> > >>>>
> > >>>>>>It is not clear from the document that the tunnel
> > >>
> > >>destination for
> > >>
> > >>>>>>PAR's tunnel endpoint can be either NAR's address or
> > >>
> > >>NCoA's address.
> > >>
> > >>>>>
> > >>>>>There is no information about this in the spec !
> > >>>>>
> > >>>>
> > >>>>
> > >>>>Page 11, in the paragraph beginning with "After a PrRtAdv.."
> > >>>>
> > >>>>"In response to the
> > >>>>   FBU, the PAR establishes a binding between PCoA ("Home
> > >>
> > >>Address") and
> > >>
> > >>>>   NCoA, and sends the FBack to the MN.  Prior to
> > establishing this
> > >>>>   binding, PAR SHOULD send an HI message to NAR, and
> > >>
> > >>receive HAck in
> > >>
> > >>>>   response."
> > >>>>
> > >>>>This is for PAR - NCoA tunnel.
> > >>>>
> > >>>>The PAR - NAR tunnel is also established in the same way
> > >>
> > >>depending on
> > >>
> > >>>>the HI/HAck exchange. I guess we need to add a specific
> > >>
> > >>code value to
> > >>
> > >>>>indicate host route support for PCoA and tunnel end-point
> > >>
> > >>being NAR.
> > >>
> > >>>>Some context: the implicit assumption has been that
> > >>
> > >>support for PCoA
> > >>
> > >>>>on NAR should be a rare case.
> > >>>>
> > >>>>Thanks,
> > >>>>
> > >>>>-Rajeev
> > >>>>
> > >>>>
> > >>>>
> > >>>>>_______________________________________________
> > >>>>>Mipshop mailing list
> > >>>>>[email-masked]
> > >>>>>https://www1.ietf.org/mailman/listinfo/mipshop
> > >>>>
> > >>>>
> > >>>>
> > >>>>_______________________________________________
> > >>>>Mipshop mailing list
> > >>>>[email-masked]
> > >>>>https://www1.ietf.org/mailman/listinfo/mipshop
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>>_______________________________________________
> > >>>Mipshop mailing list
> > >>>[email-masked]
> > >>>https://www1.ietf.org/mailman/listinfo/mipshop
> > >>
> > >>
> > 
> > 

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

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 16 Sep 2005 10:38:36 -0700

> first is possible? may be rarely..

hmm.. Sounds strange. When NAR verifies [NCoA, LLA] in FNA, it must know 
that tunnel for PCoA is set up due to HI/HAck exchange, which is used so 
that there is no "loss of memory" :-)

-Rajeev