Subject: RE: [L2tpext] Comments on draft-vipin-l2tpext-failover-01.txt

From: "Vipin Jain" <[email-masked]>
Date: Fri, 1 Mar 2002 00:43:50 -0800

Folks,

If you have any comments, feel free to send it to the list (possibly by
tomorrow afternoon so we can meet the Friday deadline).

Personally, I have two comments:

[1]
On re-sending the old-AVPs, I think going with MUST would be a conservative
approach  but very safe; How much of an impact would it have on the
processing? I doubt much.. given that  at least half of them have to be
encode anyways. So, IMHO we can keep it a MUST and evaluate it further on if
it could be avoided..

[2]
On Mark's comment to combine "Response Capability AVP" and "Request
Capability AVP", I think we agreed to have them as two separate (i.e.
different attribute type) AVPs because it would cover all four situations
for a tunnel endpoint:
- can initiate, can respond
- can't initiate, can respond
- can initiate, can't respond
- can't initiate, can't respond
Though the last one is useless and is default unless any capability is
negotiated.

thanks,
-- vipin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
W. Mark Townsley
Sent: Thursday, February 28, 2002 9:15 AM
To: Reinaldo Penno
Cc: [email-masked]; [email-masked]
Subject: Re: [L2tpext] Comments on draft-vipin-l2tpext-failover-01.txt

> Reinaldo Penno wrote:
>
>
> It think there will be no interoperability problems Mark.
>
> -All vendors MUST be able to recover tunnels if the AVPs are the same,
period.
> This is the baseline request.
>
> - If we have different AVPs the tunnel might or not be recovered. This is
a
> SHOULD.

I think the best choice for interoperability is to state that the same AVPs
MUST
be present the new tunnel as the old when sending SCCxx messages.

When receiving new messages, they SHOULD have the same AVPs as the old
tunnel in
order to continue with tunnel setup.

This is this the basic premise of being strict in what one sends, and
liberal in
what is accepted.

If you make both SHOULDs you could end up in a non-interoperable situation
where
it is not clear which side of the exchange is at fault with regards to the
RFC.

> waht do you think?
> -Reinaldo

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

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

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

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 01 Mar 2002 09:41:09 +0100

> Though the last one is useless and is default unless any capability is

Right, I had forgotten about the combinations. Thanks for the reminder. I
suppose we could make this a single ushort avp with 0, 1, 2, 3 depending on the
capability of the sender? 

I could go either way though. You're call.

---

From: "Vipin Jain" <[email-masked]>
Date: Fri, 1 Mar 2002 01:20:39 -0800

I have attached the latest revision for everybody's comments that includes
some editorial changes and other changes from discussions in past few days..

>I could go either way though. You're call.
The original proposal had ushort AVP with 0, 1, 2, etc. though in form of
bits. You had mentioned that it is pain to assign/reserve bits and that
you'd rather have them as two different attributes..

thanks,
-- vipin

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 01 Mar 2002 11:31:05 +0100

> you'd rather have them as two different attributes..

At the time, IANA and I were having several exchanges about the bit fields in
RFC2661. That, and we have had some interop problems with the framing and bearer
bits as well. So I had (and still have to some degree) an aversion to bit fields
where other methods will suffice. I suspect I made the suggestion at the height
of this. I am getting over the aversion now that things seem to be settled :-)

So, back to you're call for whichever you prefer, though even if it is a ushort,
defining them as discrete integers rather than bit-fields could make the IANA
considerations section a bit simpler. Or, you could just state that these are
all the values ever allowed, and leave IANA out of it completely.

> 
> thanks,
> -- vipin
> 
>   --------------------------------------------------------------------------------
>                                           Name: draft-vipin-l2tpext-failover-02.txt
>    draft-vipin-l2tpext-failover-02.txt    Type: Plain Text (text/plain)
>                                       Encoding: 7bit