Subject: RE: [mobile-ip] Consensus to include recent piggybacking proposal ?

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 15 Mar 2002 21:12:38 +0100

=> MTU is not relevant here as I tried to highlight
several times. 

BTW, didn't we get an email from the chairs that 
this issue was closed?

Hesham

  > Regards,
  > Charlie P.

---

From: "Karen E Nielsen (TED)" <[email-masked]>
Date: Mon, 18 Mar 2002 17:04:06 +0100

> > 
> Okay. 2a and 2b cant be piggybacked (that means final Mobility
> Header). Fine with me.
> 
> > In other words the extension header approach will not be 
> usable for the 
> > 2a. and 2b. RR messages. So if you want to go with the 
> extension header
> > approach, then half the RR messages must be implemented in 
> a final protocol
> > element and half in an extension header. 
> 
> 
> So?? I dont see the problem. 1a and 1b are initiated by MN (HoTI
> and CoTI). And 2a and 2b (HoT and CoT) are responses from the CN.
> Or I am too tired to figure out what you are saying....
> 
> are you at the IETF?

I am. 

However, I think that we are in full agreement. 
The fact that the RR 2a and 2b messages must be put in the final MH 
was all that I wanted to point out.

Karen

> 
> regards
> Vijay
> 
> >  
> > Karen
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: Vijay Devarapalli [mailto:[email-masked]]
> >>Sent: 15. marts 2002 22:57
> >>To: [email-masked]
> >>Subject: Re: [mobile-ip] Consensus to include recent piggybacking
> >>proposal?
> >>
> >>
> >>"Hesham Soliman (ERA)" wrote:
> >>
> >>>Charlie,
> >>>
> >>>  > > Karen Nielsen sent two emails to highlight
> >>>  > > the inability to piggyback some RR messages
> >>>  > > since they are placed in IPsec tunnels
> >>>  > > by the HA. You can generalise the same
> >>>  > > problem for Security Gateways, in those cases
> >>>  > > the MN might not be aware of security policies by
> >>>  > > intermediate routers (SGs).
> >>>  >
> >>>  > This is not an issue with the current proposal,
> >>>  > as Vijay has pointed out.
> >>>
> >>>=> As Vijay pointed out in his most recent email,
> >>>there could be issues with piggybacking 1a and
> >>>2a. Karen can speak for herself, but reading the
> >>>last email, it said something like 'strongly
> >>>stress ....that piggybaking 1a and 2a is not possible'.
> >>>
> >>Hesham, 
> >>
> >>I said either way is fine. That is *NOT* the issue here....
> >>
> >>Vijay
> >>
> >>
> >>>Also the other point was SGWs which the MN is
> >>>not aware of.
> >>>
> >>>  >
> >>>  > > Also the note was only relevant to IPsec and
> >>>  > > didn't address the QoS issues (e.g. when using
> >>>  > > Diffserv e2e or when having the Diffserv bits
> >>>  > > set by intermediate routers). These comments
> >>>  > > were explicitly made by David Oran and to some
> >>>  > > extent in my earlier emails.
> >>>  >
> >>>  > I responded at length to those e-mails.  There is no
> >>>  > issue with respect to piggybacking and QoS,
> >>>  > _unless_ you are trying to have some sort of
> >>>  > "implicit" QoS without asking for it.  In any
> >>>  > other case, the QoS signalling would trivially
> >>>  > be able to handle any setup required for
> >>>  > deciding whether or not to use piggybacking.
> >>>
> >>>=> First of all, no one is using e2e QoS signalling
> >>>today, please correct me if I'm wrong.
> >>>Second, I might have missed on of your emails
> >>>but I'd appreciate a pointer on how
> >>>Diffserv can be used here if there is a conflict
> >>>between the BU DSCPs and the payload's.
> >>>Obviously Diffserv is not always used e2e and
> >>>can be set by intermediate routers.
> >>>
> >>>Hesham
> >>>
> 
>