Subject: RE: [rddp] IPsec & Markers

From: "Teisberg, Robert" <[email-masked]>
Date: Fri, 8 Oct 2004 11:16:35 -0500

Maybe I'm just dense, but how does IPSec solve the problem markers
are meant to solve?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Michael C. Cambria
> Sent: Friday, October 08, 2004 10:11 AM
> To: [email-masked]
> Subject: [rddp] IPsec & Markers
> 
> 
> 
> In MPA, is there any reason why, just like what is allowed 
> with CRC, one 
> cannot have a system administrator knob to disable the use of markers 
> when IPsec is being used?
> 
> In fact, when I know I'm using IPsec, I rather not have to go through 
> the overhead of markers even when the remote peer sets the M 
> bit in the 
> Request/Reply frame.
> 
> Regards,
> MikeC
> 
> -- 
> Michael C. Cambria
> 
> email : [email-masked]
>   VoIP : sip:[email-masked]
>    FWD : sip:[email-masked]
> 
> 
> 
> _______________________________________________
> rddp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rddp
> 

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

---

From: "Carrier, John" <[email-masked]>
Date: Fri, 8 Oct 2004 14:01:43 -0700

hi Mike,

why go to the effort of calculating the CRC when the markers unambiguously define the start of the FPDU? 

--jc

> MikeC wrote:
> In general, (to simplify) a receiver can take any given TCP 
> segment, use 
> the "length" to find the CRC.  If the CRC doesn't match, I 
> don't have an 
> FPDU.
> 
>

---

From: [email-masked]
Date: Mon, 11 Oct 2004 10:58:55 -0600

MikeC,

You started this saying "In MPA, is there any reason why, just like what is allowed with CRC, one cannot have a system administrator knob to disable the use of markers 
when IPsec is being used?"

With IPsec on, the CRC may not be there to check. Therefore without a marker, there may be no CRC to use to check that the segment contained an aligned FPDU.

Regards,
Pat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Michael C. Cambria
Sent: Friday, 08 October, 2004 12:00 PM
To: [email-masked]
Cc: Culley, Paul
Subject: Re: [rddp] IPsec & Markers

In general, (to simplify) a receiver can take any given TCP segment, use 
the "length" to find the CRC.  If the CRC doesn't match, I don't have an 
FPDU.

Regards,
MikeC

-- 
Michael C. Cambria

email : [email-masked]

---

From: "Culley, Paul" <[email-masked]>
Date: Tue, 12 Oct 2004 11:30:10 -0500

As a primary draft author, I don't think that we have arrived at any
consensus to change the current draft.  If anything, it looks like the
opposite is true, no change needed.  If anyone disagrees, please post
specific text that you would like to see in an updated draft; that will
probably help clarify the discussion.

Paul R. Culley
HP Fellow
281-514-5543

> Behalf Of Sukanta ganguly
> Sent: Tuesday, October 12, 2004 9:44 AM
> To: Somesh Gupta; [email-masked]; Black
> Subject: RE: [rddp] IPsec & Markers
> 
> Hi,
>   Do we need another draft for finalizing the IPSec & Marker 
> discussion. We have had a lot of discussion but seems like no 
> conclusion is beingh made. We keep on revisiting this topic 
> multiple times.
>   It definitely is time to  put a formal, agreeable statement 
> resolving this issue so that we can all conclude happily.
> 
> Thanks
> SG
> 
> --- Somesh Gupta <[email-masked]> wrote:
> 
> > David,
> > 
> > As far as MPA is concerned, a lot of the discussion held previously 
> > was under the context of an experimental draft.
> > 
> > My assumption is that if it is changes to go on the 
> standards track, 
> > it would be entirely open for another round of discussions.
> > 
> > Looking forward to your comments on the topic.
> > 
> > Thanks,
> > Somesh
> > 
> > 
> > 
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail Address AutoComplete - You start. We finish.
> http://promotions.yahoo.com/new_mail 
>

---

From: "Carrier, John" <[email-masked]>
Date: Tue, 12 Oct 2004 11:35:06 -0700

I agree with Caitlin.

The receiver already has all the flexibility it needs.  If it doesn't want markers, for whatever reason, it just clears the flag in the MPA Req/Rep message.  There is no reason to hash out the receivers reasons for not wanting markers.

--jc

> Caitlin Bestler
> Sent: Tuesday, October 12, 2004 9:13 AM
> To: Sukanta ganguly
> Cc: Somesh Gupta; Black; [email-masked]
> Sukanta ganguly said:
> >   Do we need another draft for finalizing the IPSec &
> > Marker discussion. We have had a lot of discussion but
> > seems like no conclusion is beingh made. We keep on
> > revisiting this topic multiple times.
> >   It definitely is time to  put a formal, agreeable
> > statement resolving this issue so that we can all
> > conclude happily.
> >
> > Thanks
> > SG
> >
> 
> If a bit were worth adding, it would have the following
> meaning:
> 
> 1) The side setting the bit has an MPA-Aware IPSEC
>    implementation.  Hence each IP Datagram submitted
>    to IPSEC for this connection would contain only
>    whole MPA Frames.
> 2) That in its interface with the local IPSEC stack
>    it will be aware of the original TCP Segment boundaries,
>    and that nothing in the local stack will disturb them.
> 3) That if this bit is set by the other side, then this
>    side does not want Markers sent to it.
> 
> The last point in particular strikes me as unlikely.
> If your peer does not have MPA thru IPSEC tightly
> integrated you will want markers.  Therefore you have
> to have the logic to process them.
> 
> This is a major contrast with the normal marker suppression,
> which is intended to support receivers who did not want to
> deal with Markers at all.
> 
> Markers are ugly, and they add code/gate complexity.  But
> they aren't all that computationally intensive.  If you have
> the code/gates to implement them, and you even have number
> crunching capacity to intergrate IPSEC, then why do you need
> to suppress receiving markers *if* and only if an "alignment-
> maintaing IPSEC tunnel" can be validated to exist?
> 
> The sender already MUST support generating or not generating
> them.  The existing bit was justified by allowing some
> implementations to totally avoid processing markers on
> receive when they in fact had no use for them.
> 
> But using up another option bit for this just doesn't
> strike me as worthwhile.  You do run out of them eventually.
> 
> 
> --
> Caitlin Bestler
> http://asomi.com/
>