Subject: RE: [L2tpext] ppp draft issues - offset padding field

From: "Y Prasad" <[email-masked]>
Date: Wed, 4 Jul 2007 01:12:33 +0530

Hi Carlos,

> -----Original Message-----
> From: Carlos Pignataro [mailto:[email-masked]]
> Sent: Thursday, June 28, 2007 7:22 PM
> To: Y Prasad
> Cc: Ignacio Goyret; [email-masked]
> Subject: Re: [L2tpext] ppp draft issues - offset padding field
> 
> 
> 
> On 6/27/2007 7:31 PM, Y Prasad said the following:
> > Thanks Carlos for explaining difference between offset size and
offset
> > capability. Please see a comment below.
> >
> >
> > -----Original Message-----
> > From: Carlos Pignataro [mailto:[email-masked]]
> > Sent: Thursday, June 28, 2007 2:32 AM
> > To: Y Prasad
> > Cc: Ignacio Goyret; [email-masked]
> > Subject: Re: [L2tpext] ppp draft issues - offset padding field
> >
> >
> > Thank you for the comments, please see inline.
> >
> > On 6/27/2007 4:25 AM, Y Prasad said the following:
> >>
> >> Hi Carlos,
> >>
> >> Please see at <yp>
> >>
> >> Rather than a session-level negotiation, how about a tunnel-level
> >> SCCRQ/SCCRP capability advertisement, much like the "Pseudowire
> >> Capabilities List" or the "Modem On-Hold Capable AVP" from Section
4.1
> >> of RFC3573. A "Offset Capability" AVP can indicate how big of an
> > offset
> >> the sender is willing to insert, if requested at session-level.
> >>
> >> <yp> In v3 case tunnel can potentially carry non-ppp sessions. Do
you
> >> think offset size useful/needed across all non-ppp sessions as
well?
> >
> > This is a good point. Even though v3 supports other PW Types, the
Offset
> > Size is only applicable to PPP sessions. Other companion documents
> > (i.e., other PW Types) do not specify it, and the PPP document
specifies
> > other AVPs that are also only applicable to PPP.
> >
> >> Common offset size for all the different types of sessions may not
> >> benefit all the sessions.
> >
> > Note that there's not necessarily a common offset size for all PPP
> > sessions. The Offset Size is a Session Management AVP (per-session).
> > More below.
> >
> >> May be we are better off to keep it as session negotiated AVP?
> >
> > The "OFfset Size" is a Session-requested AVP. The "Offset
Capability"
> > only conditions/caps the maximum Offset Size that can be requested
on
> > sessions belonging to a given tunnel.
> >
> > <yp> wondering what will be the behavior in the following case:
> > session may get initiated/configured long after the tunnel is up. So
if
> > a ppp session that requires offset and the tunnel had not negotiated
> > offset capability, then we will bring down tunnel to negotiate
offset
> > capability?
> 
> If the offset capability is supported, it needs to advertise it at
> tunnel creation (SCCRQ, SCCRP). This is true for all capabilities;
<yp>
Not sure whether we still need to advertise particular session type
capabilities (here ppp specific) over the tunnel when the same is again
negotiated over session. We may have some thing like below

 Lac  ---------- lns
ICRQ   ----------> (lac advertise offset capability)
ICRP   <----------- (lns request offset size and advertise its
capability)
ICCN   -----------> lac request offset size

I am ok for advertising thru SCCRQ/SCCRP though as it helps each session
not to try for offset negotiation when peer does not support.

> 
> >
> > (IMHO)why not we just mention offset size avp as "ackable" session
AVP
> > and avoid offset capability need. I think its ok to define a new avp
> > type behavior.
> 
> This is in a way what the current text describes, with the "nak"
> (meaning "I won't add that offset size") being a CDN. Ignacio argued
> that control over the offset would need be placed in the device that
> would add the offset, and that's what the capability solves.

<yp>  
Since this addresses only performance issue, un-supported situations may
not need to end up in disconnecting the session when peer negotiates.

IMHO, offset padding avp can be a simple ackable non-mandatory avp that
can be requested by either of the peers independently.

> 
> There is an additional problem with session-management negotiation of
> this: In the outgoing call establishment negotiation, the first
message
> where a LAC can say "you can request up to this" is with the OCRP, but
> the LNS has only a chance to request a specific offset size in the
OCRQ,
> which happens before. I think that the tunnel-level advertisement
solves
> the problem presented by Ignacio in all cases, and is simpler.

May be this way?

   LAC  ---- LNS

       <----- OCRQ (lns advertise offset capability)
       
  OCRP  ------> (lac request offset padding and advertise its capability
as well)

  OCCN  <-------- (lns reqest offset padding)
 
Regards
yp
> 
> Thoughts?
> 
> Thanks,
> 
> --Carlos.
> 
> 
> >
> > Regards
> > yp
> >
> >> May be we can have this rule?
> >>
> >> - If receiver of this AVP decides to support this feature he should
> > ack
> >> the same so that sender knows for sure he can expect alignment that
he
> >> needs.
> >
> > Note also that both directions could request a different offset
size,
> > much like requesting (or not) and L2SS, or requesting (or not)
different
> > Cookie size (and value).
> >
> >> - Else sending this AVP is a nop to sender/receiver.
> >>
> >
> > I think that per-tunnel capability and per-session request is
simpler,
> > and (more importantly) aligned with how other AVPs/capabilities are
> > currently signaled: Tunnel-level capabilities (from example from
RFC3573
> > that Ignacio cited, and all the "xxx Capabilities" AVPs) and at the
> > session-level, the downstream (receiver, decap) requests what he
wants
> > sent to it (L2SS, Cookie, Session ID, etc).
> >
> >> My $.02 :), of course.
> >
> > Much appreciated. What do you think?
> >
> > Thanks,
> >
> > --Carlos.
> >
> >> Regards
> >> yp
> >>
> >>
> >> The "Offset Capability" AVP can have the same syntax as the "Offset
> >> Size" with different semantics. It could even be the same AVP
number
> >> (with semantics depending on the type of message in which the AVP
is
> >> in), or (my preference) a new AVP.
> >>
> >> That would allow the sender to have control via capability, and
would
> >> default to #1 if the "Offset Capability" is missing or it has a
zero
> >> value. Would that be an acceptable solution?
> >>
> >> Thanks,
> >>
> >> --Carlos (as editor).
> >>
> >>> The received value of this new AVP, together with the sent Offset
> >>> Size AVP will tell the receiver what to expect in terms of the
> >>> offset padding field: if the sender said it is willing to insert
> >>> up to 4 bytes and the receiver asked (or was going to ask) for 6,
> >>> only 4 bytes will be inserted by the sender. If the sender said up
> >>> to 8 bytes and the receiver asked for 6, the sender will insert
> >>> 6 bytes. If the sender said no offset will be inserted, nothing
> >>> will be inserted.
> >>>
> >>> Again, my preference is #1 as that would eliminate a significant
> >>> protocol complexity that adds no benefit (IMHO).
> >>>
> >>> Opinions, please?
> >>>
> >>> -Ignacio
> >>>
> >>> PS: This draft expired recently but a new one is in the works.
> >>> In the meantime, you can look here for the last version:
> >>> http://tools.ietf.org/html/draft-ietf-l2tpext-l2tp-ppp-05
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> L2tpext mailing list
> >>> [email-masked]
> >>> https://www1.ietf.org/mailman/listinfo/l2tpext
> >>>
> >
> 
> --
> --Carlos Pignataro.
> Escalation RTP - cisco Systems

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

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 03 Jul 2007 16:07:28 -0400

Thanks again, please see inline.

> negotiated over session. We may have some thing like below

Yes, it would be one or the other. The purpose of the capability
advertisement in SCCRQ/SCCRP is, as you describe below, to not have to
negotiate at the session level, and maintain the same signaling flow as
as with other messages, in which the receiving side requests some
dataplane characteristic.

More importantly, see below re. outgoing calls.

> not to try for offset negotiation when peer does not support.

OK.
And agreed as another reason.

>   OCCN  <-------- (lns reqest offset padding)

The problem here is that the OCCN is in the other direction:
    OCCN  ------>

So if the LAC advertises its capability in the OCRP, the LNS cannot
request the offset padding.

http://tools.ietf.org/html/rfc3931#section-3.4.2
http://tools.ietf.org/html/rfc2661#section-5.2.2

Based on this discussion and your comment above, I'm inclined to update
with an SCCRQ/P capability advertisement. That seems inline with
existing flow, and solves the requirement. Would that work?

Regards,

--Carlos (as editor).

---

From: "Y Prasad" <[email-masked]>
Date: Thu, 5 Jul 2007 22:02:27 +0530

Agree with you Carlos.

If capability advertise mentions max size offset support, then each
session can just request offset size without any response expectation to
the avp ?
Meaning offset size avp can be request-only-no-response-needed one?
If the received size is invalid due to implementation issues of the
peer, CDN may be sent to the requesting peer.

Offset size avp can be valid for non-ppp type sessions? If so we may
define this as generic avp?

Regards
yp

> Sent: Wednesday, July 04, 2007 1:37 AM
> To: Y Prasad

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 06 Jul 2007 10:58:20 -0400

> peer, CDN may be sent to the requesting peer.

Yes, exactly.

> define this as generic avp?

That would be outside the scope of this document, which covers only ppp.
RFC3931 or other companion documents have not defined any offset, so
it's ppp-only.

Thanks,

--Carlos.

---

From: "Y Prasad" <[email-masked]>
Date: Wed, 11 Jul 2007 17:22:34 +0530

Please see in-line response at <yp>

> Sent: Friday, July 06, 2007 8:28 PM
> To: Y Prasad

<yp> Thanks, Carlos for the confirmation.

> RFC3931 or other companion documents have not defined any offset, so
<yp>
IMHO:
Offset feature is useful for non-ppp type of session as well. So it is
worth to define this avp as part of generic rather than every protocol
ending up in defining in their respective drafts. I know this is out of
scope of current ppp draft/discussion. But still it is under the scope
of "l2tpext" working group?

With best regards
yp

> >>>>> session may get initiated/configured long after the tunnel is
up.
> > So
> >> negotiate at the session level, and maintain the same signaling
flow
> > as
> >>> Since this addresses only performance issue, un-supported
situations
> > may
> >>>> There is an additional problem with session-management
negotiation
> > of
> >>>> where a LAC can say "you can request up to this" is with the
OCRP,
> > but
> >>>>>>> only 4 bytes will be inserted by the sender. If the sender
said
> > up